Product SiteDocumentation Site

9.2. Environments

Environments aid in staging developments and not breaking the production. There are three environments you may want to consider using:
development
The development environment is where you stage developments in your manifests, modules and plugins. You would apply the development environment to a small number of non-critical systems, that maybe are dedicated to the sole purpose of puppet development. These development systems would not necessarily be managed extensively with puppet, and may just apply only the classes you are making changes to. There is no use in applying the foo class to a development system if you are making changes to the bar module or class.
testing
The testing stage would be the stage where your basic development is finished, and you test the changes in a broader scope. Again, these systems should be non-critical systems, but these systems may also not be dedicated to puppet testing. In the testing stage, you would want to make sure all puppet classes and modules are applied correctly when used in combination with one another. For example, conflicts between modules and/or classes could be caused by duplicate resource definitions, or incorrect inter-module or inter-class dependencies (require =>, notify =>, before => and subscribe => statements). Although most of the dependencies are used in the development stage as well, using the testing stage makes sure N+X modules cooperate before you destroy your production.
Obviously, the testing stage is entirely optional. One could decide to not use the testing stage the way it is described here, but instead assign a couple of (power-)user desktops and have these users provide feedback on the changes applied, or not use the testing stage at all.
production
The production stage is the most important stage in the entire process of staging changes. The production environment is where most of the systems within your orgnization are managed in, and as such, changes applied to the production environment need to be proven stable (or system and services may be interrupted).

9.2.1. Setting Up Environments

Setting up the environments requires you to configure the available environments in /etc/puppet/puppet.conf. The relevant settings are:
[puppetmasterd]
    environments = development,testing,production
Per environment, create a section similar to the following:
[development]
    manifest = /var/lib/puppet/manifests/development/site.pp
    modulepath = /var/lib/puppet/modules/development

[testing]
    manifest = /var/lib/puppet/manifests/testing/site.pp
    modulepath = /var/lib/puppet/modules/testing

[production]
    manifest = /var/lib/puppet/manifests/production/site.pp
    modulepath = /var/lib/puppet/modules/production
Make sure you put the files and directories in place before restarting the puppetmaster service.

9.2.1.1. Client Configuration

Setting the environment the puppet gets it's configuration from is three-fold.
  1. The environment you want to run the puppet in needs to be a valid environment, and besides default valid environments development and production, additional environments need to be configured using the environments setting in the [puppetd] section of /etc/puppet/puppet.conf:
    [puppetd]
        environments = development,testing,production
    
  2. You can set the environment the puppet normally runs against with the environment setting in the [puppetd] section:
    [puppetd]
        environment = production
    
    The default environment for a puppet is production
  3. The environment can be specified using the --environment command-line option to puppetd.