This is a reflection on the 3rd and final day of PuppetConf pre-conf training. The full conference took place on Thursday and Friday. To see what we’ve done on Monday & Tuesday check out my previous posts on Day 1 and Day 2.
By the third day in class, we had built out enough scaffolding (both virtual and cerebral) to leverage additional features of puppet enterprise in a master/agent environment and further expand to, testing, deploying and analyzing the modules that we’d created in class as well as a few module from the community.
As an example of the in class exercise, we progressively developed and deployed an apache module to install the package(s) and dependencies and configure it to serve up several virtual hosts on a single server. We then used Puppet to further configure each individual virtual host to publish a dynamically generated index page containing content that pulled from the server information that facter knew about. This last part was accomplished via ‘erb’ templates, pulling in facter facts and some variables from our own classes.
We also listed, searched for, downloaded and installed modules from the Puppet Forge. This was a great experience because at this point in the class I now felt like I had a better working understanding of the structure and purpose of each of the components of a module. Even though I still may not yet feel confident enough to author and publish my own puppet module, I do feel I can pick a part and evaluate an exisiting module that is provided by a community member who likely had much more experience using Puppet. Nothing like standing on the shoulders of giants to get started using a powerful tool. That’s the way I learn a lot of things, buy observing how others who have gone before me do it and then taking that knowledge and information and recombining it into something that meet my own specific purposes.
The balance of the remaining lecture and slides covered topics of class inheritance to share common behavior among multiple classes by inheriting parent scopes and how to override parameters should you prefer not to use the default values.
Hiera yaml was introduced as an external data lookup tool that can be used in your manifests with key:value pairs to obfuscate the actual variable values. I need to understand this particular tool better to get a feel for how it will be helpful. On the surface, it seems to be useful for publishing reusable manifests without revealing or hardcoding info from a particular environment.
Live management is a cool feature of the puppet enterprise console that we went over in class. Live Management can be used to inspect resources across all nodes managed by a Puppet Enterprise server. This is a powerful tool that provides the ability to inquire live across an entire environment – say check for a package or user, where they are and how they are config’d including the number of any variations. Live management can also be leveraged to instantiate changes live on managed systems. After covering the concept and seeing a few demonstrations of the GUI console in the lecture, we started a Live Management lab using our classroom infrastructure. This lab exercise was a bit ‘character building’. It required that all 15 of the students nodes connect up to the instructor’s master server and then ask that server to turn around and live query all of the managed agent nodes (that’s 15 agents each querying 15 agents… from a single training VM (2GB RAM, 2 vCPU) on the instructor’s laptop. Obviously an under-provisioned VM running on the modestly equipped instructor laptop was not representative of a production deployment and it was felt. Things timed out… the task queues filled up, the UI became unresponsive… students scratched their heads, instructors sighed and grimaced. This was pushing the envelope. Approaching the latter part of the final day of the course, and this was the very first exercise/demo that had gone even a bit awry. As technologist, everyone in the class understood what was going on, the reason for it and what we were supposed to get out of doing the exercise. We moved on and wrapped up a few more items included in the training agenda with a good understanding of the capabilities of Live Management in Puppet Enterprise.
Overall, I found the course sufficiently challenging and even though I am Not a Developer I survived the full three days and can still honestly say I stand by with my assessment on the first day of class:
“The quality of the content, the level of detail provided for the exercises and the software provided are all knit together perfectly. It is immediately evident that a significant amount of effort has be invested to ensure that there are minimal hiccups and learners are not tasked with working around any technical hurdles that are not part of the primary learning outcomes. If you struggle with some part of an exercise, it is highly likely that that is exactly where they want you to experience the mental gymnastics, not an artifact of an unexplored issue.
Whether you are getting started with Puppet or a user who has not yet been provided an opportunity to attend Puppet Labs training I highly recommend the Puppet Fundamentals for System Administrators course. It is a very good investment of your time, resources and brain power.