puppet overview - pros and cons
David Lutterkort
dlutter at redhat.com
Sat Dec 23 00:17:45 UTC 2006
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 at 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/
More information about the infrastructure
mailing list