Puppet is a mature and established configuration management system. We’ve used Puppet since 2006 and have followed it’s growth and success with interest.
A common challenge for an organisation running Puppet is how balance the desire for a fully automated and standardised environment, with the risk that automated Puppet runs may introduce bugs or revert hot fixes.
It’s common nowadays for sysadmins to manage very large numbers of servers - often virtual servers created on-demand in cloud platforms like Amazon EC2. How do you build so many servers and keep them updated - automatically, reliably, and quickly? John Arundel discusses the merits of image-based strategies and compares and contrasts them with an approach built around system automation and configuration management tools.
In the first part of his excellent Puppet tutorial, John Arundel suggests that, given the speed with which Puppet develops and changes, and to keep things simple, Puppet should be installed from source. While for one box, this may be true, I tend to the view that you should use the native package manager wherever possible. In the case of CentOS or Redhat (the most common platforms for Puppet users, our survey says) , this means building RPMs. This article shows you how to build reusable puppet and facter RPMs, to make your life easier when you graduate from managing puppet on one server, to controlling a whole datacentre.