[sf-perl] lack of perl in config management - problem?
james at ActionMessage.com
Fri Dec 16 16:29:38 PST 2011
For the benefit of those who don't know the high-level difference
between this system and Puppet or Chef, the former just builds a server,
while the latter both builds a server and maintains/enforces the
configuration on the server over time.
(ie. almost all of the internal ones "run out of gas" compared
to the new public config projects.)
If you're using a redhat-flavored system, then most of what is
mentioned below can be done with a few lines of Perl added to
kickstart/anaconda. (Testing and tweaking it is time-consuming though.)
Also, most sysadmins can configure kickstart/anaconda, but Puppet or Chef
is more of a Ruby programming project once you get away from the canned
recipes (sample scripts.)
On Fri, 16 Dec 2011 11:18:17 -0800, Earl Ruby wrote
> When my company first started building servers en masse about 8 years
> ago we knew we needed a configuration management tool and looked at
> what open source tools were available at that time. At that time none
> met our needs, so we ended up writing our own, mostly in Perl with
> some bash.
> Our goals were:
> * We wanted to be able to easily integrate new configuration scripts
> into the framework.
> * We wanted to be able to stage changes on staging/QA servers and
> then move them into production. * We wanted a class hierarchy, so
> that we could assign a server to multiple classes (e.g. "base",
> "base-sanfrancisco", "apache-server", "admin-tools"). * Each class
> can override configurations in the parent class, so "apache-server"
> would build a base Apache server, and "admin-tools" would install
> web-based administration tools, some of which might override the
> settings in the apache-server class. * Each host can also have host-
> specific settings which override the base classes, so if you need to
> tweak settings on just one host you can. * We wanted to be easily
> able to tell what configuration had been applied to any host, and to
> keep all of the configurations in one place. If you want to
> understand why something is set up in a certain way on a host, it's
> easy to find the configuration and see what script made which
> changes. * We wanted to be able to lock down specific versions of an
> OS, its patch set, CPAN tools, and our own packages, so that every
> server is built using the exact same versions of all software packages.
> * We wanted new servers to automatically plug themselves into our
> Nagios monitoring system.
> * We wanted to be able to take any server, reboot it, type 'inst-
> auto' at the boot: prompt, and have it go from bare metal to fully-
> configured without any additional manual intervention.
> We built all that, but maintaining it takes time, and it's not our
> core competency, so we looked at moving to Chef or Puppet. What we
> found is that neither Chef nor Puppet implements classes the way we
> have and neither one gives us the one-button build capability that we
> wanted. Chef scales and scales, but is a huge undertaking to set up
> and maintain. Puppet runs out of steam somewhere between 100 and 1000
> servers, and is difficult to scale beyond that. Our system scales
> infinitely, and it's dead-simple to set up an understand.
> We looked at extending Chef or Puppet using the tools we'd written,
> then realized that what we'd written was actually pretty damn good.
> We are currently working to strip out the company-specific parts of the
> framework, clean up the code, and release it as open source. We hope
> that by doing so that other system engineers can extend it and add
> capabilities that we would like to have but don't have time to add
> We will probably be doing an initial release in about 3 months. I'd
> be happy to do a demo for Perl Mongers when it's released.
More information about the SanFrancisco-pm