[RndTbl] Call for Personal Experiences with CFEngine and Puppet

Sean Walberg sean at ertw.com
Mon Sep 17 12:09:38 CDT 2012


I've used all 3 to varying degrees.

CFEngine - I started out with this one quite a while ago, say 2005. Puppet
was just starting up and Chef didn't exist. It's good if you have never
used anything else but every so often you get to a point where you start
swearing at it. At $job[-1] we used it too, though I wasn't the main guy on
it, I just got called in for a second set of eyes when things weren't
working correctly.

The main problems with CFEngine are that it treats the whole thing as a
series of phases. First you copy files. Then you modify files. Then you
look at services. Sometimes you'll get into a dependency problem where your
system is set up to copy files then modify files, but you need to copy a
file after modifying a file, and you end up with a bunch of hacks. The
other problem is probably also an advantage in that CFEngine gives you
tools to modify configuration files on the fly so you can support any
application out of the gate. The problem with this is that it ends up
causing problems in the long run. The idea is to describe a system
configuration (postfix should be configured not to relay), not to describe
a configuration file (if a line with "relay_all_spam_ftw" exists then
comment it out)

On the plus side, CFEngine is ultra fast and the agent is lightweight. It
also has integrated performance monitoring so you can flag alerts or do
stuff under certain load conditions.

I also presented at MUUG about my setup at the time:
http://muug.mb.ca/meetings/lamp_tuning_seanwalberg.pdf

Puppet: I've been following this project for a while and off and on use it
at home. At $current_job we have a managed service that uses puppet, so we
don't see the manifests themselves but have a good exposure to what's going
on.

The idea behind puppet is that you use modules that understand a particular
service and then describe the configuration of the service. The module
takes care of what needs to be done to configure the files or whatever. If
you've got modules available to manage the service then you're off to the
races. If not, you have to write your own. Writing the module is a bit more
complex than the equivalent in CFEngine, but it gives you a lot
more flexibility since you're doing it in a combination of puppet and ruby
(for the templates)

https://gist.github.com/3738489 is an example of my firewall's
configuration that sets up two ruby environments and Postfix.

We use Chef at work to build our development boxes. It's like Puppet -
lite. It's easier to do basic stuff but gets uglier the more complex you
go. The puppet community seems to pride itself on making its modules work
across various systems, while almost anything you find out there for Chef
seems to only run on Debian.

Chef seems like what you get if you got a developer to spec out a Config
management system and had a systems administrator write it. Puppet seems to
be specced by a systems administrator and written by a developer.

If I were doing it all again I'd use puppet. CFengine just seems antiquated
and once you run into the problems with it, and Chef doesn't seem robust
enough.

Also, as some notes because this topic has been on my mind...

- If you're starting out, I found it easier to tackle it service by service
rather than server by server. And do go slowly. Pick something like ntpd
and sudo and get those working across your environment before continuing.
- I've started a podcast. On the first episode I reviewed a book that's
made for developers and systems administrators and uses puppet extensively.
I'd highly recommend the book if you want to get started with Puppet. See
http://linuxadminshow.com/ for the links to the podcast, my written review,
and a link to the book
- On the podcast note, on my list of show topics is to talk about automated
configuration management with Cfengine and puppet. If you get into it in
any great detail, and would like to be a guest, let me know.

Sean

On Mon, Sep 17, 2012 at 11:47 AM, Robert Keizer <robert at keizer.ca> wrote:

> Greetings Greetings,
>
> I'm looking for personal experiences from people on this list who have
> dealt with either CFEngine or Puppet. What do you think are the pros /
> cons? Did you have a horrible experience with one? Are you a Chef junky
> instead?
>
> A little bit of background: I've been working for a company who asked me
> to design and implement a complete infrastructure solution - internal,
> external, testing, production, etc. Things are now stable, redundant, and
> tested ( 90% anyways .. always more to do ). I won't go into too much
> detail about the system as I know just how searchable this email will be as
> soon as it hits the muug server. Suffice to say that there are about 10
> Windows and Unix systems that I'd like to be able to manage a little easier.
>
> I haven't done anything more than read documentation on the two products
> mentioned above over the last few years. As I'm trying to decide which / if
> any of these systems would be a good solution for management of a stable
> production system that _won't_ have too many major changes in the coming
> months/years, and I'd like some input.
>
> It's worth noting that I'm a guy that decided to ( before hearing of these
> frameworks ~4 years ago ) build my own custom framework for managing the
> system ( I'd like to apply the bus principle now that I have some sense ) -
> so scripts and a steeper learning curve aren't my biggest concern.
>
> Any thoughts / advice / personal experiences would be most appreciated.
>
> All the best,
> Rob Keizer
> ______________________________**_________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/**listinfo/roundtable<http://www.muug.mb.ca/mailman/listinfo/roundtable>
>



-- 
Sean Walberg <sean at ertw.com>    http://ertw.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20120917/e791b372/attachment.html>


More information about the Roundtable mailing list