[sf-perl] lack of perl in config management - problem?

[Earl Ruby]

No, the system I just described ("the former") both builds the system
(like kickstarter), does the initial configuration, and maintains the
configuration over time.

If you're just buying VMs from a cloud host you don't need the build
portion, but you do need the initial configuration and maintenance
portions.



On Fri, Dec 16, 2011 at 4:29 PM, James Briggs <james at actionmessage.com> wrote:
> 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.)
>
> James Briggs.
>
> 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
>> ourselves.
>>
>> 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.
>
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm



-- 
Earl Ruby
http://earlruby.org/