Your typical goal with Puppet is to build complete system configurations, which manage all of the software, services, and configuration that you care about on a given system.
Building system configurations can be challenging — mostly because the systems you manage are complicated. To keep that complexity under control, your code needs to be reusable, easy to configure, and easy to refactor.
The roles and profiles method is the most reliable way to build reusable, configurable, and refactorable system configurations. It’s not a straightforward recipe: you must think hard about the nature of your infrastructure and your team. It’s also not a final state: expect to refine your configurations over time. Instead, it’s an approach to designing your infrastructure’s interface — sealing away incidental complexity, surfacing the significant complexity, and making sure your data behaves predictably.
Roles and profiles are two extra layers of indirection between your node classifier and your component modules. This separates your code into three levels:
These extra layers of indirection might seem like they add complexity, but they give you a space to build practical, business-specific interfaces to the configuration you care most about. A better interface makes hierarchical data easier to use, makes system configurations easier to read, and makes refactoring easier.
In short, from top to bottom:
That role class declares some profile classes with include
, and does nothing else. For example:
class role::jenkins::master {
include profile::base
include profile::server
include profile::jenkins::master
}
profile::jenkins::master
uses rtyler/jenkins, puppetlabs/apt, a home-built backup module, and some package
and file
resources.)Without roles and profiles, people typically build system configurations in their node classifier or main manifest, using Hiera to handle tricky inheritance problems. A standard approach is to create a group of similar nodes and assign classes to it, then create child groups with extra classes for nodes that have additional needs. Another common pattern is to put everything in Hiera, using a very large hierarchy that reflects every variation in the infrastructure.
If this works for you, then it works! You might not need roles and profiles. But most people find direct building gets difficult to understand and maintain over time.
Now that you understand what the roles and profiles method is, you can learn how to use it with a simple (but not oversimplified) example workflow.