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:

Culture

Inside puppet

Puppet 4

Case studies

Modern infrastructure

Puppet applied

Security

Windows

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:

Puppet troubleshooting

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.

Puppet templates

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.

#dev