I'm struggling with design for configuration management for a complex on-premise enterprise application with lots of moving parts. While it's fun and joy to go through this, there are lots of questions I'm really not sure of, and I need some source to refer to as best practices or just revise my design solution.

It might be I'm really bad at searching the internet, but whatever materials I've found, it's all about very basic examples, like "let's configure yet another web application behind nginx". Which feels like writing microservice application based on "hello world" example.

Example of issues I'm struggling with:

  • Configuration usability vs configuration complexity
  • Self-written solution vs open-source adaptation vs combination of those two
  • Pre-compiled configuration package vs dynamic template on actual deployment
  • Ways for a quick configuration roll-back

And others.

I do understand, that there won't be a silver bullet which answers all the questions I have, but at least it'll give me a hint if I'm moving in a right direction.

So what sources I should look into?

  • You've run into the dirty little secret of configuration management: tools like Chef are written for and by webdevs so e.g. Ruby-on-Rails devs can stay in their comfort zones while, as you say, configuring simple web applications. The "grown-up" tool, CFEngine, has fallen out of fashion recently, but it's the only one backed by solid theory, read some of its documentation for ideas. – Gaius Jul 8 '19 at 21:27
  • @Gaius CFEngine, Puppet, Chef, Ansible and Salt are all backed by the promise theory, CFEngine has fallen out of fashion for various reasons, one I can say for me is the limited DSL and "native" methods/components, as an example compare a cronjob declaration in CFEngine vs in Chef, the later just give more control on what you can do or specify. – Tensibai Jul 9 '19 at 8:03
  • Well... not really. CFEngine converges iteratively and incrementally over subsequent runs. Chef uses the word “converge” but all it’s really doing is running a script from top to bottom and giving up on the first failure. Totally different approach, and the authors of Chef had clearly no experience with CFEngine first, but had merely skimmed its documentation. – Gaius Jul 9 '19 at 9:09

Well, that's pretty broad, mostly this can boils down to two options:

In the first one you're describing the actions you want to be done to achieve the desired state, assuming previous state of the system or testing against it specifically, in the second you're describing what you expect as resulting state of the system and your tool should take care of doing what is necessary to achieve that.

A policy based management could be made of simple scripts, doing what you want, Promise Theory tools are inherently more complex (Ansible, Chef, Puppet, Salt) but they're mostly idempotent, this means they will only change something if the actual state doesn't match the desired state.

The only question which can be given a really definitive answer out of thin air without knowing the specifics of your application/service is to the second question:

Don't reinvent the wheel, there's serious softwares for configuration management nowadays that rewriting your own would be a road of pain for less functionalities than already existing in available softwares. There's of course a learning curve whatever path you choose, but the effort to learn a maintained piece is more worthy than the effort to write your own system and maintain it on top of the application configuration you'll have to manage with it.

| improve this answer | |

The closest thing to an official source for best practice configuration management is ITIL, but it is important to remember (most don't) that ITIL is a toolbox of ideas and techniques, it is supposed to be adapted to the unique requirements of each site, not applied verbatim.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.