Pulling Strings With Puppet - James Turnbull [33]
Figure 4-1. The example environment
The environment consists of four hosts running a variety of operating systems and with a variety of purposes. While four hosts may not seem like a lot, you'll see that the practices and structure I am going to demonstrate in this chapter can easily be extended to cater to larger numbers and types of hosts. You can see a full list of these hosts and their details in Table 4-1.
We've installed the latest version of Puppet on the puppetmaster host and the Puppet daemon on all the remote hosts. We've also connected our clients to the master and added them to the master using the puppetca binary. Our clients and master are installed with the default configuration.
Manifest Organization
Before we get started configuring our environment, we need to look at how Puppet manages and stores our configuration. As you'll remember, our resources, classes, and definitions are stored in manifest files. A special manifest file, called the site manifest, is at the core of our configuration. When starting the Puppet master daemon, the site manifest file, by default located in /etc/puppet/manifests/site.pp, needs to be present and syntactically correct.
Importing Manifests
If we added all our configuration to the site. pp file, it'd quickly become complicated and hard to manage. So instead, we store our configuration in multiple files. We think about the site manifest file as the apex of a pyramid; in this file, all other manifests and the configuration defined in them must be referenced. This is done by importing files into your site manifest file. We do this using the import function as you can see in Listing 4-1.
In Listing 4-1, we've used five import statements. First, we've imported the file templates. pp and the file nodes. pp. You do not have to specify the . pp extension. By default, Puppet will add the . pp extension to any file specified in the import statement that doesn't already have it. Next, we've used globbing to import the contents of three subdirectories: groups, users, and os.' By specifying the * symbol, Puppet will load all of the files that have an extension of . pp in those directories.
We also might use our site. pp file to set up a default filebucket or some other defaults for types as we have in Listing 4-2.
In Listing 4-2, we've defined a default filebucket and told the file type to always back up files to that filebucket.
We can also apply a structure to the files we import into our site. pp file. In Table 4-2, I've shown an example structure of files and directories to hold your configuration resources.
We'll discuss and expand on the structure in Table 4-2 further during this chapter. You can locate this directory structure wherever it suits you. By default, Puppet looks for the manifest files in /etc/puppet/manifests, controlled by the manifestdir configuration option.
Other people locate their manifests under the /var/puppet directory. You should choose the location that best suits your environment and standards. We can also override and change the name of the site. pp file using the manifest configuration option:
The manifest option defaults to the value of $manifestdir/site. pp.
Managing Manifests with Subversion
One last manifest management tool we're going to use is a version control system, which is the best tool for managing a large number of manifests. We're going to use a Subversion repository. Subversion is an open source version control system that can store and manage your manifest files. Subversion manages files and directories and tracks changes made to them over time. This allows you to revert changes or restore to a previous state. To use Subversion, you will need to install it. Most Linux and Unix hosts will have a Subversion package available; for example, on a Debian platform, you would need to install the subversion package.
Note - If you don't like or use Subversion as a version control tool, you can use an alternative tool like Git, Monotone, or CVS.
First, we create a Subversion repository.
$ svnadmin