What's in the way of us using automated configuration management

June 18, 2013

Every so often I poke at Puppet or Chef or one of the other automation systems and consider if we could really use it. And every time I do I find it a hard sell, even to myself (much less hypothetically to my co-workers). Today I've decided to try to write down my collection of technical reasons (to go with other reasons):

  • We already have a scripted install process and build instructions for all of our machines, and also more or less scripted package updates.

  • We install almost nothing on our machines other than vendor packages or things scripted as part of the install process; we don't have applications that must be deployed to random machines.
  • It's quite uncommon for us to add even vendor packages to our machines after their initial deployment. It generally only happens when users want some additional Ubuntu package on the login or compute servers, which is pretty rare.

  • Many of our machines are singletons, where we only have one of the particular sort of machine; one external MX gateway, one central mail server, one print server, and so on. The few machines that are significantly duplicated naturally tend to have the most automated install process.

    (Installation of login or compute servers is basically completely automated. Given racked hardware we can have a new one up and running about as fast as it can unpack many, many Ubuntu packages on to its disks.)

  • We (re)build machines only very occasionally; deploying a new machine is a rare occurrence. We don't get new hardware in very often, we have few enough machines that they almost never break, and we only 'upgrade' OS versions at most every few years as new Ubuntu LTS releases come out.

  • We consider it a feature that it takes manual steps to deploy a change to a singleton machine. To put it one way it acts to insure that you're paying attention to how your change actually works.

  • We have our own automated distribution mechanisms for things like the passwd file; these would have to be coordinated with or hooked into any general automation system.

The short version is that we've already automated most everything we commonly do to more than one machine. I don't seem much room for an automated configuration management system to come in and do new things for us; this means that it would have to replace existing, already developed and working automation. There's some benefit to using standard tools for automation but I'm not convinced that there's a lot.

It's possible that I'm missing things that Puppet, Chef, et al could do for us because the usual examples I read are bright cheerful 'let's deploy a canned web server configuration on to a random machine' ones and we don't have that problem. In a chicken and egg problem, I can't find the energy to read the documentation for Puppet because I suspect that I won't find anything we can use.

Written on 18 June 2013.
« My job versus my career: some thoughts
Our approach to configuration management »

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

Last modified: Tue Jun 18 01:05:16 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.