Hiera's main configuration file can also use environment, as a variable. This leads us to two options: a single hierarchy with the environment as a hierarchy item and multiple hierarchies where the path to the hieradata directory comes from the environment setting. To have separate hieradata trees, you can use environment in the datadir setting for the backend, or to have parts of the hierarchy tied to your environment, put %{::environment} in the hierarchy.

Stand# cd /etc/puppetlabs/code/environments
stand# cp -a production/hieradata development

:yaml:
  :datadir: '/etc/puppetlabs/code/environments/%{::environment}/hieradata'

---
welcome: 'Production Node: watch your step.'

---
welcome: "Development Node: it can't rain all the time."

[root@client ~]# puppet agent -t
…
Notice: /Stage[main]/Base/File[/etc/motd]/ensure: defined content as '{md5}8147bf5dbb04eba29d5efb7e0fa28ce2'
Notice: Applied catalog in 0.83 seconds
[root@client ~]# cat /etc/motd
Production Node: watch your step.
Managed Node: client
Managed by Puppet version 4.2.2

[root@client ~]# puppet agent -t --environment=development
…
Notice: /Stage[main]/Base/File[/etc/motd]/content: 
--- /etc/motd   2015-09-30 21:35:59.523156901 -0700
+++ /tmp/puppet-file20150930-3185-1vyeusl       2015-09-30 21:45:18.444186406 -0700
@@ -1,3 +1,3 @@
-Production Node: watch your step.
+Development Node: it can't rain all the time.
 Managed Node: client
 Managed by Puppet version 4.2.2

Info: Computing checksum on file /etc/motd
Info: /Stage[main]/Base/File[/etc/motd]: Filebucketed /etc/motd to puppet with sum 8147bf5dbb04eba29d5efb7e0fa28ce2
Notice: /Stage[main]/Base/File[/etc/motd]/content: content changed '{md5}8147bf5dbb04eba29d5efb7e0fa28ce2' to '{md5}dc504aeaeb934ad078db900a97360964'
Notice: Applied catalog in 0.04 seconds

---
:hierarchy:
  - "environments/%{environment}"
  - "hosts/%{hostname}"
  - "roles/%{role}"
  - "%{kernel}/%{os.family}/%{os.release.major}"
  - "is_virtual/%{is_virtual}"
  - common
:backends:
  - yaml
:yaml:
  :datadir: '/etc/puppetlabs/code/hieradata'

---
welcome: 'Single tree production welcome'

---
welcome: 'Development in Single Tree'

[root@client ~]# puppet agent -t
…
Notice: /Stage[main]/Base/File[/etc/motd]/content: 
--- /etc/motd   2015-09-30 21:45:18.465186407 -0700
+++ /tmp/puppet-file20150930-3221-bh9ik5        2015-09-30 21:53:43.283213056 -0700
@@ -1,3 +1,3 @@
-Development Node: it can't rain all the time.
+Single tree production welcome
…
Notice: Applied catalog in 0.67 seconds

Our configuration for Hiera did not specify production or development environments in hiera.yaml. We used the environment value to fill in a path on the filesystem. The directory environments in Puppet function the same way. Directory environments are the preferred method for configuring environments. When using directory environments, it is important to always account for the production environment, since it is the default setting for any node, when environment is not explicitly set.

Puppet determines where to look for directory environments, based on the environmentpath configuration variable. In Puppet 4, the default environmentpath is /etc/puppetlabs/code. Within each environment, an environment.conf file can be used to specify modulepath, manifest, config_version and environment_timeout per environment. When Puppet compiles a catalog, it will run the script specified by config_version and use the output as the config version of the catalog. This provides a mechanism to determine which code was used to compile a specific catalog.

Versions 3.7 and above of Puppet also support a parser setting, which determines which parser (current or future) is used to compile the catalog in each environment. In version 4 and above, the future parser is the only available parser. Using the parser setting, it is possible to test your code against the future parser before upgrading from Puppet 3.x to 4. The usage scenario for the parser option will be to upgrade your development environments to the future parser and fix any problems you encounter along the way. You will then promote your code up to production and enable the future parser in production.

Using the manifest option in environment.conf, it is possible to have a per environment site manifests. If your enterprise requires a site manifest to be consistent between environments, you can set disable_per_environment_manifest = true in puppet.conf to use the same site manifest for all environments.

If an environment does not specify a manifest in environment.conf, the manifest specified in default_manifest is used. A good use of this setting is to specify a default manifest and not specify one within your environment.conf files. You can then test a new site manifest in an environment by adding it to the environment.conf within that environment.

The modulepath within environment.conf may have relative paths and absolute paths. To illustrate, consider the environment named mastering. In the mastering directory within environmentpath (/etc/puppetlabs/code/environments), the environment.conf file has modulepath set to modules:public:/etc/puppetlabs/code/modules. When searching for modules in the mastering environment, Puppet will search the following locations:

Another useful setting in puppet.conf is basemodulepath. You may configure basemodulepath to a set of directories containing your enterprise wide modules or modules that are shared across multiple environments. The $basemodulepath variable is available within environment.conf. A typical usage scenario is to have modulepath within environment.conf configured with $basemodulepath, defined first in the list of directories, as shown here:

modulepath=$basemodulepath:modules:site:/etc/puppetlabs/code/modules

A great use of directory environments is to create test environments where you can experiment with modifications to your site manifest without affecting other environments. (provided you haven't used the disable_per_environment_manifest setting). As an example, we'll create a sandbox environment and modify the manifest within that environment.

Create the sandbox directory and environment.conf with the following contents:

manifest=/etc/puppetlabs/code/test

Now, create the site manifest at /etc/puppetlabs/code/test/site.pp with the following code:

node default {
  notify {"Trouble in the Henhouse": }
}

Now when you do an agent run on the client node against the sandbox environment, the site manifest in /etc/puppetlabs/code/test will be used, as shown here:

[root@client ~]# puppet agent -t --environment sandbox
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for client.local
Info: Applying configuration version '1443285153'
Notice: Trouble in the Henhouse
Notice: /Stage[main]/Main/Node[default]/Notify[Trouble in the Henhouse]/message: defined 'message' as 'Trouble in the Henhouse'
Notice: Applied catalog in 0.02 seconds

This type of playing around with environments is great for a single developer, but when you are working in a large team, you'll need some version control and automation to convert this to a workable solution. With a large team, it is important that admins do not interfere with each other when making changes to the /etc/puppetlabs/code directory. In the next section, we'll use Git to automatically create environments and share environments between developers.

For further reading on environments, refer to the Puppet Labs website at http://docs.puppetlabs.com/guides/environment.html.