Configuring roles and profiles

Roles and profiles are two extra layers of indirection between your node classifier and your component modules.

The roles and profiles method separates your code into three levels:

• Component modules — Normal modules that manage one particular technology, for example puppetlabs/apache.
• Profiles — Wrapper classes that use multiple component modules to configure a layered technology stack.
• Roles — Wrapper classes that use multiple profiles to build a complete system configuration.

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:

• Your node classifier assigns one role class to a group of nodes. The role manages a whole system configuration, so no other classes are needed. The node classifier does not configure the role in any way.
• That role class declares some profile classes with include, and does nothing else. For example:

    class role::jenkins::primaryserver {
      include profile::base
      include profile::server
      include profile::jenkins::primaryserver
    }           

• Each profile configures a layered technology stack, using multiple component modules and the built-in resource types. (In the diagram, profile::jenkins::primaryserver uses puppet/jenkins, puppetlabs/apt, a home-built backup module, and some package and file resources.)
• Profiles can take configuration data from the console, Hiera or Puppet lookup. (In the diagram, three different hierarchy levels contribute data.)
• Classes from component modules are always declared via a profile, and never assigned directly to a node.
  • If a component class has parameters, you specify them in the profile; never use Hiera or Puppet lookup to override component class params.