AWS Puppet Deployments

AWS Puppet for streamlined deployments

If you’re interested in automating and simplifying control over your application deployments, then Puppet – in any of its iterations – is probably a good place to start. And an AWS Puppet project can present a particularly good match.

Don’t think of this as an all-in quick start guide. The complexity of the kinds of network infrastructure that AWS Puppet deployments are designed to manage makes the word “quick” pretty much incompatible with the word “guide.” However, I believe that this post should be useful as an orientation, to introduce you to the kind of things Puppet can do and some of the ways to do them. By the way, even though Puppet is obviously not an AWS product (it’s actually the brainchild of PuppetLabs),

I’m going to use the phrase “AWS Puppet” in this post as a convenient way to describe the ways they can work together.

AWS Puppet Labs LogoHow Puppet works

Let’s say you’re running ten or fifteen Ubuntu web servers within an AWS VPC. The odds are that you will need to make configuration and content changes to each of these machines fairly often, but the process – especially as the number of servers grows – can be tedious.

Using Puppet, you can set up each server as an Agent that will, every thirty minutes or so, query a file called a manifest that lives on a separate AWS Puppet Master machine. If the manifest file, as it relates to a specific Agent, has changed since the last query, its current instructions will be immediately executed on that Agent.

This way, you can precisely and automatically control the ongoing configuration of any number of virtual (or actual) machines – running Linux/Unix or Windows – from a single file. It couldn’t get more simple. But that doesn’t mean it can’t get complicated.

Packages – AWS Puppet Master

Once you’ve created the EC2 instance that will serve as your Puppet master, you’ll have to install a Puppet package. Even if you’re limited to the open source version, there is still quite a selection of packages to choose from.

We’ll assume that we’re working with an AWS Ubuntu 14.04 AMI. For simplicity, I’ll use the puppetmaster-passenger package that’s found in the apt-get repositories. This package comes out of the box with everything you’ll need for connectivity, including Apache.

sudo apt-get update
sudo apt-get install puppetmaster-passenger

Puppet Agent

You’ll also have to install the Puppet Agent on each server – or Node – you’d like to be automatically controlled by your AWS Puppet Master. Once again, there is a choice of packages, but we’ll go with the apt-get repository:

sudo apt-get update
sudo apt-get install puppet

You’ll have to enable the Puppet Agent by editing its puppet file:

sudo nano /etc/default/puppet

…So that the START line looks like this:



We’re not even going to begin discussing many of the basic configuration elements you would need for a production deployment. Therefore, take it as given that you’ll have to properly configure your DNS, NTP, and SSL certificates. Here’s a great resource that addresses these issues in some detail.

You could, by the way, set up your DNS services using an old and reliable open source package like Unbound but, since we are working with AWS infrastructure, why ignore the obvious integrated solution: Route53?

You will probably also want lock the release version of each installed AWS Puppet package – both on the Master and on each Agent – to prevent unexpected version updates…which can have unpredictable results.

AWS Puppet Files

The file that matters the most for Puppet (on an Ubuntu installation) is /etc/puppet/puppet.conf. Here’s an example of what it might look like:

# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

This config file tells Puppet (and you) where to find key system resources, including Puppet’s log files and SSL certificates.

The files that do all the heavy lifting for Puppet are called Manifests, and use a .pp extension. Here’s a simple example:

file {'/tmp/local-ip':
  ensure  => present,
  mode    => 0644,
  content => "My Public IP Address is: ${ipaddress_eth0}.\n",

This manifest will create a file named local-ip in the /tmp directory, assign it read-only permissions for everyone except the owner (0644), and populate it with a script that will output the public IP address of the eth0 interface from whichever machine it’s running on.

Common Puppet Commands

Start a manifest file:

puppet apply web-servers1-2.pp

Create a new group:

sudo puppet resource group puppet ensure=present

Create a new user:

sudo puppet resource user puppet ensure=present gid=puppet shell='/sbin/nologin'

Specify a single Node (or group of Nodes)

You can apply particular configuration details to specific Nodes within a general manifest file using the “node” declaration:

node 'web-server1' {
  include apache
  class { 'ntp':
    enable => false;
  apache::vhost { '':
    port    => '80',
    docroot => '/var/www/example',
    options => 'Indexes MultiViews'.

(The above example also shows how to deploy pre-baked modules provided by either the Puppet team or the user community.)

Launching manifests

Finally, you can create and run manifests directly from the command line. You might, for instance, want to create a file with local IP information (using our example from above). Assuming that we named that file local-info.pp, and saved it to the AWS Puppet Manifests directory, you could run it using:

sudo puppet apply /etc/puppet/manifests/local-info.pp

If you want to learn more about Puppet, take a look at Cloud Academy’s Getting Started with Puppet hands-on course with exercises every step of the way to give you experience using Puppet.

Cloud Academy