puppet apply #5 – roles and profiles

what are roles and profiles?

Roles and profiles are the recommended way from Puppet to organise code.

Documentation elsewhere on this includes: https://puppet.com/docs/pe/2017.2/r_n_p_full_example.html

Summary:

  • Each node / server / puppet agent has a single role. Webserver, database server, jenkins server, blog-webserver, customer-databaseserver, and so on.  Whatever makes sense in your environment.
  • Profiles provide useful functionality that is included in one or more roles.

Puppet states, in the above page, that:

  • The only thing roles should do is declare profile classes with include. Don’t declare any component classes or normal resources in a role.Optionally, roles can use conditional logic to decide which profiles to use.

I’ll come back to this.

roles and profiles in control repo

They live in site/role/manifests and site/profile/manifests

In the previous post, I introduced a profile which dumps all of puppet’s facts to a file.

The next step adds a role, and a second profile.

git checkout puppetapply03
  • site/role/manifests/test1.pp defines a role called role::test1
  • It adds (to the existing profile) one which maintains /etc/motd, defined in site/profile/manifests/motd.pp
  • manifests/site.pp is now coded to deploy this role.
  • There’s also now a commit in the git history which removes Puppet’s example roles and profiles, to make the directories a little tidier, and another one which adds a script for the next post.

Try it out;  note: it will create or replace /etc/motd.

sudo scripts/puppetapply.sh #--noop

classification

It’s not very useful to classify all our servers with the same role.

There needs to be some code in there that determines what role a machine is supposed to have.  You could do it by looking at the hostname (web*, db*, files* etc), extensions to the puppet certificate, an external classifier, or some other mechanism.

For the moment I will set aside classification. Puppet apply is most broadly useful for doing development work, so control repo needs some sort of mechanism to load profiles. However, ultimately, support for both is needed – classification when control repo is being served by a puppet master, and the ability to select specific profiles for puppet apply. This is covered in the last post.

directory structure and class names

Puppet class names relate directly to the directory structure in which the manifests are stored.

For example: to get a role class called role::test1, we have a file called test1.pp. It’s in a directory structure of role/manifests.

A profile called profile::puppet::configuration is provided by profile/manifests/puppet/configuration.pp

If the class definition and the location of the manifest do not match, puppet will complain, for example:

Warning: Unacceptable location. The name 'roles::test1' is unacceptable in 
file '/etc/puppetlabs/code/environments/local/site/role/manifests/test1.pp'

Out of the box, control repo provides for two places to store classes: the site directory and the modules directory. Within each of those directory, any subdirectories form the first part of the class name (a::) and then puppet expects subdirectories (manifests, templates, files, lib etc.,)

environment.conf in control repo is where these two places are defined.

modulepath = site:modules:$basemodulepath

The final entry is shared modules (more detail here).  This includes /opt/puppetlabs/puppet/modules on the puppet server – puppet enterprise ships with a load in there.

next

puppet apply #6 – installing modules

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s