homeblogwhat are some best practices for learning puppet

What Are Some Best Practices for Learning Puppet?

Last week, I hosted a webinar titled the "Best Practices for Learning Puppet". Although there are several ways that you can master the Puppet DSL, I chose specifically to discuss our Learning Puppet VM because I find it to be the fastest and easiest way you can learn Puppet. For those of you who don't know, the Learning Puppet VM is a free virtual machine with a series of tutorials about the Puppet language and tools. Check it out here!

Although I primarily walked through how to install the Learning Puppet VM during the webinar, I received a number of interesting questions about a wide range of topics that extended beyond the scope of the webinar! Unfortunately, I didn't have the time to answer all of them, but I'd like to share some of the questions I found particularly interesting and relevant to learning Puppet and mastering basic concepts:

How are the configs distributed over the other nodes? On a high level, how does it work? So you applied the .pp to the Puppet Master itself, yes? Is there a ready configured node also as part of the tutorial?

In a master/agent puppet environment, the agent submits facter facts to the master, which are then used to compile a unique catalog of resources to be managed specific to the requesting agent. This ensures that the agent is just receiving a list of resources and the states they should be in. When writing manifests, you are describing to the puppet master how you want resources to look, it then uses those manifests to compile a unique catalog of resources for the agent, which are then distributed back down to the agent. All of this communication happens in a SSL tunnel with certificate authentication in both directions, for security.

In the Learning Puppet VM, the node is also an agent of itself. The second half of the Learning Docs goes into more depth starting here about the master/agent relationship and communication.

Is the best practice to name the puppet-master machine "puppet" to ease the management (hardcoded in clients)?

Puppet will try to contact a master at "puppet", most operating systems resolver configuration will add on the domain component automatically (ie, puppet.mycompany.com), but Puppet does not do this internally. At installation time, Puppet Enterprise does include this alternative DNS name on the certificate for the master, so as long as there is a DNS entry created to point to this, it would allow for minimal configuration of the clients to talk to the master. The Puppet Enterprise Agent installer also allows for passing it an answers file containing the masters name, so you are still free to use other hostnames that may be more appropriate to your organizations naming schema.

If there is an error condition, in the middle of the script how would you recommend rolling back what actually was completed.

Puppet doesn’t send ‘scripts’ to the agents, instead it sends a list of resources and what states they should be in. The puppet agent then acts on that information to make the resources match the intended state. In that regard, if a puppet run fails on the agent, it it will report back how (unable to install a package, so dependent resources on that package were also not applied) it failed so one can remediate it. Since the rest of the puppet run will continue to manage the resources that didn’t fail, one could roll back and apply the previous version of the manifest files (we recommend storing all of the puppet code in a version control system such as Git or Subversion in part for this reason), or just determine what caused the failure (lack of access to a Yum repo to install the necessary pack), and once fixed just perform the puppet run again. Since Puppet includes a NoOp mode, you can also simulate all of your puppet runs without performing changes on your system. Using NoOp mode to simulate changes, along with the fact that Puppet is idempotent and only changes things on the system that it needs to, and that you can model the explicit dependencies between resources means that if you do have a failed puppet run, you can easily troubleshoot the failure and once fixed you could perform another one to remediate the issue.

Hopefully you've found the questions and my answers above helpful! We've received a lot of requests for more entry-level information and resources about the Puppet Enterprise universe, so stay tuned for more webinars similar to our Best Practices of Learning Puppet. If you have any additional questions, please feel free to drop them in the comments below.

If your question wasn’t addressed in this blogpost, feel free to sign up for an account at ask.puppetlabs.com and submit the question there.

Additional Resources

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.