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.
