I’ve spent my entire IT career automating. To me, the point of technology is to make life easier, so I tend to look for any way I can to make computers do ’the heavy lifting'.

Configuration Management is the epitome of automation, it forms the bedrock of achieving supportable, repeatable and consistent services. CM is also key to the phrase-du-jour, ‘DevOps’. Your end to end (dev to prod) application deployment is nowhere without CM.

This is an opinion piece. There are no tests, they’re simply observations with comments. Therefore it’s very subjective. You may well have a different point of view. I welcome comments.

Some salient points:

1. I’ve been working with Puppet as my choice of CM for over six years. I’ve implemented it for a good few clients, and worked with it in other, established, infrastructures. And for the most part, I like it.
2. Despite that, I’m not the biggest fan of Ruby. Sure, I write some stuff in it, but it wouldn’t be, isn’t, my first choice of ‘glue’ language.
3. I’m a UNIX person. I don’t care about anything from, or relating to, Microsoft.
4. I am pragmatic. Whereas I like to do things the best way possible [that I think ;-)] I will also implement with the client in mind. For the most part I am software agnostic (apart from having favourites, of course).
5. My favourite quote is from Einstein: “Make everything as simple as possible, but not simpler”.

So, let’s get on with it.

Puppet

I’ve already mentioned that I’ve a solid background with Puppet. The main thing I like about it, and always have done, is the DSL. Puppet has a nice, simple, language for describing your systems. “Package”, “Service”, “User”, “requires”, etc. etc. It’s simple to read, easy to understand, and system agnostic.

It’s a fairly trivial install with few dependencies [Ruby], and if you use the Enterprise version it’s even easier. And unless you’re using Dashboard, you don’t really need a database (which for small implementations - of anything - is good in my book).

A lot of large organisations want a GUI, and want to be able to manage systems from it (be that web or otherwise) - which Puppet Enterprise provides (you can run Dashboard as open source too). And, although I don’t care in the slightest, it supports Microsoft Windows too.

Puppetlabs themselves maintain package repos that contain most of the dependencies too (there are some Ruby modules that aren’t in RedHat base distros, like CentOS, for example), which again makes life a bit easier.

There’s a great community, and lots of modules have already been written ’to do stuff’. Their founder, Luke Kanies, wanted a solution to stop sysadmins ’re-inventing the wheel’ at every company. I think Puppet achieves that.

The negatives - well, sometimes you can get into a pickle with resource dependencies (e.g. service X needs package Y and config file Z). You can only define a ‘resource’ in one place (e.g. an httpd service), which for newbies can be confusing. But I’m nit-picking, you get over that one quick enough.

It can be slow when you have hundreds or more clients trying to get their catalog. I’ve given up running Puppet as a client-server architecture now, and run ‘masterless’. This seems to be an increasing trend. Put all your manifests into a version control system (say, git) and check that out on every host. You’ve a simple, trusted, transport mechanism in SSH, and the application of the configuration just runs locally. No overloaded central server to worry about. Run the checkout under cron, with a random timing element, and you don’t generate a different performance problem by every host SSH’ing in at the same time.

Chef

I’ve only recently been exposed to, and had to use, Chef. I didn’t chose to use it, but being pragmatic I went into the piece of client work open minded - I knew Chef came about shortly after Puppet, which influenced its formation. I had heard they were similar products.

But for starters I’ve been put off by its DSL - it’s Ruby. Just pure old Ruby. I guess this would make it feel like ‘a comfortable pair of shoes’ for a Ruby developer to start managing systems, but coming from a systems background all I can see is it makes it hard work for anybody not a programmer by trade. It also seems overly complex. Workstation, Server and Clients. Knife, chef-client, chef-solo. Data structures in JSON. A Postgres database.

I’m also seeing a lot of ‘shelling out’ in the manifests at this particular client, which makes me think they were unable to achieve what they wanted within Chef too (’execs’ are frowned upon in the Puppet community - but of course, if you’re just running shell scripts on a system it is rather bloated and inefficient to be wrapping them in Ruby! You might as well go back to old skool for-looped copying of scripts over SSH).

And this is the thing. If you are a web programmer, maybe working on Rails, then all this is familiar ground, so it seems simple to pick it to manage your systems.

But, wait, why would you? Why would you pick something that is, as far as I can see, Puppet made overly complex? Nothing about Chef makes sense to me when I compare it to other CM solutions.

Even when you factor in somebody coming at it from a familiar background, it wouldn’t take a Ruby programmer, or any programmer for that matter, at all long to ‘get’ Puppet’s DSL, it is that simple. Puppet has a data store like Chef’s data-bags, but it’s YAML instead of JSON. And when I look at the two file formats, I fail to see why you would use JSON (for a human readable data store, I mean. Granted it’s a web programming standard, so discount that) when YAML is so much more readable.

If I’d come to Chef before Puppet I’d probably see all its good points - it delivers centralised configuration management in a, relatively, [Ruby] easy way. But I’ve not, I’ve used something that is similar but oh so much simpler.

I just cannot see the point of picking Chef over Puppet.

UPDATE: Interestingly, in the comments below, somebody brought to my attention this post. I particularly liked this line about Chef - “It’s a remote execution engine with a great deal of architectural overhead”.

But wait, we’re not done yet…

Ansible

Ansible is, again, another recent exposure for me. At pretty much the same time as Chef, since it’s being used as part of the same client project - which begs the question, why didn’t they just stick to one CM solution?

Well, because it was being used to CM the setup of XenServers. Which don’t have Ruby on. And Ansible is based on Python, which is on pretty much any base install of an OS these days (most of RedHat’s toolset on RHEL is written in Python, and even Sun were fond of writing tools in it too).

And this is where it got interesting for me. Ansible is the work of Michael DeHaan. Some of you may know about Cobbler. When I learned this I was instantly put off without even trying it (talk about judging a book by its cover) - I never liked Cobbler. Too complicated for something that should be simple (this is one of the reasons I wrote my own - totally not worthy of wider use! - Linux kickstart tool, Bacio).

But then I started to use Ansible. And my first impression was good. Here is a tool that works opposite to the way Chef and Puppet do [client-server]; it’s a push model. It requires no additional installs on the end points (unless you’re using selinux, then it takes one extra Python library that’s more than likely in the distribution repository anyway). It uses SSH for its transport. And YAML (which I really like because it meets my requirement of ‘simple as possible, but no simpler’) for the configuration language.

As I started to try to achieve things with Ansible I found it to be the simplicity I want to see from technology. It could achieve all that I’ve done with Puppet for years, but in an even easier way.

The YAML ‘playbooks’ fall through tasks like running down a firewall ruleset. You can see the path your job takes right before you (Puppet does a complex catalog compile to work out ordering, which can change from run to run. This has positive and negative connotations, not least some occasional confusion). Here’s an example playbook - this installs XenTools on Xen based virtual machines. I’ve done this before in shell and in Puppet.

No remote installs. No funny transports and odd ports to have to open on firewalls. No complex SSL certificate management. No database servers.

And I’m increasingly realising DeHaan (and one presumes his co-developers) have thought of most things. You could run it client-server if you chose; by simply emulating the master/server-less models of Puppet & Chef[-Solo].

They have a commercial offering, Ansible Tower, should you want a pretty dashboard. It’s actually got some really nice features too, one of my favourite being the REST API and Callbacks (see page 114 of the Tower manual for more information)

Ansible. Oh how I wish I’d not been introduced to Ansible. Because now I can’t think about doing CM with anything else. I could still proceed with Puppet, (if I really had to) but Ansible is at the other end of the spectrum to Chef as far as I’m concerned.

I’m sure there’ll be negatives somewhere along the line, there usually are with technology. I just haven’t found them yet. The obvious one I don’t care about - it doesn’t support Windows[3] (really? You wouldn’t train for a marathon by riding a bicycle, you’d run. So why try to lump management of Windows and UNIX/Linux into the same space? Hire people who do Windows, hire people who do UNIX, and let them manage their own estates).

You’d probably have to do some funky routing and firewalling in a massive estate to use the push model (you’d probably opt for the client-server mimic). And in its current form managing a large estate would probably be a bit like hard work. But for an SME, or a startup, managing an estate from the shell? I think it’s brilliant.

Summary

The long and short of it:

• Ansible works really well. I can’t see the negatives[1]. It is my choice of CM software right now, and I will encourage clients to use it whenever I can.
• If you’re absolutely against Python, SSH, and particularly want to install agents on every machine you manage, or you need to manage Windows[2] right now, pick Puppet.
• I can’t actually think of a good reason to use Chef. Even if you’re a Ruby programmer you’ll still be better off with Puppet.

[1] In the size of estates I’m currently implementing for. Larger scale would be a different matter, but again that’s a whole other conversation - I’ve worked in companies with 20,000 server estates for the last few years, and I’m not convinced there are any solutions to handle that sort of scale ‘properly’

[2] Please, just don’t! Apples and pears. Horses and sheep. Whatever. Let the Windows bods look after their stuff, you stick to UNIX. It’s better anyway.

[3] Update, June 19th 2014; Ansible now supports Windows. Or, at least, is beginning to. See this blog post.