patternMinor
What are sources for configuration management best practices?
Viewed 0 times
whatarepracticesformanagementconfigurationsourcesbest
Problem
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:
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?
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?
Solution
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.
- Policy based management
- 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, 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.
Context
StackExchange DevOps Q#8169, answer score: 2
Revisions (0)
No revisions yet.