puppet overview - pros and cons

[David Lutterkort]

Since introductions are all the vogue today, here's some background
about me: I work in Red Hat's Emerging Technologies group on systems
management things; a little over a year ago I got interested in
configuration management and started looking around for a tool that
could fill the gaps left by the current tool chain that people use
(well, a very short chain generally, mostly made up of package
management and a little bit of source control) 

During that time, I looked at pretty much all the config mgmt tools out
there, and found that puppet has the most promise of the lot, both for
straightup config mgmt and for pushing the envelope of what can be done
there (e.g., distributing detailed configurations in a reusable way[1])
Before that, I worked on RHN for a while, and before that I did a lot of
consulting work for Red Hat, mostly around J2EE web applications. I used
to know TCL, but the rehab really helped.

In the interest of full disclosure, I actively contribute to puppet and
work on stuff building on it.

I will be out of town until Jan. 2nd, with unclear email access, so I
might be a little sluggish with responses - but you can always ask
questions on puppet-dev(a)reductivelabs.com or #puppet on freenode.

Puppet
======

The references like [N] are at the end and lead to docs/additonal info

PROS
----
      * Project lead (Luke Kanies) is experienced as sysadmin and
        consultant around system administratio, makes his living
        exclusively off consulting around puppet
      * Designed and implemented in direct response to experiences with
        other (and no) config mgmt systems like cfengine [5], isconf,
        sth proprietary etc.
      * Architecture
              * Clients connect to central server (but all sane cfg mgmt
                tools do that)
              * Clients report facts about themselves (OS/kernel
                version/release, MAC/IP address, basic HW info) to
                central server, which uses them to make decisions about
                client's config; the fact mechanism is pluggable and can
                be easily extended with custom facts
              * Server assembles config for client from sitewide
                description (manifest)
              * Can also be used standalone with cmd line tool for
                testing (or dirt simple single machine setups)
              * Use 'native' tools for all config tasks in the backend
                (e.g., yum for pkg mgmt on RH-derived systems)
      * Security
              * Thorough security model (each client has its own SSL
                cert) Puppet comes with tools to make basic SSL setup
                and cert generation very painless (puppetca)
              * Each client only gets to see the part of the site config
                that applies to it, not the whole site config
              * Builtin file server where file access can be secured
                per-client (e.g. only hostX gets access to
                hostX/ssh_host_key)
      * Cross-platform, works on most flavors of Unix
        (Fedora/RHEL/Debian/Gentoo, Solaris, OS X, some sort of *BSD
        IIRC)
      * Domain-specific language for manifest [2]
              * Clean abstraction from messy details of changing config
              * Describe desired config of system, puppet figures out
                how to get there (e.g., you say 'need user X with
                homedir /foo and uid N', puppet figures out appropriate
                calls to useradd/usermod depending on whether user
                exists and fixes attributes that are out of sync)
              * Abstraction: describe config in high-level terms (user,
                service, package, mount) for common config objects [3]
              * Templating support for things that can't/don't need to
                be described as objects; or distribute complete files
              * Group config items logically with classes: can describe
                that a webserver has to have latest httpd package,
                service httpd enabled and running, and custom httpd.conf
                file from location X (that's not possible with at least
                one of the other config mgmt tools)
              * Override mechanism for classes to allow for simple
                one-off (or hundred-off) tweaks, e.g. to take webserver
                class from above but use with different httpd.conf
              * Clean definition of what inputs can influence a client's
                config
              * Language makes config easily readable and comprehensible
                IMHO
      * Emphasis on practical usability, not research
      * Good set of unit tests
      * No EditFiles ;)
      * Cron-like support for scheduling actions during maintenance
        windows (on a per-config object basis, if need be, though in
        reality you want to keep that simple for your own sanity)
      * Tie-in with kickstart: provision basic system with ks (including
        puppet client), complete config with puppet [4]
      * RH interested in furthering it for other reasons, too
      * Active community, Luke is very responsive both with developer
        and user issues/questions
      * Beginnings of task-oriented user docs on a Wiki [6]
      * GPL

CONS
----
      * Not everybody is familiar with puppet's implementation language
        (Ruby)
      * Evolves rapidly
      * Some of the more esoteric features (like comprehensive
        reporting) are immature
      * Need to learn puppet's language to describe site config
      * Scalability in very large deployments unknown (there are
        production deployments in the low hundreds of machines)
      * Language is mostly declarative, but has 'exec' loophole for
        running arbitrary commands on the client for practical reasons

More info
---------
Puppet's website (http://reductivelabs.com/projects/puppet/) has lots of
more info; if you want to get more of an impression, I would start with
the following, in this order:
     1. http://reductivelabs.com/projects/puppet/faq.html
     2. Luke's BayLISA presentation from last year
        (http://video.google.co.uk/videosearch?q=Kanies+puppet) - the
        ones from August '06 are also very good but _long_
     3. The high-level introduction
        (http://reductivelabs.com/projects/puppet/documentation/introduction.html)
     4. Luke's puppet/cfengine comparison
        (http://reductivelabs.com/projects/puppet/documentation/notcfengine.html) and his
blog post about BCFG2 (http://www.madstop.com/articles/2006/08/08/puppet-vs-bcfg2) - gives
some more insight into the why's and how's of puppet and how the main author
contrasts it with what's out there.
     5. The language tutorial
        http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html


David

[1] http://people.redhat.com/dlutter/puppet-app.html
[2]
http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html
[3] http://reductivelabs.com/projects/puppet/documentation/typedocs.html
[4]
http://watzmann.net/blog/index.php/2006/12/05/kickstarting_into_puppet
[5]
http://reductivelabs.com/projects/puppet/documentation/notcfengine.html
[6] http://reductivelabs.com/cookbook/

[Axel Thimm]

Thanks for the puppet overview. Maybe we should create a wiki page
with a product/feature matrix?

On Fri, Dec 22, 2006 at 04:17:45PM -0800, David Lutterkort wrote:

>  PROS
>  ---- 

>                * Override mechanism for classes to allow for simple
>                  one-off (or hundred-off) tweaks, e.g. to take webserver
>                  class from above but use with different httpd.conf 
That's nice.

>        * Tie-in with kickstart: provision basic system with ks
> (including
>          puppet client), complete config with puppet [4] 
That, of course, defeats lots of the security items, but there is no
otherway. One just needs to be aware of that.

What about diffing support, e.g. compare what's there and what we'd
like it to become, kind of a dry-run session to check deviations
between spec and reality?
-- 
Axel.Thimm at ATrpms.net

[David Lutterkort]

On Sat, 2006-12-23 at 03:25 +0100, Axel Thimm wrote:
>  Thanks for the puppet overview. Maybe we should create a wiki page
>  with a product/feature matrix?
>  
>  On Fri, Dec 22, 2006 at 04:17:45PM -0800, David Lutterkort wrote:
>  
>  > PROS
>  > ----
>  
>  
>  >               * Override mechanism for classes to allow for simple
>  >                 one-off (or hundred-off) tweaks, e.g. to take webserver
>  >                 class from above but use with different httpd.conf
>  
>  That's nice. 
One thing I forgot to mention: puppet lets you also express dependencies
between config elements, so that you can say that the httpd package
should be installed/upgraded first before your custom httpd.conf is
copied from the central server. A similar mechanism also lets you say
that service X should be restarted whenever puppet needs to make a
change to file Y (useful to keep service restarts to the absolute
minimum needed)

>  >       * Tie-in with kickstart: provision basic system with ks
> (including
>  >         puppet client), complete config with puppet [4]
>  
>  That, of course, defeats lots of the security items, but there is no
>  otherway. One just needs to be aware of that. 
Yeah, it's not entirely watertight, but the holes that it leaves are
fairly esoteric (somebody posing as a client while you are installing
the client; somebody posing as the server while you are installing a
client), and you'll discover both breaches quickly (when the client you
are installing gets to the point where it asks the server for a cert;
the request will either fail or never show up on your server)

>  What about diffing support, e.g. compare what's there and what
> we'd
>  like it to become, kind of a dry-run session to check deviations
>  between spec and reality? 
Both the command-line tool and the client daemon have a 'noop' option,
that goes through the motions w/o making changes. After changes to
configs, I usually test them by running
        # /usr/sbin/puppetd -v --onetime --noop
which produces output like
        notice: Starting configuration run
        notice:
//common/lemon/autofs-server/configfile[/etc/sysconfig/autofs]/file=/etc/sysconfig/autofs/source:
is {md5}6cd456ce35b212ea429e63bf892d2535, should be {md5}3ed0678eb6af27c0a264522705e79a08
(noop)
        notice:
//common/lemon/autofs-server/configfile[/etc/auto.homes]/file=/etc/auto.homes/owner: is
build, should be root (noop)
        notice: //common/lemon/users/user=build/home: is /home/build, should be
/homes/build (noop)
        notice: Finished configuration run in 4.56 seconds

The lines are telling me that
      * /etc/sysconfig/autofs has different content from what it should
        be
      * /etc/auto.homes has the wrong owner
      * the user 'build' has the wrong home directory
Of course, puppet would fix all these if I ran that without --noop

David

[David Douthitt]

David Lutterkort wrote:
> > What about diffing support, e.g. compare what's there and
> what we'd
> > like it to become, kind of a dry-run session to check deviations
> > between spec and reality?
> >     
>  Both the command-line tool and the client daemon have a 'noop' option,
>  that goes through the motions w/o making changes. After changes to
>  configs, I usually test them by running
>          # /usr/sbin/puppetd -v --onetime --noop 
Cfengine also has a "dry
run" option, though only on the "client" side - 
then it is only the client that can make changes:

cfagent -v --no-splay --dry-run

Splay is the client's "run time delay" in order to spread out the load 
onto the server.  Low-tech (in my opinion) and not completely scalable, 
but decent enough nonetheless.

-- 
David Douthitt
HP-UX, Unixware, Linux, FreeBSD
RHCE, SCSA, Linux+, LPIC-1
http://www.lulu.com/ssrat