Best Practices

This guide includes some tips to getting the most out of Puppet. It is derived from the best practices section of the Wiki and other sources. It is intended to cover high-level best practices and may not extend into lower level details.

Use Modules When Possible

Puppet modules are something everyone should use. If you have an application you are managing, add a module for it, so that you can keep the manifests, plugins (if any), source files, and templates together.

Keep Your Puppet Content In Version Control

Keep your Puppet manifests in version control. You can pick your favorite systems — popular choices include git and svn.

Naming Conventions

Node names should match the hostnames of the nodes.

When naming classes, a class that disables ssh should be inherited from the ssh class and be named “ssh::disabled”

Style

For recommendations on syntax and formatting, follow the Style Guide

Classes Vs Defined Types

Classes are not to be thought of in the ‘object oriented’ meaning of a class. This means a machine belongs to a particular class of machine.

For instance, a generic webserver would be a class. You would include that class as part of any node that needed to be built as a generic webserver. That class would drop in whatever packages, etc, it needed to do.

Defined types on the other hand (created with ‘define’) can have many instances on a machine, and can encapsulate classes and other resources. They can be created using user supplied variables. For instance, to manage iptables, a defined type may wrap each rule in the iptables file, and the iptables configuration could be built out of fragments generated by those defined types.

Usage of classes and defined types, in addition to the built-in managed types, is very helpful towards having a managable Puppet infrastructure.

Work In Progress

This document is a stub. You can help Puppet by submitting contributions to it.

↑ Back to top