PuppetConf is a yearly conference for Puppet DevOps automation software. This year’s conference was held in San Diego, CA. As one of the largest DevOps automation conferences in the United States, PuppetConf is a big event. With over 80 sessions, 100 speakers, and 1,500 attendees the conference was a great source of DevOps automation information.
This year, the conference was a split into several different phases. The first two days (October 17 and 18) were mainly focused on Puppet training courses. Wednesday (October 19) focused more training along with the Puppet Contributor Summit. The Puppet Contributor Summit provided information, product sneak peaks, and community interaction for Puppet users and contributors. The final two days (October 20 and 21) were focused on educational sessions presented by both Puppet employees and industry experts.
The sessions were split into eight different topic tracks:
While there were plenty of sessions dealing specifically with Puppet itself, there were still a great number of opportunities to learn more about practical DevOps in general.
Here are some of my personal highlights from the conference:
Supporting and diagnosing issues with Puppet and other automation platforms can often be just as difficult as building the implementations themselves. Having a set of processes and procedures to follow can speed up the diagnosis phase by quite a bit. Thomas Uphill, who lead the presentation, covered basic troubleshooting methods, API usage for problem detection, common certificate authority issues, and usage of Ruby Pry to debug catalog compilation. More information is available in the description of Thomas’ presentation.
The challenges with container configuration
Containers are at the forefront of the minds of developers and DevOps engineers these days. Applying containers to infrastructure automation can present some definite challenges, which David Lutterkort went over in his talk. Using demos and identification of common problems and their solutions, David covered several operational challenges that engineers might face with containers. If you have questions with how to overcome the usual issues, you can find additional material on David’s talk here.
Puppet design patterns: Lessons from the Gang of Four
The Gang of Four Design Patterns book is a well-known tome of knowledge in the software development industry. However the idea of patterns can and should be applied to your Puppet implementation and configuration. David Danzilio’s talk was a great exploration of how to solve problems using Puppet design patterns. For more information regarding David’s talk, you can look over the session details.
Templates are files that utilize code, data, and text to produce a final rendered output. The goal of a template is to manage a complicated piece of text with simple inputs. Templates simplify Puppet configuration file management. Sally Lehman’s presentation went over when to use the different templating options (EPP and ERB), how to create/update their own templates, and various best practice tips.
If you’re having a rough time getting your Puppet configuration organized, the Puppet Templates talk is a great one to watch. For more information, check out the sessions description here.
Things I learned
There was a lot more information available at PuppetConf than could possibly be consumed by a single person, but there were definitely some key points that I found enlightening.
Design patterns and templates aren’t just for normal software development
I will admit that I’m guilty of only considering design patterns and templates for use with software development. Applying design patterns and templates to DevOps automation is a natural next step in speeding up the operations life-cycle and ensuring long-term support of those systems. As you would expect, not having to ‘reinvent the wheel’ when it comes to setting up operations processes gives DevOps engineers more time back to devote to running the systems.
Containers add a whole new level of usefulness and complexity to DevOps
The rise of containers and container management solutions has been meteoric in the last few years. While these containers have provided more modularity and an increased ability to shift to a micro-services architecture they have also caused a fair bit of confusion and frustration from DevOps teams having to support and account for their presence. Having used Docker for a few startup projects on the development side, I had neither explored the potential for containers in DevOps nor had I realized the potential problems containers presented for DevOps teams.
Final thoughts and information for next year
PuppetConf 2016 was a great experience, even for someone like myself who mainly operates on the development side of things.
Having a better working knowledge of one of the main DevOps automation platforms along with a deeper understanding of the developer operations processes enables software developers to make better decisions about the code they write. It’s all too easy to forget that the things we create have to be run in the real world and things aren’t always as neat and tidy as they can be in your local dev environment.
Rumor has it that next year’s PuppetConf will be in San Francisco, bringing things back to the Bay Area. If it is anywhere close to PuppetConf 2016 then it will definitely be a must attend event in 2017.