Holding the Strings

Although the configuration management craze is all over the startup world, many computers in this world are not managed in any way other than by very careful sys admins. I have nothing against them – I am glad they're careful – but I'm not, so I need to cheat: I need config management.

Config management sets up servers. It installs stuff, configures it, and makes sure it is working as you requested. The important word is: you . It sets it up as you requested.

Many admins have learned how to configure a server by installing things manually, so automating the configuration steps can lead to uncertainty and scare a few people away. Puppet takes a little time to set up, but I found that once I understood what it was doing, I felt much more able to trust it – even on legacy servers. In this article, I'll present a really simple and fast guide to getting stuff done with Puppet. Once you've worked through this, you'll be able to install and configure most of the major packages out there. It's really very simple.

A Really Fast Intro to Puppet

A lot of admins are using Puppet for increasingly complex systems. The technology has picked up pace in the past year, but for those of us who have either used it a little or not at all, Puppet requires a heap of learning.

In this whirlwind tour, I want to convince you that you should start using Puppet to manage everything, right now.

This is a tour of the terminology and a high-level description of what Puppet does. Instead of treating this as a fresh installation that is going to run a really complex server, I'll take you through installing Puppet locally and using it to control just a few things. Puppet is a really strong tool and can do great things, but until you trust it, you'll treat it with hesitation.

Configuring a server is largely about writing text to files, and this is one of the many things Puppet can do for you. Puppet takes a description of what should be there, compares it with what is there, and changes it to match. For example, configuring an Apache site might require the existence of the file /etc/apache2/sites-enabled/<my-site>.conf, or you might want to make sure a module is configured as you desire: /etc/apache2/conf.d/<some-module>.conf.

In both cases, all that's required is that file exists and the content is as you want it. Would that be enough to run your site? Probably not, because for this command to work, you'll need to install Apache plus maybe a couple of modules. You also need the document root to exist.

A more complete list of what you need to get your site working is:

• Apache
• Some modules
• A couple of config files
• A file in the document root

Puppet gives you building blocks to set all this up.

Install Puppet

Start by installing the latest version of Puppet. Not all versions have the same options, and you don't want to spend your time translating between the options in different versions, so get the latest if you can. I'm only covering the latest version here, which, at the time of writing, is 2.7.x. Using Ubuntu, you can run the following

do-release-update
apt-get update
apt-get install puppet

to upgrade your server (if desired) and install Puppet. To make sure you have the latest version of Puppet installed, run:

$ puppet --version
2.7.1

This tour focuses on the Puppet command-line tool because I want to make sure you can see the link between what's in the Puppet manifest files and what Puppet does to the server. Understanding this relationship makes working with Puppet on the small and large scale make sense, and it makes Puppet considerably less terrifying.

Create the Puppet Manifest File

To begin, I'll start with a very simple Puppet manifest file. Puppet files are named .pp. The syntax is very simple, looking a bit like JSON, but it is worth noting that a lot of Puppet modules make use of Ruby (including .erb files) and other scripting tools to add more cleverness. The Puppet cli tool runs the .pp files, so when you want to apply a Puppet manifest file to your server, apply it so that, if you create an empty file and run the command

puppet apply <myfile>.pp

Puppet will successfully do absolutely nothing. If you put the following line into the file:

notice("Let's build a server!")

and run it, Puppet says:

$ puppet apply <myfile>.pp
notice: Scope(Class[main]): Let's build a server!
notice: Finished catalog run in 0.01 seconds

Next, create a simple and largely useless file in the same script, drop the file into a home directory, change the manifest file to

file { "/home/dan/hello.md":
  ensure => "present",
  mode    => '0664'
}

and run:

$ puppet apply <myfile>.pp notice: /Stage[main]//File[/home/dan/ hello.md]/ensure: created notice: Finished catalog run in 0.02 seconds

Now, when you take a look, you'll see that /home/dan/hello.md exists.

Using this technique alone, you can now litter the server with all the files you need, but still keep the best settings in one place: in your Puppet project.

This method is hugely useful for deploying to new servers and tracking changes. Say, for example, you run some experiments and find that changing the memory limits on Apache, along with max children improves performance. Instead of remembering this, you would put it in your Puppet files and ensure that your config files are the ones that are in use.