Puppet – Directory Environments

let’s say you have two groups of puppet agents, these 2 sets have the following names:

  • prod
  • test

Let’s now say that the same puppetmaster manages these two groups.
In which case te site.pp file will have node definitions for both prod and test agents.

This approach isn’t a good idea, that’s because, while testing, if you introduce an error into your site.pp, then that could also break prod as well.

One way around this is to have two site.pp files. This is by setting up something called “Directory Environments”.

With “Directory Environments”, you can have multiple site.pp files on the puppetmaster. These site.pp will also have exclusive access to it’s own modules folder, amongst other things.

To start using “Directory Environments”, you need to take the following steps:

  1. Configure Puppet Master to use directory environments
  2. Create your environments
  3. Assign nodes to their environments.

Configure Puppet Master to use directory environments

This involves:

  1. Enable Directory Environment on puppet.conf file
  2. Create a Directory Environment

Enable Directory Environment on puppet.conf file

Here we set the following parameters:

  • environmentpath – Before you set this, you first need to ensure you have a folder for this parameter to point to, e.g. I created a folder called /etc/custom-environments and set this parameter to this. I think best practice is to set this to $confdir/environments. Also see the environmentpath reference. This value must be set in the [main] section.
  • basemodulepath – This is optional, it’s a place to for storing modules that are to be used by all environments. It acts as a fallback if the environment’s own module doesn’t contain the module. Also see the “basemodulepath” reference.
  • default_manifest – This is optional, also see the default_manifest referece.

Create a Directory Environment

Under the $environmentpath directory, you need to create a folder for each of your environments, hence the folder’s should be named after your environment. I.e. The directory name is the same as the environment’s name.

Within each of these folders, create the following folders/files:

  • modules
  • manifests
  • environment.conf – this is optional. environment.conf overrides defaults.

For example if we want to create an environment called “test1”, and our $environmentpath is equal to /etc/custom-environments, then we will end up with the following structure:



See also Puppetlabs page for more info about how to create directory environments.

Puppetlabs also has a page covering environment.conf.

Restart PuppetMaster

Whenever you make changes to the puppet.conf, you need to to then restart the puppetmaster to load the changes:

service puppetmaster restart

Assign agents to environments

When ever an agents requests a catalog from the puppetmaster (i.e. doing a puppet run), it will need to tell the master what environment it belongs to.

You can do this through ENC or via the agent’s puppet.conf file.

We’ll look at the ENC approach later. For now we’ll just look at assining agent to an environment using teh config file.

See also:
https://docs.puppetlabs.com/puppet/latest/reference/environments.html

http://puppetlabs.com/blog/git-workflow-and-puppet-environments

http://puppetlabs.com/blog/git-workflow-and-puppet-environments