The roles and profiles pattern adds two additional layers of abstraction between your node classification at the highest level and component modules at the lowest, thus providing three levels of abstraction in your Puppet modules. The following descriptions go from the most complex to the least:

• Component modules: These are modules for the management of software for your business. There will no doubt be a bunch of these that you've downloaded from the Forge (for example, puppetlabs/apache, puppetlabs/mysql, hunner/wordpress, and so on), and no doubt also some that you have developed for your own business-specific purposes.

We've discussed these already at length in Chapter 1, Authoring Modules, so here's the rub:

• Profiles: A set of encapsulated technology-specific classes that use one or more component modules and corresponding business data to configure part of a solution stack
• Roles: A set of encapsulated business-specific classes that comprise profiles to build a complete system configuration

These two additional layers of abstraction and improved interfaces make hierarchical business data easier to integrate, system configurations easier to read for both business people and technologists, and they make refactoring easier.

The following UML diagram shows the relationship between the elements in the pattern more clearly:

From the preceding diagram, we can see the following:

• A Node has exactly one Role
• A Role comprises one or more Profiles
• Profile comprise one or more Component Modules and corresponding Hierarchical Business Data
• Component Modules comprise many Resources

Puppet resources should already be very familiar to you, and we've already covered component modules in Chapter 1, Authoring Modules, so in the following two sections, let's take a deep dive into the profile and role part of the pattern.