Completely unscientific poll: cfengine, puppet, other?
cmt at burggraben.net
Tue Mar 1 12:03:53 UTC 2016
## Chris Inacio (nacho319 at gmail.com):
> Happy if you would just reply with which one, if any, you use.
I'm using cfengine for a mixed (several Linux, some FreeBSD) environment.
But: without the "cfengine-masterfiles" (available as a port), using
cfengine can be somewhat painful (as already remarked by some); and
when using those masterfiles "as provided" by upstream integration
between the cfengine port and the masterfiles is not really ideal.
Caveat emptor: my cfengine setup did not start with the FreeBSD
machines, some of the problems may be homegrown.
Some items not immediatly relevant to the current question, but perhaps
helpful to to consider when chosing any sort of configuration
management; picked from experience and top of my head:
- what environment do you expect?
cfengine is C and "data", so there's little inital dependencies
and you can bootstrap cfengine from a very minimalistic isntallation,
while puppet/chef/salt/ansible require ruby/python/working ssh/...
(that alone had been the tipping point in one setup I know of)
OTOH cfengine/puppet/chef are probably "too large" for embedded/IoT
stuff - those smallish systems would be fully loaded with the config
- do you want "push" or "pull"?
Some systems (e.g. cfengine) are using a pull model, where the "managed"
machines connect to a central hub periodically, fetch the configuration
and "do what needs to be done", while e.g. ansible follows a "push"
model, where the "agent" is executed "somewhere" and connects to the
managed node to do it's work.
Considerations: network model, load. With the "pull" model, the agents
are constantly executing, the aggregate load (CPU&IO) may be noticeable
in virtualized/shared storage environments - and the central configuration
hub requires enough "horse power" to handle the clients (I've heard of
problems in that area, and some documentation hits that cascading setups
should be used for huge setups). Consider having a centralized config
hub and "change lag" because of periodic polling against "run anywhere"
and "run anytime you need it".
More information about the freebsd-ports