Puppet Tutorial for Linux (Part I): Powering up with Puppet

Puppet tutorial series

(Linux configuration management)

• Part 1: Powering up with Puppet 2.6
• Part 2: Client and Server

Puppet tutorial part 1: Powering up with Puppet 2.6

This Linux Puppet tutorial will help you install Puppet for the first time and start managing your servers. Server configuration management (CM) is big news in the IT world these days. Rightly so, because Linux automation, devops and CM tools like Puppet and Chef can save you an enormous amount of time and money and help you build a really reliable and automated Linux infrastructure. In this tutorial, I’ll show you how to set up Puppet on Linux.
If you’re a sysadmin, or anyone else who manages a bunch of servers, CM tools can help you create patterns or recipes which you can use to build lots of identical servers, or cloud instances, or re-use in different places and for different applications. Automating Linux servers is a snap with Puppet. Puppet can manage thousands of servers as easily as just one or two - but let’s start with one or two!
If you’re a developer, Linux configuration management lets you write code which describes how servers should be set up - saving you the time and effort of doing it manually, and letting you create large, load-balanced groups of interchangeable servers which are guaranteed to be identically configured.

Installing Puppet

So much for the sales pitch. Let’s take a look at the steps required to get up and running with your first Puppet install (we’ll come to Chef in a later article).

Puppet example

For this Puppet example install, we’re going to assume you’re using an Ubuntu Linux machine. You can use a virtual machine for this, running in VMWare, VirtualBox or Xen if you like, or just a spare Linux box that happens to be lying around the office.
First, we need to install Puppet itself (you’ll need to log in as root or sudo su - on your server):

# apt-get install libopenssl-ruby rdoc libopenssl-ruby1.8 libreadline-ruby1.8 libruby1.8 rdoc1.8 ruby1.8
# wget http://puppetlabs.com/downloads/facter/facter-1.5.8.tar.gz
# wget http://puppetlabs.com/downloads/puppet/puppet-2.6.4.tar.gz
# tar xvzf facter-1.5.8.tar.gz
# cd facter-1.5.8
# ruby install.rb
# cd ..
# tar xvzf puppet-2.6.4.tar.gz
# cd puppet-2.6.4
# ruby install.rb
# puppetd --version
2.6.4

There are gems and packages for Puppet, but for the sake of simplicity we’re installing from source; this also guarantees that you’ll get an up-to-date version, as Puppet is under active development and there are frequent new releases.

Creating a Puppet configuration

Next, we need to give Puppet something to do. The code snippets that tell Puppet how a machine should be configured are called manifests - like a shipping manifest, it tells Puppet what things (packages, users, files and other resources) should be present, and what they should contain.
The first thing to do is create a directory structure to hold your manifests. Puppet itself is not too fussy about how these are laid out, but we’re going to follow the Puppet community’s best practices document and use the recommended layout there. To save time, you can download a (nearly) empty template layout. To use this:

# cd /etc
# wget http://bitfieldconsulting.com/files/powering-up-with-puppet.tar.gz
# tar xvzf powering-up-with-puppet.tar.gz

You should now have an /etc/puppet directory with two subdirectories: modules and manifests. Roughly speaking, modules is where Puppet code lives, and manifests is where we specify which code should be applied to each machine under Puppet’s control.

Starting the Puppetmaster

Puppet comes in two parts: a server (the Puppetmaster) which listens for connections from clients and then tells them what manifest they should have, and a client program, which runs on each machine under Puppet control and connects to the Puppetmaster to get its manifest.
In our example, we’re running the master and client on the same machine, so let’s start the server:

# puppet master --mkusers

Running the Puppet client

With the Puppetmaster running, we can now check that everything is working as it should by running the client:

# puppet agent --test --server=`hostname`
info: Caching catalog for localhost.localdomain
info: Applying configuration version '1256130640'
notice: Finished catalog run in 1.23 seconds

Creating Puppet classes

While technically we have just applied a Puppet manifest to the machine, it’s not a very interesting one, as it does nothing at all. Let’s create a manifest that manages a simple service: NTP (the Network Time Protocol). NTP is a daemon which keeps the machine’s clock synchronised with reference servers on the Internet.
First we’re going to create a class for the NTP service (if you haven’t done any object-oriented programming, a class is just a named chunk of code which we can refer to).
I’ve created a (nearly) empty template for you for the NTP class, so go ahead and edit the file /etc/puppet/modules/ntp/manifests/ntp.pp. Currently it looks like this:

class ntp {
}

Change it to this:

class ntp {

    package { "ntp": 
        ensure => installed 
    }

    service { "ntp":
        ensure => running,
    }
}

And save the file. We’ve now created a Puppet manifest which will manage the NTP daemon (ntp).

Creating Puppet nodes

Because Puppet can manage many machines at once, we still need to tell it to apply the NTP manifest to this machine. To do that, edit the file /etc/puppet/manifests/nodes.pp. You’ll see a template that looks like this:

node myserver {
}

Change it to this:

node myserver {
    include ntp
}

(Replace myserver with the name of your machine - that is, the output of hostname -s.)
When Puppet runs, it looks for a node definition that matches the name of the client machine, and applies all the classes that it finds listed there with include.
You’ve now told Puppet that the server myserver (or whatever your machine is named) should have the NTP manifest applied to it.

Applying changes with Puppet

When you run Puppet again:

# puppet agent --test --server=`hostname`
info: Caching catalog for localhost.localdomain
info: Applying configuration version '1256130643'
notice: //ntp/Service[ntp]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.94 seconds

What happened here? Puppet looked up the manifest for myserver and found this:

    package { "ntp": 
        ensure => installed 
    }

    service { "ntp":
        ensure => running,
    }

This says that the package ntp should be installed, and the service ntp should be running. Your system may or may not have ntp already installed, but if not, Puppet will install it. Puppet checks to see if the service is started, and if it’s not, it starts the service for you. If you run Puppet again now:

# puppet agent --test --server=`hostname`
info: Caching catalog for localhost.localdomain
info: Applying configuration version '1256130643'
notice: Finished catalog run in 0.66 seconds

you’ll see that Puppet does nothing, because the manifest is satisfied.

Puppet manifests are declarations

Puppet manifests are not a set of instructions, in the way that a shell script or a Ruby program is. They’re a declaration of how the world should be (or that part of it under Puppet’s control, anyway). If reality differs from the manifest, Puppet takes steps to adjust reality.
This means that Puppet isn’t just useful for building machines. It can also check them regularly to make sure that nothing important has changed, and if it has, to correct it. If you stop the NTP service manually and then run Puppet again, you’ll find Puppet restarts it.
Conversely, if you decide you no longer want NTP running on your machines, you can change the word running to stopped, and Puppet will enforce this policy on every machine that includes the NTP manifest (which could be hundreds or even thousands of servers).
Imagine making a change like that to a large production network by logging in to each machine in turn and running the necessary commands manually. Not only would it be tedious and time-consuming, but if you got interrupted halfway through, you might not remember which machines you’d fixed, and your whole network would be in an inconsistent and unknown state.

In our next thrilling episode

You’ve just powered up your system with Puppet! Next time in Puppet Tutorial part 2: Client and Server, we’ll look at how to set up Puppet to control multiple machines. If you’ve got any comments on this Puppet tuto, do let me know!

Puppet links

• Puppet Resources - our compendium of the best Puppet documentation and tutorials on the web
• Introduction to Puppet
• Puppet Wiki - the authoritative and accurate (or if not, at least definitively inaccurate) source for all things Puppet.

Puppet books

If you’re excited about Puppet and want to learn more, may I modestly recommend the Puppet 2.7 Cookbook? The Puppet 2.7 Cookbook takes you beyond the basics to explore the full power of Puppet, showing you in detail how to tackle a variety of real-world problems and applications. At every step it shows you exactly what commands you need to type, and includes full code samples for every recipe.