Puppet Roles and Profiles

Now that we have a complete overview of the Puppet DSL and its concepts, it is time to look at how to build implementations based on Puppet that reflect your infrastructure settings and requirements.

In the early days of Puppet, it was common practice to add resources and variables to a node classification. This mostly led to duplicate code and made refactoring almost impossible. This pattern mostly reflected the usual admin work, which was done by configuring individual systems.

To avoid difficult to manage and hard to maintain code, a community around Puppet modules emerged. This community took care to implement technical parts of a system into Puppet modules. Modules have the benefit of being reusable by parameters and get bug-fixes and new implementations faster due to shared efforts.

As we now have a large set of modules available, we must rethink...

Technical component modules

Until now, we have referred to modules as a strict directory structure containing classes, static files, templates, and extensions. We now must differentiate between upstream or generic modules and our platform implementation modules.

Modules that take care of a specific technical component are now referred to as technical component modules. Technical components themselves are a set of configurations for a certain software running on a system, such as Nginx, Postgres, or LDAP.

There has always been the problem of whether a module is a technical component module or not. There are some patterns that allow you to identify technical component modules:

• Developed upstream with active community
• Open source with README and LICENSE files
• Only manages what is required
• Clearly described entry class with parameters for adoption and reusability
• Allows stacking...

Implementing components in profiles

Puppet code that is not taken from upstream, but developed in-house describing your infrastructure, usually is an implementation of resources and upstream classes. This implementation is called a profile class.

Technically, a profile is a module containing classes, and optionally has parameters, defines, files, and templates. On very rare occasions, it might be valuable to also have custom facts or custom functions within profiles.

Inside a profile, one specifies data and resources. Data can either be static data, which is valid for the whole platform, or placed into Hiera. Resources can be anything such as class, file, package, and service.

Combining these into a profile builds another layer of abstraction:

• Data is abstracted by Hiera
• CLI commands are abstracted by resource types
• Resource types are abstracted by technical component modules...

The business use case and node classification

With all implementations now being in place, we look forward to how to do node classification.

There are several options available and which one is the best solution mostly depends on your platform.

When you have a very diverse platform, the concept of roles as another abstraction layer is not very useful, as it mostly leads to duplicate code. In this case, most people decided to use profiles for node classification.

When you have large sets of identically configured systems, one wants to go ahead with the role pattern and classify systems by their business use case.

The business use case allows you to describe systems not by what they do, but by what they are used for.

Think about the phpmyadmin installation. Depending on use case and business owner, one might have different classification names:

A technician will use the term database...

Building roles from profiles

Let's continue with the phpmyadmin example, which has been built for the sales department so that they can manage their CRM database.

In this case, we build a role for that system based on implementation profiles. The name of the role reflects the business use case:

class role::crm_db_control_panel {
  contain profile::login::secure
  contain profile::database::mysql
  contain profile::scripting::php
  contain profile::apps::phpmyadmin::db
  contain profile::apps::phpmyadmin
}

Within a role, one only declares profiles. No code logic, no resources, no data lookups. This allows flexible use of roles. Don't try to build almost identical roles, as this will lead to duplicate code. Instead, it would be better to create profiles with data lookups to reflect individual usage.

The previously mentioned role can then be used for a node classification:

node...

Placing code on the Puppet server

From a technical perspective, roles and profiles are classes inside modules. Usually, modules are put into the modules directory of an environment. But roles and profiles are different to modules, as they are implementations of modules and collections of implementations.

To reflect this different behavior, it is common practice to add another module directory to an environment. This configuration can be done in the environment.conf file inside an environment:

#/etc/puppetlabs/code/environments/production/environment.conf
modulepath = site:modules:$basemodulepath

Within our example, we have added a new path to the module path setting: site. This directory resides inside our environment (/etc/puppetlabs/code/environments/production/site). This directory will have all of our roles and profiles:

/etc/puppetlabs/code/environment/production/site/
  |...

Summary

When building and maintaining Puppet code bases, it is a good idea to implement the roles and profiles pattern. It makes you define roles to cover all of your machine use cases. The roles mix and match profile classes, which are basically collectors of classes from custom and open source modules that manage actual resources.

When setting up your first large Puppet installation, it is a good idea to adhere to the pattern from day one, because it will allow you to scale your manifests without getting tangled up in complicated structures.

Deployment of Puppet code is managed via r10k, where Git branch names reflect your Puppet code quality. Using Puppetfile allows you to separate your own Puppet code development from upstream module development.

This concludes our tour of Puppet Essentials. We have covered quite some ground, but as you can imagine, we barely scratched the...