Date: Tue, 1 Mar 2016 13:03:50 +0100 From: Christoph Moench-Tegeder <cmt@burggraben.net> To: freebsd-ports@freebsd.org Subject: Re: Completely unscientific poll: cfengine, puppet, other? Message-ID: <20160301120350.GB1580@elch.exwg.net> In-Reply-To: <CAG_PEey4TR%2BZo=bq24HCmShYV1FZJpBiPAeegF5455oUjER5pg@mail.gmail.com> References: <CAG_PEey4TR%2BZo=bq24HCmShYV1FZJpBiPAeegF5455oUjER5pg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
## Chris Inacio (nacho319@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 management alone. - 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". Regards, Christoph -- Spare Space
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160301120350.GB1580>