Automated Configuration Management with Puppet

Puppet is a systems management platform that enables sysadmins and developers to standardise the deployment and management of the IT infrastructure. This blog entry shows you how to automate your configuration management using Puppet.

The problem – configuring servers

When working in a software development shop, either as a developer or a sysadmin, you often need to use and configure many types of servers. Every development team may require a test server, usually a *NIX box running Tomcat or Jetty, along with a database server, user accounts and other services and configuration. Sysadmins probably will configure file servers, mail servers, build servers, version control servers and so on.

If you only have a few machines you can use a golden image, a preconfigured virtual machine image, along with some manual configuration or scripting. However, when you have a lot servers, all requiring very different configuration, this way of working can become inflexible, too costly, time-consuming and error-prone. In this post I will show you how a great tool called Puppet can be used to make this process of configuring servers more robust, modular, flexible and a hell of a lot more fun!

Enter Puppet

Puppet is a ruby-based configuration management tool for automatically configuring machines, also called puppets. In puppet lingo the machines you want to configure act as clients to the puppetmaster. The puppets and puppetmaster both run the puppet daemon and use the same puppet distribution albeit with a different configuration. The puppetmaster contains the configuration manifests for our puppets written in the ruby-ish Puppet DSL. Using this language we use terms as host, service, package, file and many others to easily configure servers with a few lines of code. The puppets will poll the puppetmaster every half hour by default to see if the configuration has changed and if it has update themselves. It’s possible to configure this interval in puppet.conf and you can also ‘kick’ puppets to update themselves immediately.

Show me the code!

Let’s say you want to run apache httpd on one of your nodes. You need to write a puppet manifest or module which is stored on the puppet master, usually under /etc/puppet
This manifests consists of several declartions. First we need to install the package, run the service, provide it with the correct httpd.conf file and let it restart if this file changes. Check it out!

Installing the apache package

package { httpd: ensure => installed }

Starting the service

With the snippet below we declare that the apache service should be running and that it should restart if the httpd.conf, stored on the puppetmaster is changed.

service { "apache2":
  ensure => running,
  subscribe => File["puppet:///apache/httpd.conf"],
}

Adding users and groups

Users and groups can be created easily in a single line.

group { apache: gid => 1001 }
user { apache: gid => 1001 }

Bundling it together

Puppet allows you to create classes to bundle related configuration.

class apache {
  package { httpd: ensure => installed}
  service { httpd:
    ensure => running,
    require => Package[httpd],
    subscribe => File["puppet:///apache/httpd.conf"]
  }
 group { apache: gid => 1001 }
 user { apache: gid => 1001 }
}

Node configuration

Besides the configuration manifests you need a node configuration. This specifies what will be configured on each machine. So to configure the apache module on one node we specify the following

node 'node1.example.com' {
  include apache
}

Reusable Puppet Modules

This blog is to show you the potential of puppet. Of course, the above examples do not represent a complete configuration for httpd. However, even though writing puppet manifests requires an investment of time and effort, once written, these manifests can be used over and over again for new nodes. Also, to save time, you can reuse puppet modules, even ones that have been written by others. Puppetforge and Github are good sources with ready-to-use puppet modules for all sorts of services.

Puppet in practice

Here are some practical things that need to happen in order for you to use puppet:

• Certificates – Both the puppetmaster and the puppets need to exchange certificates. See Puppet Certificates & Security
• Version control – It’s good practice to version control your puppet master and its modules
• Testing your manifests with cucumber-puppet

References

As mentioned above, this blog entry just shows you the tip of the iceberg. Check out the resources below to learn more about puppet.

• Official Documentation by Puppetlabs
• Puppet Tutorial by Bitfield Consulting Excellent blog with lots of info on puppet
• Automated Configuration Management with Puppet Slides from my recent presentation at the JTeam Tech Meeting