Authors: Jeffrey McCune James Turnbull
Pro Puppet (5 page)
Puppet will then report its success or failure in applying the resource back to the Puppet master.
INTRODUCING FACTER AND FACTS
Facter is a system inventory tool that we use throughout the book. It returns “facts” about each agent, such as its hostname, IP address, operating system and version, and other configuration items. These facts are gathered when the agent runs. The facts are then sent to the Puppet master, and automatically created as variables available to Puppet.
You can see the facts available on your clients by running thefacterbinary from the command line. Each fact is returned as a key => value pair. For example:
operatingsystem => Ubuntu
ipaddress => 10.0.0.10
We can then use these values to individually configure each host. For example, knowing the IP address of a host allows us to configure networking on that host.
These facts are made available as variables that can be used in your Puppet configuration. When combined with the configuration you define in Puppet, they allow you to customize that configuration for each host. For example, they allow you to write generic resources, like your network settings, and customize them with data from your agents.
Facter also helps Puppet understand how to manage particular resources on an agent. For example, if Facter tells Puppet that a host runs Ubuntu, then Puppet knows to use aptitude to install packages on that agent. Facter can also be extended to add custom facts for specific information about your hosts. We’ll be installing Facter shortly after we install Puppet, and we’ll discuss it in more detail in later chapters.
Puppet’s transactional layer is its engine. A Puppet transaction encompasses the process of configuring each host including:
- Interpret and compile your configuration
- Communicate the compiled configuration to the agent
- Apply the configuration on the agent
- Report the results of that application to the master
The first step Puppet takes is to analyze your configuration and calculate how to apply it to your agent. To do this, Puppet creates a graph showing all resources, their relationships to each other and to each agent. This allows Puppet to work out in what order, based on relationships you create, to apply each resource to your host. This model is one of Puppet’s most powerful features.
Puppet then takes the resources and compiles them into a “catalog” for each agent. The catalog is sent to the host and applied by the Puppet agent. The results of this application are then sent back to the master in the form of a report.
The transaction layer allows configurations to be created and applied repeatedly on the host. Puppet calls this
idempotent
, meaning multiple applications of the same operation will yield the same results. Puppet configuration can be safely run multiple times with the same outcome on your host and hence ensuring your configuration stays consistent.
Puppet is not fully transactional though; your transactions aren’t logged (other than informative logging) and hence you can’t roll back transactions as you can with some databases. You can, however, model transactions in a “noop,” or no operation mode, that allows you to test the execution of your changes without making any actual changes.
The best version of Puppet to use is usually the latest release, which at the time of writing is the 2.6.x branch of releases; newer ones are currently in development. The biggest advantage of the 2.6.x branch of releases onward is their replacement of XML-RPC as a transport layer. The 2.6.x releases instead use REST APIs, resulting in greatly improved performance. The 2.6.x releases are also stable, perform well, and contain a wide of variety of new features and functions unavailable in earlier releases.
WHY DID PUPPET CHANGE VERSION NUMBERING?
If you are familiar with Puppet’s development, you are aware that Puppet jumped release numbers from 0.25.5 straight to 2.6.0. So why did this happen – is the 2.6.0 release 11 times more powerful and stable than the 0.25.5 release? Well, yes and no. The 2.6.0 release included substantial feature additions and removed the last of the XML-RPC transport layer. Importantly though, the jump in release numbering was also an acknowledgment that the previous release numbering was not an accurate reflection of the growth and change in Puppet. In stability and functionality terms, the 0.24.x and 0.25.x releases should have had the decimal place moved to the right. Additionally, since the 0.25.0 release, Puppet has not really been the “pre-V1.0” product that its version numbering would suggest.
Older releases of Puppet, especially releases before the 0.24.x branch of releases, tend to be very poorly featured and contain a number of bugs and issues. They are largely unsupportable and requests for help for with 0.20.x, 0.22.x, and 0.23.x or earlier releases will be largely met with suggestions that you upgrade. We do not recommend you use any of these releases.
Note
This book assumes you are using either a 2.6.x or later release, although most of the material (except where specifically indicated) is supported back to release 0.24.7. It is important to remember that if you use the 0.24.7 or 0.24.8 releases, you will not get the benefit of the performance improvements in the 0.25.x and later releases.
There are a variety of releases, some older than others, packaged for operating systems. The 0.24.x releases are broadly packaged. The 2.6.x and 0.25.x releases are packaged and distributed in newer versions of operating systems and platforms. If you can’t find later Puppet releases packaged for your distribution you have the option of rolling your own packages, backporting, or installing from source (though we don’t recommend the latter – see below).
The most common deployment model for Puppet is client-server. Many people ask if you can have differing releases of Puppet on the master and as agents. The answer is yes, with some caveats. The first caveat is that the master needs to be a later release than the agents. For example, you can have a version 0.24.8 agent connected to a version 2.6.0 master but not a version 2.6.0 agent connected to a 0.24.8 master.
The second caveat is that the older the agent release, the less likely it will function correctly with a newer release of the master. It is highly unlikely that a version 0.20.0 agent will correctly work with a version 2.6.0 master. Generally, the 0.24.x branch of agents will happily connect to and function with 2.6.x and 0.25.x-based masters. Later versions of masters may not be so forgiving of earlier agents and some functions and features may not behave correctly.
Lastly, mixing 2.6.x and later release masters with 0.24.x and earlier agents will mean you won’t get the full performance enhancements available in 2.6.x. The 0.24.x agents will still communicate with the slower XML-RPC transport layer rather than taking advantage of the newer REST interface.
Puppet can be installed and used on a variety of different platforms, including the following:
- Red Hat Enterprise Linux, CentOS, Fedora & Oracle Enterprise Linux
- Debian and Ubuntu
- Mandrake and Mandriva
- Gentoo
- Solaris and OpenSolaris
- MacOS X and MacOS X Server
- *BSD
- AIX
- HP UX
- Microsoft Windows hosts (in versions after 2.6.0 and with only limited support for file resources)
On these platforms, Puppet manages a variety of configuration items, including (but not limited to):
- Files
- Services
- Packages
- Users
- Groups
- Cron jobs
- SSH keys
- Nagios configuration
For Puppet, the agent and master server installations are very similar, although most operating systems and distribution packaging systems divide the master and agent functions into separate packages. On some operating systems and distributions, you’ll also need to install Ruby and its libraries and potentially some additional packages. Most good packaging systems will have most of the required packages, like Ruby, as prerequisites of the Puppet and Facter packages. For other features (i.e., some types of reporting that I’ll demonstrate later in this book), you may also need to install additional packages. When we look at these functions, I’ll let you know what additional packages you’ll need to install.
We’ll also demonstrate how to install Puppet from source, but we don’t recommend this approach. It is usually operationally easier and simpler to use your operating system’s package management system, especially if you are installing Puppet on a large number of hosts.
On Red Hat Enterprise Linux and Red Hat based-derivatives, you need to install some prerequisites (such as the Ruby programming language, the Ruby libraries and the Ruby Shadow library) to allow Puppet to manage users and groups. You can do this with Red Hat’s package management tool, Yum.
# yum install ruby ruby-libs ruby-shadow
Next, to get the latest releases of Puppet, you will need to add the EPEL repository (see sidebar) to your host and then install packages from that repository. You can add the EPEL repository by adding theepel-releaseRPM (.rpm package manager).
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/
epel-release-5-3.noarch.rpm
Note
The EPEL repository is a volunteer-based community effort from the Fedora project to create a repository of high-quality add-on packages for Red Hat Enterprise (RHEL) and its compatible spinoffs such as CentOS, Oracle Enterprise Linux or Scientific Linux. You can find more details on EPEL including how to add it to your host athttp://fedoraproject.org/wiki/EPELandhttp://fedoraproject.org/wiki/EPEL/FAQ#howtouse.
On the master, you need to install thepuppet,puppet-server, andfacterpackages from the EPEL repository.
# yum install puppet puppet-server facter
Thepuppetpackage contains the agent, thepuppet-serverpackage contains the master, and thefacterpackage contains the system inventory tool Facter. As mentioned earlier, Facter gathers information, or “facts,” about your hosts that are used to help customize your Puppet configuration.
On the agent, you only need to install the prerequisites and thepuppetandfacterpackages.
# yum install puppet facter
INSTALLING VIA RUBY GEMS
Like most Ruby-based applications, you can also install Puppet and Facter via Ruby Gems. To do this you’ll need to install Ruby and the appropriate RubyGems package for your operating system. On Red Hat, CentOS, Fedora, SUSE/SLES, Debian and Ubuntu, this package is calledrubygems. Once this package is installed thegemcommand should be available to use. You can then use this command to install Puppet and Facter like so:
# gem install puppet facter
On Debian and Ubuntu we also need to install the Ruby packages as a prerequisite:
# apt-get install ruby libshadow-ruby1.8
Then you can install the required packages for Puppet:puppet,puppetmaster, andfacter. Thepuppetpackage contains the Puppet agent, thepuppetmasterpackage contains the master, and thefacterpackage contains the Facter system inventory tool.
On the master, you need to install this:
# apt-get install puppet puppetmaster facter
On the agent, you only need to install the following packages:
# apt-get install puppet facter