Pulling Strings With Puppet - James Turnbull [34]
Next, in Listing 4-3, we add our Puppet directory structure and files to the repository.
In Listing 4-3, we've imported the contents of the puppet directory into the repository we created. You can see each file being added and the final message indicating that the first revision has been committed to the repository. If we now wish to check out these files into what Subversion calls a "working copy" to use in Puppet, we can do this using the svn checkout function.
We then make any updates and changes to our working directory. Then each time we update our Puppet manifests, we commit our changes using the svn commit command.
We can now potentially revert back to a previous revision of our configuration if we wish to reverse a change or changes.
Tip - If you've never used Subversion before, an excellent introduction is available at http: //svnbook. red-bean. com/. You can also see details of the various Subversion options by running the svn command with the help option: svn help.
Defining Nodes
Let's configure our nodes first. We'll start with the node definitions themselves, and to make it easier, we're going to classify our nodes into types and build some templates. We're going to template our nodes on the assumption that we're going to have multiple mail, web, firewall, and database hosts in our environment. So we're going to create a base node and some template nodes for each.
Caution - As I mentioned in Chapter 3, template nodes (and node inheritance) is generally only useful for inheriting and templating nodes with static classes that do not include variables. Say we want to specify a variable in our node that overrides a particular variable in a template node; unfortunately, due to variable scope, we can't. We discussed this limitation in Chapter 3. Later in this section, you'll see another method using the include function workaround we also discussed in Chapter 3.
We're going to place these templates in a file called templates. pp, shown in Listing 4-4, and we'll need to update our site. pp file to import this file.
In Listing 4-4, we've created our template nodes. The first, basenode, is configuration we're going to apply to all nodes. In our basenode we've made use of a fact, $operatingsystem, to include a class based on the operating system of the node; for example, if Facter returned a value of fedora, the fedora class would be included.
We've then defined a default node, which inherits basenode. The default node is applied to any nodes that do not have specific node definitions. We've then created three templates, webserver, dbserver, and mailserver, which all inherit basenode and add classes of their own. At this stage, we've just included a small number of classes into each template.
There is an alternative method of inheriting classes between parent and child nodes that uses the include function. This method is better suited to classes where variable scoping and inheritance is an issue. You can see an example of that method next:
In this alternative method, we've defined a class called baseclass rather than a base node. This class is then included in all subsequent classes including the default node. Additional classes are created that contain the base class and classes required to template other nodes much as we did in Listing 4-4.
Now let's add node definitions for the actual nodes we're going to manage. We're going to create a file called nodes. pp to store them and import that into our site. pp file (as you can see in Listing 4-5).
Note - You can also store node definitions external to Puppet in an LDAP directory. You can read about that at http: //reductivelabs. com/trac/puppet/wiki/LdapNodes. We'll discuss this further in Chapter 6.
In our nodes. pp file, we've created a node definition for each node we're going to manage. We've specified each node by its fully qualified domain name and enclosed the name in single quotes. We haven't added any specific classes to the node definitions and are just inheriting the templates we created in Listing