[Puppet-users] What I'm doing with Puppet

[Tim Stoop]

Hi all,

Just reading through Luke's interview on computerworld.com.au and I
came across this statement:

"This topic comes up on the list periodically, however, and most
people are very tight-lipped about what they're doing with Puppet."

Being the chattermouth that I am, I'd like to take this opportunity to
tell you all what we're (that is, my company, Cidev, based in The
Netherlands) doing with Puppet and why we like it. Even though I've
only started using it about a week ago...

Our new customer (which I'm not going to name at this time, but you
probably haven't heard of him, because it's a pure b2b company) needed
a high-available setup, consisting of 14 servers and providing several
services like web, servlets, database, you name it. Think about your
ideal web platform, add some proprietary stuff and that's basically
it. Required uptime: 99.9999999% (we only offered 99.99% though).

In the years doing service maintenance we've learned the power of
virtualisation. Even when a server only provides 1 service, we put it
in a virtualised environment. It helps a lot in maintenance and
general "stuff you can do at a distance". I.e. updating kernels, if
you want to be really sure it doesn't give you downtime, requires a
test setup and usually your direct presence or remote console stuff.
With Xen (the virtualisation we use) we can do it simply from the
dom0. There's more, but, since Puppet is a sysadmin tool and I expect
most of you to be sysadmins, you can probably think of some stuff
yourself.

But, that also means you at least duplicate the number of servers you
maintain. So 28 servers needed to be maintained. We splitted some
services onto their own virtual domain, for safety, so that can amount
quickly to 35~40 servers in the end. Ow and they have to be ready
yesterday. Yeah, we know you had to start two weeks late because the
machines were delivered late and Internet wasn't available for two
week, but we still got our deadlines. Well... needless to say, not
only did we need a convenient way to adminster the servers, we also
needed fast deployment.

Now, xen-create-image (on Debian at least) supports roles, which are
basically scripts that can do some stuff after installation to fix up
the installation the way you want it. Great. It took me almost two
days to create a role that did exactly what I wanted, create a basic
installation the way we do it. Then I switched to puppet. I learned
puppet and recreated the basic installation script in one day. And now
we got advanced config replication foo. That's important since
high-availability means you have several servers configged exactly the
same.

A deadline passed today and I'm quite sure I only made it because of
the use of Puppet. It still took me to 3.30am last night, but once I
had one server running, I only needed to add the script to the other
servers which were supposed to be about the same. Done. Loadbalancing,
webserver, HA-NFS working.

Thank you for Puppet!

Now, for my wishlist, Santa! What I would like to see support for in Puppet:
- LVM (I need to create large amounts of partitions, would be great if
I could do that centrally and no, sorry, the RH conga framework
doesn't work for me)
- DRBD (if we can make the partitions, we can network-raid-1 them...)
- Xen domU (just a convenient way to create domU *configs*, not create
the entire image, since I guess that would be a bit difficult)
- Xen domU (the entire image... yeah, it's a wishlist so why not)
- apt-get --purge option
- apt-get dist-upgrade (preferably on demand only)
- report-back framework (oh noes! client 375 had an error while trying
to run manifest Foo, let's have the puppetmaster mail the Sysadmin
Donkey so he can fix it)
- nagios integration (I can dream, can't I?)
- support for something like:

exec { "mycommand with some arguments":
  unless => file { "/tmp/idonotexists": test => exists }
}

-- 
Kind regards,
Tim