So what is this Puppet thing anyway?

Puppet Zero

So you keep hearing about this Puppet thing and how it's going to solve all of your DevOpsy configuration management problems. But what is it? How do you write a Puppet script? Well, as it turns out, the key concept is unlearning the habit of thinking about scripts. But all in good time. We'll get there. First, let's write some code.

Let's start out with something easy. You all know what the /etc/motd file is. It's the message of the day file that's dumped to your screen every time you log in.

Declarative State Modeling

By now in your Puppet career, you've almost certainly been exposed to the phrases declarative state or state modeling. You may even have a pretty good idea of what the words mean. But how in the dickens do they relate to configuration management? The confusion only makes sense. We've been writing shell scripts to provision, configure, and even boot our computer systems for forty years. It's going to take a mighty strong argument to change that habit now.

Manipulating existing state, and other foolish ideas

One of the more common questions I'm asked on #puppet is how to use existing state when applying configuration to a node. For example, "how can I tell when mysql is installed, so I can add a firewall rule for it?" In this post, I'm going to talk a little bit about why I think there's such a draw to this approach, then I'll explain why it's universally such a bad idea, and then I'll talk about better ways of accomplishing the same goals.

Using the ENC together with site.pp. What is this madness?

Puppet has this real neat concept of an external node classifier (ENC) that lets you define your nodes in some way that's not Puppet. If you have your nodes stored in anything from an LDAP database to even an Excel spreadsheet and you can write a script to connect to your datasource, then Puppet can call it to create its node definitions as it runs.