Chapter 10. Creating a Test Environment

Puppet provides the ability to serve clients different versions of modules and data using environments. You can use environments to provide unique catalogs to different groups of machines, which can be very useful in large projects with many teams. However, a primary usage of environments is to enable testing of changes to Puppet policy without breaking production environments.

Puppet environments have proven so necessary and useful for code testing and deployment that they are enabled by default in Puppet 4. So before we go on to install Puppet modules, let’s configure the production and test environments.

Verifying the Production Environment

The default environment used by Puppet clients is named production. The Puppet installation creates the production environment during the installation of Puppet. You should find that this already exists:

[vagrant@client ~]$ ls -l /etc/puppetlabs/code/environments/production
total 4
-rw-r--r-- 1 root root 879 Mar 26 19:27 environment.conf
drwxr-xr-x 2 root root   6 Mar 26 19:38 hieradata
drwxr-xr-x 2 root root   6 Mar 26 19:38 manifests
drwxr-xr-x 2 root root   6 Mar 26 19:38 modules

The default environment is prepared with an environment configuration file, and directories for Hiera data, modules, and manifests.

Creating the Test Environment

Now let’s create a test environment you can use to test out new modules or changes to modules prior to implementing them in production. Create the environment like so:

[vagrant@client ~]$ mkdir -p /etc/puppetlabs/code/environments/test/modules
[vagrant@client ~]$ cd /etc/puppetlabs/code/environments/test
[vagrant@client test]$ mkdir hieradata

This gives us a place to test module changes without breaking any production nodes. Let’s also enable a reminder that we are using the testing environment:

[vagrant@client test]$ mkdir manifests
[vagrant@client test]$ $EDITOR manifests/site.pp

The contents of this file should be something like this:

  notify { 'UsingTest':
    message => "Processing catalog from the Test environment.",
  }

This will give you a warning any time you use this environment, which can be a helpful reminder to move a node back to the production environment when testing is complete.

Changing the Base Module Path

The Puppet configuration has a convenience setting that allows you to share modules between all environments. The following can be specified in /etc/puppetlabs/puppet/puppet.conf:

[main]
  # these are both default values
  environmentpath = /etc/puppetlabs/code/environments
  basemodulepath = /etc/puppetlabs/code/modules

The environmentpath variable contains a path under which a directory for each environment will be created.

The basemodulepath variable contains a directory that will be used as a fallback location for modules not found in the environment’s modules/ directory. This allows you to place common and well-tested modules in a single location shared by all environments.

Both of the directory names shown are the default values, and do not need to be specified in the configuration file unless you wish to change them.

Skipping Ahead

While there are many things you can fine-tune and customize with Puppet environments, many of them wouldn’t make much sense at this point in our learning process. These environments are ready for us to use.

We’ll come back to cover environments in much greater detail in Chapter 29.

Previous Chapter

II. Creating Puppet Modules

Next Chapter

11. Separating Data from Code

Table of Contents for Learning Puppet 4

Chapter 10. Creating a Test Environment

Verifying the Production Environment

Creating the Test Environment

Changing the Base Module Path

Skipping Ahead

Table of Contents for
Learning Puppet 4