Configuration tools: A few thoughts
I just found a post in my drafts folder, summing up my thoughts about CM (Configuration Management) tools from a little under a year ago. Since then, I’ve started using Ansible to set up servers. I’m still not fully converted, but I find Ansible a very useful tool. I have 7 active machines at home, and running my update scripts on each of those is a pain. Ansible makes it a lot easier.
I still use Fabric for updating machines, mainly because it gives me specific control over the process and it makes it easy to string commands together to make just the changes I need. That, and it’s fast.
I do find that Ansible sometimes gives me too little feedback to figure out what went wrong if a directive did not complete, but on the whole it’s a lot more consistent and usable than any of the alternative CM tools I’ve tried to use.
Original draft below. Pretty much all of it is still valid:
For the past few years, I’ve been using a shell script to set up new development machines to my liking. These install all the needed packages, create directories and files, and copies my preferences to the correct places. I also have a few servers with various setups. Since I use Ubuntu on the desktop and Ubuntu/Debian on the server, the server setups are usually a subset of the development setup.
I’ve also used Fabric for deployment in the past year or two, and really enjoy the better consistency and ease of use I get from that. Coupled with buildout, I can get a stable setup running on both development machine and server. With that in mind, I figured that it would be useful to look at provisioning systems, most notably Puppet and Chef.
I do see the need for systems like Puppet or Chef, where machine configurations are centrally controlled and absolutely repeatable from a clean base. However, these systems are overly complicated for my use case, where I have few machines and some of them do double duty, running many services.
In addition, the setup and learning curve on these systems are insanely complicated. These systems also have a requirement for extra software on the machines.
I recently saw a project called Ansible that looks very promising, but until I have that configured, Fabric rocks.
It’s all a matter of horses for courses. The ability to update code on the server within seconds and with very little effort makes a difference to ease of development and responsiveness to client requests.
Configuration management systems are very useful when setting up servers from scratch, especially getting machines up quickly for a cluster. However, they suck at configuring machines that were initially configured without these tools.
The centralised nature of Puppet/Chef, and the complicated way they have of getting their configuration, makes them too clunky, in my opinion.
If you want a fast turnaround, push works better than pull. Pull has its own inherent problems, like the ’thundering herd’ problem, and non-deterministic, slow updates. It also adds extra layers of complication.
I also find that the abstractions that configuration management tries to foist upon us, are both leaky and useless. Setting up a box using Puppet, without knowing the underlying commands, will get you into trouble at some point, and the setup itself is just another layer of abstraction on top of the actual commands, with a different syntax.
Configuration tools are fine for when you have several identically-configured servers, but are much too complicated for single-machine or custom setups.