How does Foreman determine node definitions?
Foreman acts as an External Node Classifier (ENC). Remember, node is just a fancy word for host and is used interchangeably here.
An ENC acts like the traditional
site.pp: Add classes and variables to a host object and create a catalog for a specific node only. Foreman will resolve classes and parameters usually from the hostgroups (see bellow). To see it in action, go to a specific host and the press YAML button. Basically, this YAML is fed to the puppet master.
While it is possible to keep node definitions, your
site.pp, on the puppet master, it is not considered a good practice: These definitions are merged with ENC values and can lead to unexpected behaviour - so remove any node definitions in
manifestes and instead use only Foreman to assign classes and parameters.
You do not need to use the ENC feature and can instead rely completely on Hiera. However, to get started easy, you should try ENC first.
Notes on Hiera
- One of the biggest challenges using the ENC model is class dependency. You can never be sure if a class you need was actually declared when your class is calling it, let alone with the parameters it needs. To be fair, this is a more a puppet issue then Foreman’s. However, if you rely on this a lot, you should consider the hiera route.
- Later on, a combination of ENC and Hiera is often a good practice: Store default values for your parameters in your modules directly. It can save you from writing a lot of conditionals in your manifests.
What are Classes, Hostgroups and Config Groups?
Classes are a Puppet feature witch Foreman reflects by making them importable and assignable to hosts. Classes are usually grouped in modules are installed on your puppet master using
puppet module command.
To make parameter values accessible to change in Foreman, you need to ‘override’ the parameter default in the Smart Class Parameter tab.
This is a puppet concept witch Foreman reflects. It basically allows you to have the same classes but different versions. Imagine you are working on your own Puppet classes: Maybe you want to test things on a small number of development hosts in an environment called development while most hosts in the production environment are unaffected (using the old code). A host can only be assigned to one environment.
Is a concept in Foreman to hierarchically organise hosts. On hostgroup level you assign classes and setup parameters of these classes. While you may assign the same class to different hostgroups, any given host can only be part of one host group.
Example: You have a bunch of web servers wich are load balanced. You need serve two websites, foo.com and bar.com . Create hostgoups foo.com and bar.com ; then add hosts to the group. Change the vhost parameter on host group level
You can use hostgroups to model the structure of our company; maybe mirror Organisational Units in Active Directory. They work in a hierarchical way: Lower level hostgroups inherit values and parameters from upper levels. Hierarchies are organised from mot general on the top to the most specific on the bottom.
Apart from puppet, hostgoups also play a major part in deploying hosts. This is not the scope of this document.
Config groups hold a bunch of classes grouped together. A class can be part of any number of config groups. You cannot assign actual values to parameters there.
Example: The file server config group has nfs, samba and sssd classes. This is pretty useful, and you should make a lot of use of them early on. It is best practice to only assign config groups to hosts and hostgroups. This makes it easy to propagate changes later on when you really have a lot of classes.
Note : You can also assign classes directly to hosts. However, this is only useful in a few edge cases. You should avoid doing this when possible.