Ask HN: How do you design configuration management solutions?

[avaika]

Hey,

I'm digging around a scalable configuration management solution to make it a skeleton for projects inside my company. A kind of silver bullet for everyone. I know about different tools and automation and stuff, but I really miss a kind of best practices reference.

Whenever I read books or blogs, it only shows oversimplified cases which doesn't apply to real world. I'm looking for a kind of source I can use as a reference to justify the solution I'm choosing (at least for myself). And also save a bit of time on testing and comparing all the things I'm not sure about.

I mean it's really easy to build e.g. ansible playbook to deploy nginx config with variables. Though it doesn't always works as good when we talk about hundreds of services and business demands supporting multiple different versions on different hosts and the playbook isn't that small and pretty. Also topics like configuration versioning, rollbacks and stuff are covered really rare.

Is there any source for best practices in configuration area? (it also might be I'm bad at googling, but didn't find a thing though)

[ktpsns]

My experience is that trying to build "the silver bullet" always inevitably results in reinventing the wheel by finding a piece of software which solves the same problems after weeks of coding. That's probably why the classical "Unix admin approach" -- a collection of scripts to manage textual config files -- is probably the most flexible one, when combined with standard (for file formats, versioning, etc -- depends on your preferences). Basic scripting with JSON/Yaml/tenplating/git/systemd/etc is the way I would setup larger computer systems nowadays. I've seen this being successful in institutes with ~200 users and according computing facilities.

[avaika → ktpsns]

Collection of scripts might be quick and fun solution, but it isn't really reliable (unless it's ansible / chef level of scripts).

[ktpsns → avaika]

The reliability comes if the tool is mature -- it doesn't matter whether it's a collection of CLI scripts or a big web frontend. In any way, it's clear that "a bunch of scripts" will remain the opposite of a big framework such as Ansible. But it doesn't neccessarily need to be worse. Equipped with a good documentation, it might be much better tailored to save the administrator her time.