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

<ul>
<li><a href="https://en.wikipedia.org/wiki/Policy-based_management" rel="nofollow noreferrer">Policy based management</a></li>
<li><a href="https://en.wikipedia.org/wiki/Promise_theory" rel="nofollow noreferrer">Promise Theory</a></li>
</ul>

<p>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.</p>

<p>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 <a href="https://en.wikipedia.org/wiki/Idempotence" rel="nofollow noreferrer">idempotent</a>, this means they will only change something if the actual state doesn't match the desired state.</p>

<p>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:</p>

<p>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.</p>

CC BY-SA 4.0
2019-05-20T13:10:22.220Z
2019-05-20T13:10:22.220Z
Tensibai
<p>The closest thing to an official source for best practice configuration management is <a href="https://en.wikipedia.org/wiki/Configuration_Management_(ITSM)" rel="nofollow noreferrer">ITIL</a>, but it is important to remember (most don't) that ITIL is a toolbox of ideas and techniques, it is <em>supposed</em> to be adapted to the unique requirements of each site, not applied verbatim. </p>

CC BY-SA 4.0
2019-07-08T21:32:35.373Z
2019-07-08T21:32:35.373Z
Gaius
<p>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.</p>

<p>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.</p>

<p>Example of issues I'm struggling with:</p>

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

<p>And others.</p>

<p>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.</p>

<p>So what sources I should look into?</p>

CC BY-SA 4.0
2019-07-08T21:27:18.277Z
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
CC BY-SA 4.0
2019-07-09T08:03:21.533Z
@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](https://docs.cfengine.com/docs/3.12/reference-masterfiles-policy-framework-lib-bundles.html#cronjob) vs in [Chef](https://docs.chef.io/resource_cron.html), the later just give more control on what you can do or specify.
Tensibai
CC BY-SA 4.0
2019-07-09T09:09:04.127Z
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
<configuration-management><configuration>
What are sources for configuration management best practices?
rush
# What are sources for configuration management best practices?

(Asked by: username_0 on 2019-05-20)

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?

**Tags:** configuration-management, configuration

> **Comments:**
> **username_1**: 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.  
> **username_2**: @username_1 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](https://docs.cfengine.com/docs/3.12/reference-masterfiles-policy-framework-lib-bundles.html#cronjob) vs in [Chef](https://docs.chef.io/resource_cron.html), the later just give more control on what you can do or specify.  
> **username_1**: 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.  

---

## 2 answers

### Answer by username_2 on 2019-05-20. Score: 2 | Accepted answer

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

* [Policy based management](https://en.wikipedia.org/wiki/Policy-based_management)
* [Promise Theory](https://en.wikipedia.org/wiki/Promise_theory)

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](https://en.wikipedia.org/wiki/Idempotence), 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.


---

### Answer by username_1 on 2019-07-08. Score: 1

The closest thing to an official source for best practice configuration management is [ITIL](https://en.wikipedia.org/wiki/Configuration_Management_(ITSM)), 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.


---

