Puppet Best Practices

Chapter 1. The Puppet Design Philosophy

Before we begin to explore best practices with Puppet, it’s valuable to understand the reasoning behind these recommendations.

Puppet can be somewhat alien to technologists who have a background in shell scripting. Whereas most scripts are procedural, Puppet aims to be declarative. This allows it to take a node from an unknown state and converge it to a known, desired state.

Puppet’s declarative design principles drive the practices in the coming chapters. Although the declarative language has many advantages for configuration management, it does impose restrictions on the approaches used to solve problems. Understanding the philosophy behind the design will help contextualize the recommendations covered in this book.

Declarative Code

As we discussed a moment ago, the Puppet domain-specific language (DSL) is a declarative language, as opposed to the imperative or procedural languages with which system administrators tend to be most comfortable and familiar.

Note

Imperative language declares the actions to accomplish a task. Declarative language declares the desired result. You’ll see examples of these differences as we proceed.

In theory, a declarative language is ideal for baseline configuration tasks. Because declarative language defines the result, and not the path to get there, the Puppet language is (mostly) verbless. Using the Puppet DSL, we describe only the desired state of our nodes. Puppet handles all responsibility for making ...