Getting ready

If your Puppet manifests aren't already in Git, follow the steps in Using version control for your Puppet manifests in this chapter.

How to do it...

How it works...

Instead of contacting the Puppetmaster to receive their compiled manifest, each client compiles its own from a local copy of the manifest source. This is updated every time you push updates from the Git server (or from your working checkout). This is more efficient with respect to network bandwidth, as clients don't have to contact the Puppetmaster on every run. It also eliminates a single point of failure, as clients can be updated from anywhere.

Using a decentralized Puppet architecture based on Git as outlined here gives you a great deal of flexibility. You can configure access controls and permissions using SSH keys, and allow each client machine or group only as much access as it needs. Manifests for a database server group, for example, can be made available only to those machines that need it.

While it requires some extra work to set up, and is not necessary for most small organizations, this way of deploying Puppet gives you extra flexibility and control for the most demanding environments.

There's more...

If you want to have Puppet apply the changes every time they are pushed, you can edit the post-receive script to do this, or take any other action you want. Alternatively, you could run Puppet manually, or from cron as described earlier in this chapter— just run puppet apply.

There are a few disadvantages to using a Git-based architecture: you can't use advanced Puppet features such as external node classifiers or stored configurations. However, when you need to scale to a large number of nodes, this is the simplest way to do it.

You can find a more detailed discussion of this architecture in Stephen Nelson-Smith's article at http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control.

See also