Puppet and you
Back in January, I gave a presentation for the local LUG group (CIALUG) and while it was nice to put it all into one presentation, I’d like to go back and break down the various aspects of the presentation and show off what Puppet can do in your organization.
What is it?
Puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. The user describes system resources and their state, either using Puppet or Ruby DSL (domain-specific language). This information is stored in files called “Puppet manifests”. Puppet discovers the system information via a utility called Facter, and compiles the Puppet manifests into a system-specific catalog containing resources and resource dependency, which are applied against the target systems and any actions taken to remediate the system to the desired state will be reported. (Source: WikiPedia)
In English Please?
Puppet makes it so administrators can make a change in one place, and it is automatically updated on configured systems.
Basically, DRY (Don’t Repeat Yourself) in its truest sysadmin form.
Why do I need it?
OK, So maybe you have a small environment with 5 servers. Say you hired a new guy and need to update the sudoers files on all those boxes. Not a huge deal, 5 minutes per server and done in under a half hour. But, what if it was 5 minutes and done. DONE! now that other 20 minutes is doing other things, other projects, moving the company forward!
Now imagine if you control hundreds if not thousands of servers, it becomes painfully obvious real fast on why this is needed. The server to admin ratio can go way up with this level of automation.
Getting Started
First off, before jumping first in I recommend you read the documentation and Puppet provides some pretty good stuff at docs.puppetlabs.com. If you rely only on this blog, well, I’ll leave you hanging in places for sure. I’m here to give highlights, not dive that deep in all areas.
Design
Now time for the design of your implementation. How do you want this thing laid out? What makes the most sense for you and your network? The most common layout is to have a master server / client setup. That’s what we use at the office and its working pretty good for us. Obviously, the most important thing there is to make sure that your master server is both accessible and secure. We have a few private networks that work out pretty well for us but I’ve also run this on a more diverse spread out environment across the internet. With the proper firewall rules and SSL signing, I’ve been able to secure the environment pretty well so only the servers that need the access get the access.
Now for the software
Most distributions out there are including puppet in their repositories. If you run the the AWS AMI image, its available right away for you to install. If you are running CentOS, you’ll need to install the EPEL repo before you can install the open source version of puppet.
And of coarse, you can jump both feet into the Enterprise version if you want by downloading directly from puppetlabs.com.
Our Setup
For the posts that I’m going to be writing, we’re going to work with the assumption of a master server and all the clients checking into it. On our master server, we simply need to install the master server software and the client.
If you did a
you probably saw puppet-dashboard as an available package to install. I’m going to leave that out for the time being as it will be covered in a separate post.
Once installed, you will see the puppet configuration files in your /etc/puppet directory.
For our clients, we obviously won’t need the master server software so your installation line is simply:
Next Up
Our next part will be how to configure your client and connect to your puppet server.
