It was interesting to read recently from Martin F. Krafft a botnet-like configuration management proposal.
Professionally I've used CFEngine, which in version 2.x, supported a bare minimum of primitives, along with a distribution systme to control access to a central server. Using thse minimal primitives you could do almost anything:
- Copy files, and restart services that depend upon them.
- Make minor edits to files. (Appending lines not present, replacing lines you no longer wanted, etc)
- Installing / Removing packages.
- More ..
Now I have my mini cluster (and even before that when I had 3-5 machines) it was time to look around for something for myself.
I didn't like the overhead of puppet, and many of the other systems. Similarly I didn't want to mess around with weird configuration systems. From CFEngine I'd learned that using only a few simple primitives would be sufficient to manage many machines provided you could wrap them in a real language - for control flow, loops, conditionals, etc. What more natural choice was there than perl, the sysadmin army-knife?
To that end slaughter was born:
- Download polices (i.e. rules) to apply from a central machine using nothing more complex than HTTP.
- Entirely client-driven, and scheduled via cron.
Over time it evolved so that HTTP wasn't the only transport. Now you can fetch your policies, and the files you might serve, via git, hg, rsync, http, and more.
Today I've added one final addition, and now it is possible to distribute "modules" alongside policies and files. Modules are nothing more than perl modules, so they can be as portable as you are careful.
I envisage writing a couple of sample modules; for example one allowing you to list available sites in Apache, disable the live ones, enable/disable mod_rewrite, etc.
These modules will be decoupled from the policies, and will thus be shareable.
Anyway , I'm always curious to learn about configuration management systems but I think that even though I've reinvented the wheel I've done so usefully. The DSL that other systems use can be fiddly and annoying - using a real language at the core of the system seems like a good win.
There are systems layered upon SSH, such as fabric, ansible, etc, and that was almost a route I went down - but ultimately I prefer the notion of client-pull to server-push, although it is possible in the future we'll launche a mini-daemon to allow a central host/hosts to initial a run.