Puppet

We’re onto post 3 of our Puppet series. We have a master server, a client and we’ve made a connection. Its time to start getting into the real power of puppet and write our first module.

Module Make Up

So what makes up a module. They can be as simple as an init.pp file or as complex as having directories of files, templates and just about everything else under the sun there to help control your infrastructure. Typically, our modules are going to be under /etc/puppet/modules.

In our first post, we gave you the overview of what puppet was and how to install the software so its available on your system. Now its time to get into the guts of the system and get your client connecting to your master server.

Configuration

By default, puppet really wants to look for a server at puppet.. If you need to change this to a different server name, you’ll want to edit the /etc/puppet/puppet.conf file and add in an entry such as this:

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)

Earlier this week, I had the opportunity to speak at Puppet Camp in Chicago. The goal of the event was to basically share, energize and evangelize puppet to a group of “locals” who will hopefully then use it and also spread the word to others.

I got involved in the event basically by accident. Last year at VMworld, I met Jose who is one of the community guys at Puppet. He helped sponsor a local LUG meeting where I spoke about puppet and it was a pretty good success. For the puppet camp chicago, they were a little short on presenters so I threw something together in the past week and away I went.

Logged into a Puppet master server today and noticed that I had some high CPU utilization happening. This is rather odd as the box usually just chugs along with no worries what-so-ever.

Turns out, some others noticed this as well and some had suspicions that it was leap second related. Check out the full thread here.

Looking back at my SAR records, I find that my CPU spiked right around June 30th at 7PM which is July 1, Midnight GMT.