Sporadically delivered thoughts on Continuous Delivery


| Comments

I would call cfengine a configuration management tool. I just can’t get into graphical and web-based tools for managing servers, I much prefer having a set of configuration files that I can check into version control. Once I’ve got a decent configuration set for an infrastructure, setting up, updating, or changing the role of a machine is a simple matter of tweaking the configuration files and running a command.

I find cfengine to be a bit awkward, it’s configuration system suffers from being an academic research project. But so far I haven’t found anything better.

A challenge I have is that less experienced sysadmins often find it difficult, they would rather just directly change a machine’s configuration instead of changing central files and distributing them. But this inevitably leads to a bunch of inconsistent, out of date machines, so discipline is worth it.

Cfengine’s syntax is too rigid, it doesn’t make it easy to template configuration patterns and reuse them. For example, let’s say I want to build Apache configurations for multiple virtual hosts. In Apache’s main httpd.conf file I use an include directive to read in all files ending in .conf in the directory /etc/httpd/vhosts. So I just need to configure cfengine to put a .conf file in that directory for each virtual host to be hosted on a given machine.

Ideally I would just have a single set of rules in cfengine which create the appropriate vhost file, using the cfengine editfiles: tasks to build the file with the appropriate apache configuration directives, the copy: task to put it into place, and the files: task to ensure it has the right permissions. But cfengine doesn’t let me do this, instead I need to copy the appropriate directives for each vhost.

This kind of inflexibility is one of the reasons cfengine configurations are difficult to understand, which discourages sysadmins from using it.