The three legs of modern configuration management

[Marco Marongiu]

Hi there

I'm moving from the interesting thread "Messaging in CFEngine",
initiated by Martin Simons. I like the way things are developing there.
At the same time, I feel there is something missing and I'd like to
share with you something I've been mumbling about for some time. I'd
appreciate if you could share your opinions on the following.



I would classify today's CM tools as proactive and one-offs.

Proactive CM run on each node, watching its configuration at well
defined intervals and correcting deviations from the desired state.
CFEngine falls into this category. Puppet does as well (unless it's run
on demand, of course). I have no knowledge of Chef but AFAIK it also
falls here.

One-off CM is usually run on demand: a certain desired state is defined
and applied when an "agent" initiates the configuration of a set of
nodes. AFAIK Ansible and Salt fall in this category. CFEngine does NOT
fall in this category: the closest thing you can do is to request an
agent to run on a set of nodes via cf-runagent, but it's up to the agent
itself to decide if it will run or not.

Yet, there is a third type of configuration management and it's so
increasingly important nowadays, with elastic infrastructures, docker
containers and whatnot. It's Reactive CM, where the configuration of a
system is updated in near-real time following an event. That's for
example what happens with Consul and Consul Templates.


In my personal view, an all-round, modern configuration management
system should stand on these three legs. You'd have proactive CM tools
configure the system in general and the other two legs in particular,
use one-off CM tools when you need to nullify latencies (e.g.: you want
to trigger an agent run immediately, you want to force a package cache
update, like "apt-get update", so that a subsequent request to install a
package would be applied immediately... you name it). And you'd have
reactive CM take action when, for example, you are spawning/killing
instances of VMs/containers following a load spike and you need to
update the configuration of a front-end FAST.


Now, there's a lot up for grabs for Proactive and One-off CM. For
Reactive CM, I personally believe that Consul is the way to go, and we
should work towards integrating it with CFEngine and in the simplest way
possible for the end-user. In my opinion Consul is the most complete
tool for reactive CM:

- it's clustered
- it's data center aware
- it has a built-in key/value store
- it supports events
- it can reconfigure systems on the fly via consul-template
- it has failure detection
- it has service discovery
- it supports encryption
- it's multi-platform
- it's easy to install (copy one file, done)


What do you think? If there was a collective effort to do this kind of
integration (CFE+Consul+something) I may be able to contribute.

Ciao
-- bronto