Distributing Puppet manifests

So far in this book we've only applied Puppet manifests to one node, using puppet apply with a local copy of the manifest. To manage several nodes at once, we need to distribute the Puppet manifests to each node so that they can be applied.

There are several ways to do this, and as we saw in manifests and distributes the catalog (the desired node state) to all nodes.

Another way to use Puppet is to do without the master server altogether, and use Git to distribute manifests to client nodes, which then runs puppet apply to update their configuration. This stand-alone Puppet architecture doesn't require a dedicated Puppet master server, and there's no single point of failure.

Both agent/master and stand-alone architectures are officially supported by Puppet, and it's possible to change from one to the other if you decide you need to. The examples in this book were developed with the stand-alone architecture, but will work just as well with agent/master if you prefer it. There is no difference in the Puppet manifests, language, or structure; the only difference is in the way the manifests are applied.

All you need for a stand-alone Puppet architecture is a Git server which each node can connect to and clone the repo. You can run your own Git server if you like, or use a public Git hosting service such as GitHub. For ease of explanation, I'm going to use GitHub for this example setup.

In the following sections, we'll create a GitHub account, push our new Puppet repo to GitHub, and then set up our virtual machine to automatically pull any changes from the GitHub repo and apply them with Puppet.

Creating a GitHub account and project

If you already have a GitHub account, or you're using another Git server, you can skip this section.

1. Browse to https://github.com/
2. Enter the username you want to use, your email address, and a password.
3. Choose the Unlimited public repositories for free plan.
4. GitHub will send you an email to verify your email address. When you get the email, click on the verification link.
5. Select Start a project.
6. Enter a name for your repo (I suggest puppet, but it doesn't matter).
7. Free GitHub accounts can only create public repos, so select Public.

   Tip

   Be careful what information you put into a public Git repo, because it can be read by anybody. Never put passwords, login credentials, private keys, or other confidential information into a repo like this unless it is encrypted. We'll see how to encrypt secret information in your Puppet repo in Chapter 6, Managing data with Hiera.

8. Click Create repository.
9. GitHub will show you a page of instructions about how to initialize or import code into your new repository. Look for the https URL which identifies your repo; it will be something like this (https://github.com/pbgtest/puppet.git):
   

Pushing your repo to GitHub

You're now ready to take the Git repo you created locally earlier in this chapter and push it to GitHub so that you can share it with other nodes.

1. In your repo directory, run the following commands. After git remote add origin, specify the URL to your GitHub repo:

   git remote add origin YOUR_REPO_URL
   git push -u origin master
   

2. GitHub will prompt you for your username and password:

   Username for 'https://github.com': pbgtest
   Password for 'https://pbgtest@github.com':
   Counting objects: 3, done.
   Writing objects: 100% (3/3), 262 bytes | 0 bytes/s, done.
   Total 3 (delta 0), reused 0 (delta 0)
   To https://github.com/pbgtest/puppet.git
    * [new branch]      master -> master
   Branch master set up to track remote branch master from origin.

3. You can check that everything has worked properly by visiting the repo URL in your browser. It should look something like this:
   

Cloning the repo

In order to manage multiple nodes with Puppet, you will need a copy of the repo on each node. If you have a node you'd like to manage with Puppet, you can use it in this example. Otherwise, use the Vagrant box we've been working with in previous chapters.

Run the following commands (replace the argument to git clone with the URL of your own GitHub repo, but don't lose the production at the end):

cd /etc/puppetlabs/code/environments
sudo mv production production.sample
sudo git clone YOUR_REPO_URL production
Cloning into 'production'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
Checking connectivity... done.

How does this work? The standard place for Puppet manifests in a production environment is the /etc/puppetlabs/code/environments/production/ directory, so that's where our cloned repo needs to end up. However, the Puppet package installs some sample manifests in that directory, and Git will refuse to clone into a directory that already exists, so we move that directory out of the way with the mv production production.sample command. The git clone command then recreates that directory, but this time it contains our manifests from the repo.