Our approach to configuration management

June 19, 2013

A commentator on yesterday's entry suggested that we're already using automated configuration management, just a home-grown version of it. To explain why I mostly disagree I need to run down the different sorts of configuration management as I see them:

  1. No configuration management: you edit configuration files in place on each individual machine with no version control. Your best guess at what changed recently is with 'ls -l' and your only way back to an older configuration file is system backups.

  2. Individualized configuration management: you use some sort of version control but it's done separately on each individual machine. Rebuilding a copy of a dead machine is going to be a pain (and involve restoring bits from system backups).

  3. Centralized configuration management: you have a central area with canonical copies of your configuration files for all of your machines (under version control of some sort because you aren't crazy). But you still have to update machines from this by hand (or make changes on the machine and then copy them back to this central area).

  4. Automated configuration management: when you change something in your central area it automatically propagates to affected machines. You don't have to log in to individual machines to do anything.

For the most part we have centralized configuration management, with the master copies of all configuration files living on our central administrative filesystem, but not automated configuration management. Only a few things like passwords and NFS mounts propagate automatically; everything else has to be copied around in an explicit step if we change it (sometimes by hand, sometimes with the details wrapped up in a script we run by hand).

(Actually now that I think about it we have a surprising amount of automatic propagation going on. It's just all in little special cases that we usually don't think about because, well, they're automated and they just work.)

I could give you a whole list of nominally good reasons why we aren't automatically propagating various things, but here's what it boils down to: if sysadmins are the only people changing whatever it is, it doesn't change very often, and it doesn't have to go everywhere, we haven't bothered to automate things because it doesn't annoy us too much to do it by hand. When one or more of those conditions changes we almost invariably automate away.

(That actually suggests a number of openings for a system like Puppet. For a start it can probably handle the actual propagation on command instead of having us manually copy around files.)

Written on 19 June 2013.
« What's in the way of us using automated configuration management
The question of whether to rewrite an old but working service »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 19 00:29:16 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.