Puppet Best Practices

Chapter 5. Resources

Resources are the heart of Puppet’s state management. Resources model a configurable entity on a node. The vast majority of resources model things you’re quite familiar with, such as:

• Files

• Packages

• Package repositories (yum, apt, chocolatey, etc.)

• Users

• cron entries

• Databases

• Windows registry keys

Resource types declare the desired state (a model) of the resource, and resource providers converge the target to match the model. Put another way, types are the interface, and providers are pluggable platform-specific implementations.

This chapter reviews the built-in Puppet types and providers, along with popular custom types. We examine how to best use virtual resources, exported resources, resource relationships, and metaparameters.

Using Resources to Implement Change

Resources evaluate and manage state of their type on nodes. No matter how complex the codebase is, the manifests are ultimately compiled down to a catalog of resource declarations, which is what the Puppet agent uses to evaluate and converge a node. Resources are the only way Puppet can idempotently affect change on your nodes.

Warning

exec resources can also affect node state, but they create untrackable, unknown changes that are antithetical to the purpose of Puppet.

Resource Types Abstract Implementation Details

A Puppet resource type is an abstraction layer and interface between Puppet and the underlying provider. You implement types in Ruby by declaring a child of the