Static IPs and full DNS entries

Stats on the left give a quick overall health status Manually add nodes

and groups using the buttons on the left-hand side

Puppet dashboard showing daily status with our node showing compliant

Using the tabs, you can fi lter all the machines and review all those in a particular state

contents of their fi les and keep them in sync across your estate. In this how-to guide to implementing a basic Puppet setup, we show how to keep all your fi les in sync.

This tutorial covers the basics of creating a basic Puppet server and client setup, through to setting up a few sample confi gurations that can be deployed, applying different confi gurations to different machines and confi guring to clients in a standard manner.

01

Puppet comes in two parts – master and agent nodes. The master node, as the name implies, is in charge. This server holds all the confi g fi le goodness (also known as manifests). For this tutorial we are running Ubuntu 12.04 LTS. Installing Puppet is really straightforward. Choose one of the hosts and install the Puppet master. Type the command:

sudo apt-get install puppetmaster

The setup requires the fi le site.pp to be present (more on what it is later). Do this by using:

sudo touch /etc/puppet/manifests/ site.pp

This installs all the prerequisites of the server.

02

The agents sit on the machines that we want to effectively manage. To install all the components, use the command:

sudo apt-get install puppet

Again, this installs all the requirements for the agent or client. It is suggested that you do not set Puppet to autostart on boot. If you do this, by default the agent will contact the Puppet master and update its confi guration, if needed, every 30 minutes. We are going to run ours manually, so that there is no waiting to see the changes take effect.

03

The next step is to set up the secure communication between the servers. To do this, log into the Puppet agent server and issue the command:

sudo puppetd --server puppetmaster. test.local --waitforcert 60 --test

04

The next step is to enable secure communications between the master and agent.

Type sudo puppetca --list. This will show all the client machines that are trying to connect to the server to service their requests. In order for them to be given access, we must allow them to do so, using the command:

sudo puppet cert --sign clientname

Look at the agent console while doing this and see the handshake that is going on as the machines are joined together.

To test if an agent system can see the server, there is a command that can be used to test.

05

Before all the interesting code creation, you need to understand how Puppet works. All the confi gurations are held in manifest fi les. Manifests are just source fi les are what we can edit. All source fi les end in .pp

The whole point of having a Puppet setup is to ensure that the machines on the site are all the same (we can differentiate between server You will have to edit the server name to refl ect your setup. Leave the --test switch on as it’ll show what is happening in the foreground, making life easier if there’s a need to debug.

If you run the command and you get an error ‘warning: Could not retrieve fact fqdn’, it means you have not set up your DNS properly. It is strongly recommended that this is fi xed before proceeding.

types later!). To help with this aim, Puppet thoughtfully created a site-wide basic confi g fi le called site.pp. This is a basic fi le that is used to create the confi gurations.

To create changes on systems, a manifest is used. A manifest is a number of (or just one) text fi les. Within these manifests are the details that confi gure each part of the system that can be edited and customised. Looking at a very, very basic manifest – it is fairly clear as what it does…

file {'myfile':

path => '/tmp/myfile', ensure => present, mode => 0640,

content => "This could be anything.",

}

The fi rst line is termed a resource. Resources are groups of similar things that can be confi gured to meet a desired standard. Examples of resources include directories, services and fi les. In other words, basically groups of items that share a commonality.

The bit after the fi le resource is what is known as the title. It can be thought of as the unique identifi er. The bits that follow the identifi er are properties and values. To explain it a bit better, the resource ‘fi le’ has a number of properties, such as the path and the fi le rights.

10

How do we group machines together and apply specifi cs? It’s quite straightforward. Use the ‘node’ prefi x. Again it goes into site.pp. An example of adding specifi c machines is:

09

Once the class is created, it can be referenced in the site.pp fi le. To make it work, the classes need to be included in the latter. Go back to site.pp and modify it to include the following text: # /etc/puppet/manifests/site.pp import "classes/*" node default { include webserver }

To import the classes, we just use the import command. The ‘default’ means it is applied to all nodes. Notice how we use ‘include webserver’ and the class is called webserver? Basically, the class can be called by using ‘include’ suffi xed by the class created that is to be referenced.

The default node is applied to all the nodes. It is possible to create nodes with special uses and work only on specifi c nodes. These nodes are the same layout as the default, except they have different names. Again, the include can be used to apply several confi gurations to all new nodes.

08

Putting all these entries in one fi le is going to get messy, right? Also what if there are several different confi gurations? This is where the system can be used to differentiate. Use classes to group together bits of code that need to run, but reference it rather than putting all the code directly into site.pp.

If there was a need for a separate web server confi g and a database confi guration, they’ll have some commonalities and some differences.

So create a folder called classes under the manifest folder.

07

It was mentioned before that we could do useful things with Puppet. For example, it can be made to install an application. This can be done by defi ning the Resource; this time the resource is ‘package’ and using the ensure property followed by ‘ensure’ to make sure it is installed or

06

Manifests can be tested on the local Puppet master machine if you want to (not best practice, but will suffi ce for the tutorial needs). Simply save the above into a fi le, for example test.pp. Once you have done that, use the command:

sudo puppet apply /path/to/test.php

One item by itself is not very useful, so we could group together several items in one fi le. However, it makes more sense to split down the manifests into the jobs they do – or, to use the proper term, classes. That way you can modify the manifests to meet the requirements for multiple groups.

‘absent’ to make sure it is not!

package { "apache2": ensure => "present" }

With a simple addition, that basic start can be built up to autostart. The resource this time is ‘service’ . Following on from the above, add:

service { "apache2": enable => 'true' }

Create a new fi le under classes, call it webserver.pp and put in the following:

class webserver { package { "apache2": ensure => "present"; } package { "php5": ensure => "present"; } service { "apache2": enable => 'true' }}