In this chapter, we will cover how to deploy Puppet in a centralized and decentralized manner. With each approach, we'll see a combination of best practices, my personal experience, and community solutions. We'll configure and use both PuppetDB and Hiera. PuppetDB is used with exported resources, which we will cover in Chapter 5, Users and Virtual Resources. Hiera is used to separate variable data from Puppet code. Finally, we will learn about Git and see how to use Git to organize our code and our infrastructure. Because Linux distributions, such as Ubuntu, Red Hat, and CentOS, differ in the specific details of package names, configuration file paths, and many other things, for reasons of space and clarity, the best approach for this book is was pick one distribution (CentOS 7) and stick to that. However, Puppet runs on most popular operating systems, so...

It's a great idea to put your Puppet manifests in a version-control system, such as Git or Subversion (Git is the de facto standard for Puppet). This gives you several advantages:

• You can undo changes and revert to any previous version of your manifest
• You can experiment with new features using a branch
• If several people need to make changes to the manifests, they can make them independently, in their own working copies, and then merge their changes later
• You can use the Git log feature to see what was changed and when (and by whom)

In this section, we'll import your existing manifest files into Git. If you have created a Puppet directory in a previous section, use...

Puppet is a configuration management tool that can be used to configure and prevent configuration drift in a large number of client computers. If all your client computers are easily reached via a central location, you may choose to have a central Puppet server control all the client computers. In the centralized model, the Puppet server is known as the Puppet master. Originally, the Puppet master ran a service named master, it now runs a service named puppetserver, but the name has remained. We will cover how to configure a central Puppet master later.

If your client computers are widely distributed or you cannot guarantee communication between client computers and a central location, then a decentralized architecture may be a good fit for your deployment. In the next few sections, we will see how to configure a decentralized Puppet...

We'd like to make it as quick and easy as possible to apply Puppet on a machine; for this, we'll write a short script that wraps the puppet apply command with the parameters it needs. We'll deploy the script where it's needed, with Puppet itself.

Follow these steps to create the papply script.

1. In your Puppet repo, create the directories needed for a Puppet module:

t@mylaptop ~$ cd puppet/modules
t@mylaptop modules$ mkdir -p puppet/{manifests,files}

2. Create the modules/puppet/files/papply.sh file with the following contents:

#!/bin/sh 
cd /usr/local/git/cookbook
sudo -u git git pull -q origin master
sudo /opt/puppetlabs/bin/puppet apply /usr/local/git/cookbook/manifests...

You can do a lot with the setup you already have: work on your Puppet manifests as a team, communicate changes via a central Git repository, and manually apply them on a machine using the papply script.

However, you still have to log in to each machine to update the Git repo and rerun Puppet. It would be helpful to have each machine update itself and apply any changes automatically. Then, all you need to do is push a change to the repo, and it will go out to all your machines within a certain time.

The simplest way to do this is with a cron job that pulls updates from the repo at regular intervals and then runs Puppet if anything has changed. Since our papply script already pulls the latest changes, we can just schedule cron to run the papply script.

Previous versions of this book used Rakefiles to bootstrap Puppet. The problem with using Rake to configure a node is that you are running the commands from your laptop; you assume you already have ssh access to the machine. Most bootstrap processes work by issuing an easy-to-remember command from a node once it has been provisioned. In this section, we'll show you how to use bash to bootstrap Puppet with a web server and a bootstrap script.

Install httpd on a centrally accessible server and create a password-protected area to store the bootstrap script. In my example, I'll use the Git server I set up previously, git.example.com. Start by creating a directory in the root...

A configuration management tool such as Puppet is best used when you have many machines to manage. If all the machines can reach a central location, using a centralized Puppet infrastructure might be a good solution. Unfortunately, Puppet doesn't scale well with a large number of nodes. If your deployment has less than 4,000 servers, a single Puppet master should be able to handle the load, assuming your catalogs are not complex (take less than 10 seconds to compile each catalog). If you have a larger number of nodes, I suggest a load-balancing configuration, described in Mastering Puppet.

A Puppet master is a Puppet server that acts as an X509 certificate authority for Puppet and distributes catalogs (compiled manifests) to client nodes. The puppet master runs the puppetserver service. Puppetserver is a JRuby application running...

By default, Puppet will create an SSL certificate for your Puppet master that contains the fully-qualified domain name of the server only. Depending on how your network is configured, it can be useful for the server to be known by other names. In this recipe, we'll make a new certificate for our Puppet master that has multiple DNS names.

Install the Puppet master package if you haven't already done so. You will then need to start the Puppet master service at least once to create a certificate authority (CA).