I started using Puppet ahead of deploying a new infrastructure and simply bought a (well-regarded) book on the topic. I don’t think most people actually obtain professional Puppet training. I worked on examples until I could mold the process to my environment. This was December 2011, so within a few weeks, I was able to understand the basics and get a production framework in place. I wasn’t new to configuration management, having a CFEngine background, but many of your sysadmins’ concerns resonate. I made mistakes and had to refactor several times, but I did get things working satisfactorily.
A few notes on your points…
-
The traditional systems administration role is changing. Adapt or be left behind. I’ve been a successful systems engineer, but am having to retool as well (learning Python, for example). The focus on individual servers is diminished as hardware abstraction through virtualization and public and private cloud services gain traction. This means automation of systems tasks and the use of configuration management to wrest control of a larger number of servers. Add DevOps concepts to the mix, and you’ll see that the customer/end-user expectations and requirements are changing.
-
Puppet modules available online differ in style and structure and yes, I saw lots of overlap, redundancy and duplicated efforts. One developer I worked with said, “you could have developed your own tools in the time you spent looking online for something that works!” That gave me pause as I realized that Puppet seems to appeal more to developer types than admins looking for a best-practices or the right way approach.
-
Document heavily in order to get a feel for how things are connected. Given the shaky definitions and lack of a standard way of doing things, your configuration management structure really is unique to your environment. That transparency is going to have to be developed within.
-
I’d argue that it’s reasonably easy to duplicate a module to accommodate a new daemon or add a service to an existing manifest, depending on how you’ve organized your servers and roles.
-
I spent a lot of time testing on a single target before pushing changes to larger groups of servers. Running puppetd by hand on a representative server allowed me to debug changes and assess their impact. Maybe that’s a bit conservative, but it was necessary.
-
I’m not sure how much I’d depend on community modules. I did have to start using Augeas for some work, and lamented the fact that it was a functionality I took for granted in CFEngine.
In all, I feel like there isn’t a well-defined standard when it comes to Puppet. I had trouble figuring out how to organize directory structure on my Puppetmaster, understanding how to manage certificate signing, getting proper reverse DNS in place everywhere, getting Puppet to scale appropriately for the environment and understanding when to leverage community modules versus building my own. It’s a shift in thinking and I see how that would make a sysadmin panic. However, this was also solution built from scratch, so I had the luxury of evaluating tools. The decision to go this way was based on mindshare and the momentum behind Puppet. It was worth the effort to learn something new.
Remember, this site is a good resource, too.