Pro Puppet (19 page)
Authors: Jeffrey McCune James Turnbull
Similar to the development environment you just set up, you’ll also clone the production environment modules into a testing environment.
$ cd /etc/puppet/environments/testing
$ git clone ../../modules
Initialized empty Git repository in /etc/puppet/environments/testing/modules/.git/
$ cd modules
$ git remote add production /etc/puppet/modules
$ git remote add development /etc/puppet/environments/development/modules
Notice how we’ve also added the development repository as a remote in the testing environment repository. This will allow you to fetch changes you make in the development repository to the testing repository.
Tip
For additional information on a branch and merge strategy using environments and Subversion rather than Git, please seehttp://projects.puppetlabs.com/projects/1/wiki/Branch_Testing.
Now that you have your three environments populated with the same Puppet modules, you can make changes without affecting the production environment. We’re going to use a basic workflow of editing and committing changes in the development branch first. This mirrors the common development life cycle of moving from development to testing and finally to production. We’ll start with running a Puppet
agent in the development environment to test the change we’ve made. Then, if everything goes well in the development environment, you can merge this change into testing or into production.
Tip
In large Puppet setups where changes from multiple groups of people need to be managed, it is common to run a selection of hosts against the testing environment. Periodically, the production environment repository will be synchronized against the testing environment.
We’re going to edit the Postfix configuration file template we created in
Chapter 2
to explore how Puppet isolates the three environments we’ve created. We’ll edit the filemain.cf.erbin the development environment and then run the Puppet agent in this environment to see the change. We’ll also run the Puppet agent in the production environment, which we have not changed yet, and make sure our changes do not have any effect on production.
To start, edit the filemain.cf.erbin/etc/puppet/environments/development/modules/postfixusing your favorite text editor and add a new line at the very top of the file to look like:
/templates/
# This file managed by puppet: <%= this_will_fail %>
soft_bounce = no
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
myhostname = <%= hostname %>
mydomain = <%= domain %>
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
unknown_local_recipient_reject_code = 550
relay_domains = $mydestination
smtpd_reject_unlisted_recipient = yes
unverified_recipient_reject_code = 550
smtpd_banner = $myhostname ESMTP
setgid_group = postdrop
Now that you’ve made a change to the development environment, Git will let you know that the status of the repository has changed:
$ git status
# On branch master
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: main.cf.erb
#
no changes added to commit (use "git add" and/or "git commit -a")
Git has noticed that you’ve made a change to themain.cf.erbfile and tells you this on the “modified” line. As we learned in
Chapter 2
, we must add files changed in the working directory to the
index, and then commit the index to the repository. Before you do this, you should double-check to make sure the line you modified is what will actually be added in the new commit.
$ git diff
diff --git a/postfix/templates/main.cf.erb b/postfix/templates/main.cf.erb
index 3331237..2be61e0 100644
--- a/postfix/templates/main.cf.erb
+++ b/postfix/templates/main.cf.erb
@@ -1,3 +1,4 @@
+# This file managed by puppet: <%= this_will_fail %>
soft_bounce = no
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
Notice the line beginning with the single plus sign. This indicates that you’ve added one line and this addition will be recorded when we commit the change, as we will with thegit commitcommand:
$ git commit –a –m 'Updated postfix configuration template'
[master 0fb0463] Updated postfix configuration template
1 files changed, 1 insertions(+), 1 deletions(-)
You’ve now successfully changed the development environment. But before testing the change on ourmailtest.example.comsystem, let’s review the environment configuration changes you’ve made to the Puppet Master.
puppet.confon the master now contains adevelopmentandtestingsection.- The Puppet master process has been restarted to activate the change to
puppet.conf. - You updated
modulepathandmanifestin the development and testing section. - You cloned the modules VCS repository to /etc/puppet/environments/{testing,development}/modules.
- You updated the
postfixmodule and committed the change to the development repository.
Now that you have multiple environments configured on the Puppet master system and have made a change to the development environment, you’re able to test this change using the Puppet agent.
In order to tell Puppet to use an environment other than production, use theenvironmentconfiguration parameter or command line option:
$ puppet agent --noop --test --environment testing
Tip
Up through Puppet 2.6, the Puppet configuration on a node configures the environment that the node uses. The Puppet master does not directly control which environment a machine connects to. This may change in the future once issue #2834 is resolved; please watchhttp://projects.puppetlabs.com/issues/2834for up-to-date information. If you would like to manage the environment from the Puppet master, we recommend having Puppet manage the node’spuppet.conffile and specify theenvironmentparameter in the managed configuration file.
Running the Puppet agent onmailtest.example.comin the testing environment should produce the same results as running the agent in the production environment.
Tip
We recommend developing a habit of testing changes to Puppet using the--noopcommand line option. As mentioned in
Chapter 1
, the--noopoption tells Puppet to check the current state of the system against the configuration catalog, but does it not manage the resources on the node. This provides a safe way determine if Puppet is going to make a change. It’s also a unique feature of Puppet, compared to other tools.
You can switch between the production and testing environments by simply removing theenvironmentcommand line option. The default environment is production (defined in themainstanza in thepuppet.conffile); therefore, you need only leave the environment unspecified to switch back to the production environment.
$ puppet agent --noop --verbose –test
Notice how no resources are changing when switching between the two environments. This is because the testing environment is a clone of the production environment, and you have not made any changes to either of these two environments. In the last section, however, you made a change to Postfix module in the development environment, and we expect the Puppet agent to update themain.cfpostfix configuration file with this change. Let’s check the development environment now:
$ puppet agent --noop --verbose --test --environment development
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse
template postfix/main.cf.erb: Could not find value for 'this_will_fail' at
/etc/puppet/environments/development/modules/postfix/manifests/config.pp:17 on
node mailtest.example.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
