Non-Puppet best practice

A friend of mine asked me how I use puppet and what I consider best practice. He thinks I still use puppet as I gave a talk about it 6 years ago (in Hungarian).
(Oh, that was quite a while ago :-) )

At that time I really thought Puppet is the way to go, but a few years ago I really did not have time to keep puppet up and running as I was reassigned at work to another organizational unit and many thing changed at once.

About a year ago I revisited the idea of reviving/redeploying puppet, but as my thinking changed recently I started to feel more disgust as I tried to use it again.

There are usability problems, upgrade incompatibilities, receipts requiring newer puppet etc... I will not go into the details as Martin summarized it quite well and I agree with him.

Slaughter instead

Instead of puppet I use slaughter now. Only for some basic things like:

  • deploying configuration files
  • installing packages
  • adding all admins with ssh keys to all machine

and I did not yet deployed it to all machine.
Still I feel confident because of Perl. There is no hidden magic involved. No DSL to learn. It has less power, but much more easier at the same time.

General ideas, may work with puppet...

My idea (that requires some work in Slaughter) is to use some external database/data structure and using that instead of defining the same multiple times.

What do I mean? I do not want a fancy way to configure DNS, Nagios, Graphite, PF and defining the same over and over again.
Instead define it once "here in my public http service running on host myhost.domain port 80" then the configuration management should generate a

  • DNS record for the host (if it does not have already)
  • configure the firewall to let port 80 throu
  • install apache on the host
  • monitor the service

Puppet has a mechanism (module?) called Hiera that lets you do this. I think with Chef this is built-in. (Chef is so hard to start with that I did not dared to try it at all.)

recent link http://blog.steve.org.uk/more_competition_for_server_management_and_automation_is_good.html