The roles and profiles pattern: What is it? How do I use it to manage my infrastructure and configuration more easily?

The roles and profiles pattern helps organize Puppet code and eases some of the challenges of managing infrastructure as code and maintaining configuration over time. It is the most reliable way to build reusable, configurable, and refactorable system configurations. It’s an approach to designing your infrastructure’s interface — sealing away incidental complexity, surfacing significant complexity, and making sure your data behaves predictably.

Setting up roles and profiles is not straightforward. You must think about the nature of your infrastructure and team. Expect to refine your configuration over time.

What is the roles and profiles pattern?

The roles and profiles pattern adds two layers of abstraction between your node classifier and the component modules that manage your services and applications. Roles and profiles are wrapper classes in Puppet modules, usually named role, and profile. The profile layer abstracts customization for the site. A role is a group of profiles used to model a specific host type.

You can hard-code information in profiles or use Hiera to pass data to a parameterized profile. Parameterizing allows you to add logical, site-specific information. For example, if your site uses more than one domain, add a domain parameter. If you only have one domain, you don’t need to add a domain parameter.

Best practices for roles and profiles

Adhere to guidelines when creating and managing roles and profiles. Puppet’s Service organization uses the following best practice guidelines.

Role guidelines

A role can be a classification group in a classification tool or the PE console, or it can be written as code.

A role:

• Includes only profile classes.
• Contains only includes and any ordering required by profiles.
• Assigns only one role to a host (also called an agent or node). If more than one role is required to build a host, create a new role with everything required for that host.
• Is named based on the product name or type of services that the host(s) provide for the organization.

Profile guidelines

The profile layer is made up of site wrapper modules. Create one base profile supporting all of your organization’s supported operating systems containing the base configuration of allowable security and hardening configurations for your organization.

A profile

• Includes component classes.
• Can include other profiles.
• Has no (or very few) resource definitions.
• Can be parameterized.
• Gets data from Hiera or through a classification tool.
• Is named after the technology it enforces.

Example roles and profiles code

This role is for a support server that monitors an organization’s services.

# This is a monitoring server for several products and services
class example_role::sup_svc::monitor::server {
  include profile::os::baseline
  include profile::app::icinga::server
}

This profile installs Icinga using a component module class available on the Forge. You can use the $manage_repo parameter to let you use Hiera data (profile::app::icinga::server::manage_repo: true) to change whether the Icinga component module manages its own package repositories.

# @summary
#   This profile uses the icinga-icinga2 module to configure and install
#   Icinga monitoring service
#
# @param manage_repo
#   This identifies if icinga module should manage the package repository of icinga packages.
#
# @example Basic usage
#   include profile::app::icinga::server
class profile::app::icinga::server (
  Boolean $manage_repo = false,
) {
  class { '::icinga2':
    manage_repo => $manage_repo,
  }
}

Learn more about roles and profiles

• The roles and profiles pattern: Start with a baseline profile📍
• The roles and profiles pattern: After you have a baseline profile, work on a role📍
• Old documentation, but still helpful: Roles and profiles: Introduction
• Old documentation, but still helpful: Roles and profiles: A complete example
• Working examples of roles and profiles in a control repo