Configuration management with tools like Puppet can make your life a lot easier. It can make configuring newly provisioned servers more repeatable and reliable and it can make disaster recovery nearly trivial. Learning to use the tool isn't trivial by any means, though. There are 200 configurable options, give or take depending on the version you're running, and the number of things you can do with it is nearly infinite.
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.
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.
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.