Puppet is an immensely powerful tool for system administration, but with great power comes great responsibility, and it’s not always obvious how to structure your configurations. There are many different ways to accomplish similar goals, and this malleability has given rise to a plethora of different design and architecture principles - some of which are good, and many of which are bad.

In this talk, Ben and Dan will explain the guiding principles of responsible Puppet design and architecture, walking you through real-world examples in order to illustrate solid methodological approaches, and illuminate Puppet administrators of all skill levels. As an added bonus, we will also show you how Puppet can be integrated into automated deployment and continuous integration platforms - an increasingly important component of today’s development and operational landscape.

This talk will include such topics as:

- The separation of data and logic: How not to commit such Puppet sins as hardcoding credentials, paths, and other sensitive variables into your modules.
- External data sources: There are a variety of ways to interface Puppet with other data sources, including Heira, puppet-db, extlookup, dilly, and more.
- The tiered manifest approach: Leveraging different granularity levels for fine-grained control.
- Module-writing best practices: Why it’s important for modules to be as generic as possible, and how to deal with differing environments and edge cases.
- Explicit sanity preservation: Verifying the validity of the incoming values.
- The importance of useful log output: Puppet has mature logging facilities built-in. Use them to get useful output in your dashboard, in email digests, and running manually triggered Puppet runs.
- Recommended (and enforced) style guides: Machine-readable manifests are good, but human-readable manifests are better.
- A comparison of visualisation tools: Everybody loves charts and graphs. Dashboards, reports aggregators, and automated metrics for the pointy-haired boss in your life.