Introducing Puppet - a configuration management DevOps tool

This is the third in a series of blogs looking at DevOps and its key tools. This blog focuseson Puppet - a configuration management tool which enables continuous integration.

QA |
29 October 2015

What is Puppet?

"A movable model of a person or animal that is typically moved either by strings controlled from above or by a hand inside it." -- Google.

Helping you adopt DevOps

In the DevOps model, developers and system operators work closely together throughout the software development process to deploy software more frequently and more reliably. Many new third party and proprietary tools have been developed to support automation, measurement and sharing.

Puppet is another configuration management tool available as part of the DevOps toolbox which enables continuous integration. It uses a master / node setup to ensure that the correct set of files, programs and configuration is present on each of the nodes it looks after. This may not be so useful in a single machine system, or even when you only have a handful of servers to look after. But as the number of servers we need to look after increases, having a single Puppet master controlling what happens on each of the nodes is much more handy.

Puppet comes in two flavours. Enterprise or Open Source. Enterprise systems have access to the web front end for the Puppet master and an automated build tool which will configure everything for you (https://puppetlabs.com/puppet/puppet-enterprise). They also get access to other features that may not be available to the open source users. However, you will need to pay to control more than ten nodes with the Enterprise edition..

Open Source Puppet (https://puppetlabs.com/puppet/open-source-projects) is a collection of different services as well as the core Puppet master. You can chose whether or not you want to include services based on your needs, rather than have everything included at once.

Setting up the Puppet master

There are two modes the enterprise Puppet master can use: monolithic or split. A monolithic system will be able to handle up to 500 nodes. For anything larger you'll want to look at using a split installation, moving the database, console and Puppet master to different machines.

To install the open source Puppet system all the configuration must be handled manually, starting with setting up the repositories for Puppet and ending with configuring the certificates for the machine.

As with most configuration management tools, the Puppet master requires a *nix server, but it can handle nodes of any operating system. We will be using Ubuntu 14.04, the open source Puppet community edition and Puppet 4.2 for these examples.

Step 1: Enable the Puppet repositories

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-trusty.deb

sudo dpkg -i puppetlabs-release-pc1-trusty.deb

sudo apt-get update

Step 2: Install the Puppet server with:

sudo apt-get install puppetserver

Once the server has installed, we need to start the service

sudo service puppetserver start

All the configuration files will be present in the /etc/puppetlabs/puppetserver directory. These can be used to control and change the server settings.

Creating the Puppet agent

The Puppet agent will check in with the master every 30 minutes (by default) on port 8140 and request its current config catalogue. To install the agent we need to do similar steps to installing the Puppet master. Again, this is assuming Ubuntu 14.04.

Step 1: Enable the repositories

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-trusty.deb

sudo dpkg -i puppetlabs-release-pc1-trusty.deb

sudo apt-get update

Step 2: Install the agent

sudo apt-get install puppet-agent

Step 3: Update your hosts file

The agent will need to know where to find the Puppet master, we can achieve this by changing the hosts file to point at the current Puppet master with the name 'puppet'.

echo '52.10.14.46 puppet' >> /etc/hosts

Step 4: Start the Puppet agent

The Puppet agent will attempt to talk to the Puppet master and request a certificate. To start the agent use the following line:

You can create a symbolic link between the Puppet executable and /usr/bin if you want to call Puppet directly.

sudo ln -s /opt/puppetlabs/bin/puppet /usr/bin/puppet

The check in interval can be changed on the Puppet agent with:

puppet config set runinterval xxx

The time given is in seconds, so the default is 1800. You can see the currently configured time with:

puppet agent --configprint runinterval

Connecting the two - accepting certificates

So the Puppet master has been set up and is waiting for nodes, the agent has requested a certificate. The next step is to accept the certificate on the master. This can be automated, but it isn't recommended. If you trust your firewall rules, then you can configure the Puppet master to only accept traffic on port 8140 from known machines (for example, an IP range) and then auto sign everything. But it's not considered secure

To manually accept a certificate we need to look at the Puppet master again.

So far, so good. We have the two communicating. Now we need to tell the Puppet agent to actually do something!

Puppet Modules

Puppet uses modules and manifests to describe how a machine should be configured. These are collections of files written in a ruby-like syntax (similar to the chef recipe) which describe the ideal state of the node.

Modules are stored in the puppetlabs directory: /etc/puppetlabs/code/modules. We're going to make a simple webserver. In the modules directory we need to create the directory structure required.

cd /etc/puppetlabs/code/modules

mkdir webserver

cd modules/webserver

mkdir files manifiests tests

You should have the following structure:

root@ip-172-31-36-134:/etc/puppetlabs/code/modules# tree

.

└── webserver

├── files

├── manifests

└── tests

Now we're going to fill this up. First create a file in the files directory called 'index.html' and add some html code to it.

In the manifests directory, create a file called init.pp. This is the default file used to look up what to do to a machine. Add the following to the file:

The class uses the same name as the base directory, this is what our module is called. The case statement works out which operating system we are on and ensures that the apache can be installed via both yum and apt-get (they have different names). Then it goes on to ensure two directories are present (/var/www and /var/www/html) and to copy in the index file to that directory. Finally, the apache service is started.

Finally we want to add a test to see if our module will work. Create another file called init.pp, this time in the tests directory and add the following line:

include webserver

This will include our module when we are running the tests.
At the end of this you should have:

root@ip-172-31-36-134:/etc/puppetlabs/code/modules# tree

.

└── webserver

├── files

│ └── index.html

├── manifests

│ └── init.pp

└── tests

└── init.pp

You could have generated the Puppet module with their new tool:
puppet module generate < USERNAME > < MODULE NAME >

This sets up the structure for you and ensures everything is in the correct place. Also, the tests directory is being deprecated and so you should use "examples" instead. But this example works for now, who knows what else will change with the new version of Puppet!

Assign the manifest to the node, watch the webserver configure, save the world (okay, maybe not that last part...)

In Puppet enterprise we can do this via the GUI, but that is backed up by a set of configuration files which we can manipulate in the community version of Puppet.

The Puppet master requires a site.pp file which assigns different classes to nodes. This is, by default, located in the /etc/puppetlabs/code/environments/production/manifests/ directory.

Puppet training from QA

Talk to our team of learning experts

Every business has different learning needs. QA has over 30 years of experience in combining the highest quality training with the most comprehensive range of learning services, ensuring the very best fit for your organisation.