In the area of server operating systems, configuration management at the most basic level is about managing the configuration of the server. It usually starts from OS configuration files, but often includes software installations and their respective configurations, possibly data too, and may extend across large numbers of servers that may serve different purposes.
Think of it like this. If you have one server, maintaing its configuration is probably not very difficult. If you have a dozen or so of them, it quickly becomes a chore to manage them individually. You’d wish you had some automatic tools to help you manage them, such as to update configuration files, apply software updates, etc. Now, suppose you have many hundreds of servers, which are not homogeneous, not just because their hardware are different, or that their operating systems are different, but also because the software used in them are different and they are provisioned for different purposes in different environments. You’d quickly realise that the system administration job becomes quite overwhelming.
Somewhere after the first half dozen or so of servers to manage, most sysadmins will start to develop their own scripts to help them do their jobs more efficiently. The easiest things to do is to build rsync scripts to replicate stuff automatically. It’ll soon grow to include a whole bunch of Unix tools, everything from cron, version control, make, etc. Eventually most system administrators will think there must be something much better and much easier to use out there.
That’s when we start to seriously consider configuration management tools. Unfortunately, many of them seem to have a steep learning curve. They are supposed to make system administration easier. Indeed, they probably will, but only after you’ve mastered them, and spent considerable time setting things up to work the way you want them to work.
I did come across a comparably lesser known contender in the configuration management space: Ansible. Like CFEngine, Puppet and Chef, Ansible is on the one hand open source, but at the same time has commercial services and other premium products built around it. It seems this is the growing trend among these tools.
Before I go on, let me share with you my requirement for configuration management tools. I’m looking for the following attributes:
- Lightweight
- Easy to install, minimum pre-requisites
- Easy to figure out, easy to do simple things
- Ability to extend to more complicated tasks
The lightweight bit bears a little more elaboration. The configuration management tool should not be a burden in terms of CPU and memory overheads. My servers are there to provide some useful service, and configuration management just plays an underlying supporting role. I do want to run configuration tools even in some embedded servers, such as Raspberry Pis. So, no Java or other monster, thank you.
Ansible seems to fit well. There are a couple of key benefits offered by Ansible:
- Manages all remote clients entirely via SSH. No new protocols to deal with.
- Has no requirement on the remote, apart from needing Python installed.
- Extensible with modules that speak JSON over STDOUT. Uses YAML for configuration.
Now, here’s one of the best things I always wanted with these automation tools. Suppose you have an ad-hoc thing you needed to get performed on all your servers. With most configuration management tools, it’s likely you’ve to go write some config, push it out, and then your ad-hoc thing gets done. I often wish I could do something like the equivalent of:
$ ssh * do-something.sh
In the above example, the * wildcard is supposed to match all my servers.
Let’s use a concrete example. Suppose I want to know the uptime (using the command uptime) of all my servers. Here’s the simple command to do that:
$ ansible all -a uptime
That’s it. No need to write any config. No need to commit anything. No need to get anything synced.
Ansible is written in Python, hence the requirement for Python on the host. It may not be as lightweight or efficient as something written in, say, C. But Python’s sufficiently good, and it makes Ansible relatively portable. Python is easily available on many platforms, and it’s not difficult to find people who can understand Python, or pick up Python.
There are several resources on the web where you can get a quick run down on the various configuration tools mentioned here. For example, try this post on Normation Blog on CFEngine, and this InfoWorld article which compares Puppet, Chef, Ansible and Salt. The InfoWorld article doesn’t think very highly of Ansible, but do note that they are comparing the commercial offerings of the various tools.
The simplicity of Ansible, and their use of familiar tools, makes me as a system administrator very comfortable. For example, with all the communications happening via SSH, you are fundamentally debugging a SSH connection if you run into any Ansible communications problems. Troubleshooting SSH could be something that we’re already familiar with.
Ansible makes it easy to use because it works in the way you’d expect things to be done, if you had to do them by hand. You aren’t forced to change your way of thinking to match the model that the configuration management tool has adopted.
Try out Ansible for your next project!