Using Puppet Roles & Profiles pattern with Foreman Hostgroups?

Support
1

We are trying to figure out how to integrate Puppet’s Roles and Profiles pattern with Foreman, and are trying to understand how to use Host Groups or Config Groups with this pattern, and also how to override parameters for a group of hosts.

My question is based on these Puppet Enterprise documents:

For background, here’s how that example works:

  • A profile uses multiple component modules to configure a layered technology stack. In this case, it sets a default parameter for the Docker version.

    # /etc/puppetlabs/code/environments/production/site/profile/manifests/kubernetes/worker.pp
class profile::docker (
  $docker_version = "present",
) {

  package { 'docker':
    ensure => present,
    version => $docker_version,
  }

}

  • A role use multiple profiles to build a complete system configuration.

    • Here’s a development role, which includes a set of tools for development:

      # /etc/puppetlabs/code/environments/production/site/role/manifests/kubecluster/dev
class role::kubecluster::dev {
  include profile::base
  include profile::docker
  include profile::developer_tools
}

    • And here’s a production role, which does not include development tools:

      # /etc/puppetlabs/code/environments/production/site/role/manifests/kubecluster/prod
class role::kubecluster::prod {
  include profile::base
  include profile::docker
}

  • Component modules are normal modules (from Puppet Forge, Github, etc) that manage one particular technology, for example, puppetlabs/docker

  • In Puppet’s examples, they store configuration parameters such as an IP address or a special Docker package version in Hiera or the Puppet Enterprise ‘console’ (I don’t know what the Console is).

Our strategy is to populate /etc/puppetlabs/code/environments/production/site/ with roles and profiles as described. We do not plan to use Hiera, and instead, want to store configuration parameters as data in Foreman.

In Foreman, we will create Host Groups for groups of similar hosts. In each host group, we assign a single role.

  • The Kubecluster::production host group includes the role::kubecluster::prod class
  • The Kubecluster::development hostgroup includes the role::kubecluster::dev class
  • The webserver::customer_a hostgroup includes the role::webserver class, etc.

Our questions:

How do we accomplish the data lookups without Hiera?

  • Should we be able to override the default Docker version by setting a parameter in the host group,
    such as simply setting docker_version = 19.09? I tried this, and it didn’t work and I’m sure if I am understanding the purpose of host groups.
  • In rare cases, we might want to temporarily override the parameter from the host group. In that case, would we set a temporary parameter in the Host configuration?

Are Hostgroups intended to manage a set of servers that all have the same application? Or are they intended to be used to manage similar sets of hosts (Hostgroup A are VMs, Hostgroup B is Bare Metal in Datacenter A, Hostgroup C are nodes in AWS)?

Do people use Config Groups for this instead of Host Groups to apply application configuration to a group of hosts?

2

Host groups are roughly analogous to roles and config groups are roughly analogous to profiles. There are some major differences though and they do not expect you to use actual roles and profiles classes. i.e. they are supposed to completely replace those conceptually.
A few of the major differences are

  • Host groups inherit classes AND data from their parents where as you could include a role class in another role in puppet but the profiles wouldn’t necessarily get the same data passed to them
  • Config groups do not have data associated with them, they are just a collection of module classes. Defaults are applied at the module level or the hostgroup level via smart class parameters instead. This differs conceptually from the puppet definition of profiles.
  • You must include the classes that have parameters you want to override in the foreman host group either via a config group or directly otherwise you are not given the option to override them.

That last point pretty much precludes using roles classes in the way puppet documents them with foreman smart class parameters, as there is no way for you to pass the required data to the profiles. You could however do a hybrid where you have profiles classes with parameters as described in the puppet docs and then include them in hosts groups thus making host groups your roles.

Out of interest does foreman see your profiles classes in the site directory when you import from your environments? We keep ours in the modules directory.

1 Like
3

Yes, because it’s part of the modulepath. Pretty sure this is what the default Foreman install directions do:

root@puppet:~# puppet config print modulepath`
/etc/puppetlabs/code/environments/production/modules:/etc/puppetlabs/code/environments/common:/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules:/usr/share/puppet/modules:/etc/puppetlabs/code/environments/production/site
root@puppet:~#
1 Like
4

Thanks I’m not sure how we missed that but it makes a lot of sense. Should be a simple refactor.

Let me know if you have any questions about my answer above. We use roles and profiles extensively, however we do keep our data in hiera.

1 Like