PuppetConf 2014

Presenter: Andrew Parker
Co-Presenter: Kylo Ginsberg

Puppet 3 is winding down. The series has had many feature releases, even more bugfix releases, and lots of activity. Puppet 4 should be an even more exciting major series. I will explain many of the changes in mind for Puppet 4, ranging from how the compiler works to the communication protocols that Puppet will use to get more scaling and flexibility.

In large environments, especially constantly changing, living systems, it can be difficult to maintain control. Puppet helps, but some scenarios require scaling the Puppet infrastructure to support thousands of nodes across multiple cloud and physical environments in different locations. This overview of how to keep control of your infrastructure with Puppet will feature guidelines for:

• Scaling Puppet with a web cluster (Apache/Nginx)


• Reducing the load on puppet masters through web caching (apache mod_cache)


• Controlling Puppet environments through source code management (git)


• Managing multiple data centers and environments with Puppet (branching environments)


• Deploying Puppet masterless in the cloud

Recent versions of Puppet and Puppet Enterprise enable much more sophisticated use of certificates than before. I'll go into detail on the improvements in signing and how to use them end-to-end, with an emphasis on public/private cloud deployments.

What if there was a tool that lets you create a custom deployment pipeline for changing and deploying Puppet code? How would it work? What would the workflow be? Come design it with us! 

What’s a design jam?
A hands-on workshop in which we collaborate on solving a problem. If you can draw boxes, you’ve got all the drawing talent you’ll need.

Puppet is an incredibly powerful tool, and part of that power is its flexibility. Flexibility often leads to a wide range of ideas on implementation. I've consulted on countless Puppet implementations, and I've seen the entire spectrum, ranging from bat-shit insane to picture perfect. But even the bat-shit insane implementations worked (to a point), and at some point, what seemed bat-shit to me was picture perfect to the folks running it. As I got to understand some of the unique implementations, I started to ask myself: if there's no clear right way to implement Puppet, is there a particularly effective way?

When trying to answer this question I started by looking at the teams who got it right, and a pattern quickly emerged. All of these teams had common behaviors that went far beyond policies and procedures. These behaviors were broadly understood by team members, nearly universally adhered to, and almost second nature. These habits led to more stable, maintainable, and well understood Puppet deployments. In this talk, I'll share with you the behaviors I saw and discuss how you can turn these seemingly obvious best practices into habits amongst your team members.

What if Puppet provided you with insight into your nodes without Puppet installed? What would you do with that insight? Come design the tool you’d like to use.

What’s a design jam?
A hands-on workshop in which we collaborate on solving a problem. If you can draw boxes, you’ve got all the drawing talent you’ll need.

Safely exposing Hiera data to large teams can be challenging. Who has access to which values?

This talk will discuss a pattern and introduce some new tools for providing limited/delegated Hiera data access to large teams.

PAMI is an institution managed by the Argentinean government and is a fully comprehensive public health care service provided to retirees and pensioners. Today, they maintain more than 4.5 million members, 120 health care centers and 700 offices that are distributed across the country.

PAMI proposed the creation of an entirely new IT platform in four months. The objective was an infrastructure that would not only comply with a 99.95% of uptime YoY, but would also enable them to improve the services provided to their members, therefore maximizing all available resources. To do this they tasked Edrans, a group of Puppet and virtualized infrastructure experts, to design and implement a viable solution. We're here to talk about the challenges we faced and the solutions that emerged from this, both from a cultural and a technical perspective.

Puppet is easy to use and understand for modeling a desired configuration state within the bounds of a single system. For multitier applications however, or configuration involving data and content distributed between variable numbers of systems and tiers, the modeling gets more complex.

This talk will use Puppet Labs Professional Services’ implementation of a flexible-architecture Puppet Enterprise deployment as a case study to talk specifically about:

* Minimizing required configuration input for multitier apps
* Using Puppet to model variable size app tiers of expandable and contractible size
* Art of the Possible and constraints to be aware of when using only pure Puppet and its eventual consistency configuration model

The intended audience is advanced Puppet users interested in pushing Puppet to today’s multitier limits. The talk will incorporate specific code examples and a full working implementation of a Puppetized mulitier app. It will be accessible to general Puppet practitioners looking for an art-of-the-possible level understanding.