Many years ago, whilst working in an environment with a couple of hundred machines, I created a systems configuration system with which I was able to deploy machine-specific configurations. The program supported SSL, macros and had all the bells and whistles I could think of, at the time. The customer never really used it, preferring to manually configure things, editing a file here and there (or forgetting to do so!), etc., so the program fell into oblivion. Fast-forward to today. I have a similar task at hand, but this time we’re talking large numbers of machines, all Unix/Linux. As I’ve had the pleasure of trying to keep up a bit with the subject of DevOps, I’m aware that there is a large number of configuration management utilities on the market today. Two stand out, however: Puppet and Chef. I won’t delve too deeply into why I chose Puppet, except to say that I strongly believe Puppet is better in an enterprise, its documentation is superior and it doesn’t force its users to learn Ruby. And if you want to glance at a configuration snippet of both, … ‘nuff said. I did though confirm with Kris, whom I trust knows a lot on the subject, that my findings are correct:
I also see a lot more adoption of puppet in enterprise environments where I see more of the web shops look at chef.
Puppet it is. And let me tell you I’m quite impressed. There’s a bit of terminology to be learned, but it isn’t difficult. Puppet’s DSL is very readable (and as I said: you don’t need to read Ruby!) and within minutes you can experience Puppet’s working. (If you’re looking for a very quick introduction to Puppet, glance at the NTP tutorial. What you should really do is to read R.I.Pienaar Getting started documentation, and while you’re at it, you’ll find him as @ripienaar. James Turnbull has a good book called Pulling strings with Puppet. It’s a bit dated but it gives a start into the subject.) I’m also using Puppet for an exciting new project I’m doing with my friends at SpeedPartner.