Setting up a LAMP box with Puppet

In the last weeks, we saw how VirtualBox can build empty virtual machines, provided at the hardware level. We also configured a Linux virtual server with Vagrant, which is able to quickly build a virtual machine from a template (called box).

This time I want to expand the usage of Puppet for provisioning a machine (often virtual) with software: this task covers installation, configuration, and lifetime management of services; but also adding user accounts or cron jobs. In the languaghe of Puppet, it's all about providing resources.

Puppet offers a declarative language for resources: by describing what should be installed, or present in the filesystem, or running, you get Puppet to define all the resources needed, install packages and so on.

In this primer, we will use Puppet in serverless mode, on single machine. The goal is to install a LAMP server, providing an environment containg Apache, PHP 5 and a MySQL server. Let's see what Puppet can do!

The starting point

The Learning Puppet VM (which requires one-step registration for download) is a virtual CentOS Linux instance that already contains Puppet. I suggest you to use this machine for experimentation as you can always throw it away in case of failures (while it's not simple to do so with your own system). I worked with the VirtualBox version, but there is also a VMware one.

One step to perform before starting the machine is to configure networking. I chose a bridged adapter in VirtualBox settings, since it's the easiest choice. The machine will pick up an IP address in the same subnet as the host (and you will be able to access the machine via SSH for copying and pasting manifest pieces after having installed openssh-server).

After starting, you will also need to setup the right keyboard if you're not on a US one: put "it" or your national code in /etc/sysconfigl/keyboard.

You can login with the user root and the password puppet.

The puppet command

The puppet command line utility is already installed. The resource types we'll need are the file, package, and service ones, but there are more available. puppet describe -s file will print an help page for each of them.

puppet apply manifest.pp

will install a manifest, a file containing the description of a system. Instead of using puppet directly to change the state of the system by writing many calls into a .sh file, we invert the flow and write a manifest which we will pass to puppet everytime we need. Applying the configuration is idempotent: reapply it as many times as you want (it's declarative.)

Writing the manifest

In a manifest, the first step is specifying a set of packages, wiich yum or dpkg or the current utility will install for you:

package {'name':
  ensure => present,
}

These configurations feature the name of the package as the key for referring to them after the definition. The trailing commas are optional, like in PHP and JavaScript.
You should also define which services you want to run now, and at startup:

service {'httpd':
  ensure => running,
  enable => true,
}

A key issue is the ordering of the installation steps. For example, if we want to install or just restart an Apache daemon we'll have to make sure to do so after the installation of PHP (otherwise .php files won't be interpreted):

require => File['/tmp/test1']

specifies that the file resource should be created before the service is started.

before => Service['...']

is the inverse relationship. However, in the case of service resources, the notify and subscribe options are more useful as they specify that the service should be restarted after the attached event (being it a file creation or else).

The actual manifest for a LAMP stack

In this case, we want to install PHP, Apache and the MySQL server. I tested the success of applying this configuration with a phpinfo script and by running ps -A. This manifest relies heavily on the package names of CentOS, so you may have to change their names if you want to use a different virtual machine.

package {'php':
  ensure => present,  
  before => File['/etc/php.ini'],
}

file {'/etc/php.ini':
  ensure => file,
}

package {'httpd':
  ensure => present,
}

service {'httpd':
  ensure => running,
  enable => true,
  require => Package['httpd'],
  subscribe => File['/etc/php.ini'],
}

package {'mysql-server':
  ensure => 'present',
}

service {'mysqld':
  ensure => running,
  enable => true,
  require => Package['mysql-server'],
}

Conclusions

Puppet seems a nice tool for managing complex configuration of packages, services and configuration files on multiple machines that has to be kept in sync. Actually I only scratched the surface of what it can do.

I like particularly the idempotency of manifests, that can be applied multiple times. Their declarativity approach is powerful and does not mean that their power is limited: you can always include exec resources to extend them.

One problem I note is that Puppet gives a false sense of portability of our configuration: while you're writing a manifest at an higher level of abstraction than bash scripts, the manifest does not run unmodified even between two Linux distributions (such as CentOS and Ubuntu). The package and service names are borrowed from the underlying OS: there is nothing magic (it's probably a good thing.)