Service Configuration Management

September 05, 2005

Today our sysadmin asked me to setup a new wiki for use in some course. (Due to early wiki enthusiasm I became wiki master in our department. In fact it took quite some time to convince people that not having a single web master was a good idea.) When I set up my first wikis, one for our Software Technology research group and the other for Program-Transformation.Org, it took me quite some time to get everything installed in the right place, customize the configuration file, and such misery. For instance, on the webserver of our department perl was not installed in /usr/bin as was expected by the CGI scripts of TWiki, but rather in /sw/bin. This required patching all scripts each time I upgraded the installation. Also the directories containing the site were mounted on a different path in the webserver than on the user server. Thus, scripts that were invoked via cron job (for example to update statistics) needed a different path configuration than scripts running on the server. As a result, updating the site was not something to look forward to, let alone adding new installations.

Today I didn't flinch a second when receiving the request to create a new wiki. I just copied the 60 line Nix file of another wiki, changed the name of the wiki, the directories in which to store the wiki data, the port at which to approach the wiki on the server, and customized a few other options. Then I called the install script, and there I had a new wiki set up and running. Well, actually I had to ask sysadmin to open the new port, but then it was just there.

This is all thanks to service configuration management with Nix. In this paper that Eelco Dolstra will present tomorrow morning at SCM-12 in Lisbon (Portugal), we show that the management of services requires the integrated management of software and configuration. By treating software configurations just like any other software components, rather than as state managed in global directories, one can uniquely and reproducibly describe a specific instance of a service. We have used this to succesfully deploy quite a few services already, including a subversion version management server, a Jira issue tracking server, a buildfarm and automatic release management system. The description of the machine specific parts of the deployment of these services is factored out into a small Nix expression, such that I could create a combined subversion/wiki server on my little home machine with the push of a button (well almost).

So if you don't have a chance to attend Eelco's talk tomorrow morning, at least have a look at the paper.