Pro Puppet (47 page)

As we can see, Puppet is being run in no-operation mode, and would have created six resources: three for Bob and three for Alice, each person having a user, group and home directory managed for them. The developer has not explicitly declared any relationships among these resources, Puppet is managing them using the implicit relationships between file owners and groups and a user resources relationship to its group members. The relationship graph looks like that shown in
Figure 8-1
.

Figure 8-1.
Relationship graph for accounts_ruby

Adding new accounts managed by Puppet is now simply a matter of setting them in the ENC. No code in Puppet needs to be changed. Let's see how the developer adds a new account in
Listing 8-30
. The ENC script is modified to produce a third entry in the
account_resources
parameter for a local administrator account.

Notice there is now a third entry in the output of the external node classifier script. This information contains only the data related to the Local Administrator account. The modification to the script is simply a matter of adding the hash entry to the
account_resources
object, as you can see in the diff shown in
Listing 8-31
.

The developer is directly declaring Hash resources in the script, but this information could just as easily come from YAML data files stored on disk, LDAP or an SQL database. Finally, the developer runs
Puppet as shown in
Listing 8-32
. Puppet manages additional resources based on the new data coming through the ENC API.

Listing 8-32.
Puppet adding additional resources from the ENC information

$ puppet apply --verbose --noop /etc/puppet/manifests/site.pp
notice: /Stage[main]/Accounts_ruby/Group[alice]/ensure: is absent, should be present (noop)
notice: /Stage[main]/Accounts_ruby/Group[localadmin]/ensure: is absent, should be present
 (noop)
notice: /Stage[main]/Accounts_ruby/User[alice]/ensure: is absent, should be present (noop)
notice: /Stage[main]/Accounts_ruby/File[/home/alice]/ensure: is absent, should be directory
 (noop)
notice: /Stage[main]/Accounts_ruby/User[localadmin]/ensure: is absent, should be present
 (noop)
notice: /Stage[main]/Accounts_ruby/File[/home/localadmin]/ensure: is absent, should be
 directory (noop)
notice: /Stage[main]/Accounts_ruby/Group[bob]/ensure: is absent, should be present (noop)
notice: /Stage[main]/Accounts_ruby/User[bob]/ensure: is absent, should be present (noop)
notice: /Stage[main]/Accounts_ruby/File[/home/bob]/ensure: is absent, should be directory (noop)


This shows that Puppet is now managing nine resources instead of the six in the previous run. Puppet is managing the Local Administrator account simply by adding additional data to the external node classifier. This implementation would have been very difficult to carry out using only the Puppet language, since there is no easy way to iterate over a Hash. By using the each method in Ruby, the developer is able to declare an arbitrary and dynamically changing number of resources based on external data.

In the next section, we switch gears and examine another valuable tool in the Puppet ecosystem. Cucumber Puppet allows you to easily and clearly test your Puppet infrastructure.

A common problem with Puppet and configuration management in general is testing. After working with Puppet for some time, the Example.com operator has the nagging question, “How can I test changes I make to my systems with Puppet?” A frequently-used solution to this problem is to maintain an entirely separate network identically configured to the production network. Changes to Puppet are then deployed to the testing network prior to deploying them to production. While effective, this strategy incurs the overhead of maintaining a separate network. Additional hardware and time must be invested in the testing network.

Automated testing tools like Cucumber Puppet do not fully replace a rigorous testing network identically configured to production. However, in situations where a testing network is not available or feasible, Cucumber Puppet solves many of the problems related to testing and change control.

Cucumber Puppet is a tool that allows you to specify the desired behavior of a Puppet configuration catalog. Once specified, the tool also allows you to verify changes to the Puppet modules and manifests, resulting in a configuration catalog with the same specified behavior. This functionality allows you to make changes with confidence, knowing unintended side effects will not be introduced.

If you're already familiar with Cucumber, the specifications used by Cucumber Puppet will be familiar. Cucumber Puppet is inspired by the natural language descriptions of application behavior used in Cucumber. More information about Cucumber is available at
http://cukes.info/
. Let's see how the
Example.com operator installs and uses Cucumber Puppet to test and validate changes to his Puppet configuration.

Similar to the puppet-module tool discussed in this chapter, The Cucumber Puppet tool, cucumber-puppet, is not available as a native package on most operating systems. However, the software is easily installed using the RubyGems gem command (see
Listing 8-33
).

If you're installing on a Debian-based system, the gem command may be configured to install executable scripts in a location not in the PATH environment variable. On a Debian system, this location is /var/lib/gems/1.8/bin. If you encounter the “command not found” message shown in
Listing 8-34
, which the operator experiences on a Debian 6.0 system, you may use the gem environment command shown in
Listing 8-35
to find where the executable scripts are installed.