Puppet hiera Configuration System
Puppet is often used with hiera. hiera is essentially a configuration system that allows one to:
- Store configuration in separate YAML files;
- Define multiple hierarchies for the configuration files.
hiera configuration files
Each hierarchy allows to one choose the proper configuration file for a resource, based on certain criteria. For example criteria may include node names, node groups, operating systems, or datacenters. Hierarchies are defined in a hiera.yaml
file, which also defines a path for the files in each hierarchy.
Puppet facts are commonly used to select the proper files to use. For example, a path may be defined as "os/%{facts.os.name}.yaml"
. In this case, each resource will use a file named after the operating system it uses, in the os directory. You may need to use custom facts, for example to check which microservices will use a MariaDB server, or in which datacenter it runs.
We do not have to create a file for each possible value of a certain fact. We can define a default configuration file with settings that are reasonable for most resources. Other files, when included, will override some of the default settings.
A hiera configuration file will look like this:
version: 5 defaults: datadir: global data_hash: yaml_data hierarchy: - name: "Node data" path: "nodes/%{trusted.certname}.yaml" - name: "OS data" path: "os/%{facts.os.family}.yaml" - name: "Per-datacenter business group data" # Uses custom facts. path: "location/%{facts.whereami}/%{facts.group}.yaml"
This file would include the global files, the OS-specific files and the node-specific files. Each hierarchy will override settings from previous hierarchies.
We can actually have several hiera configuration files. hiera.yaml
is the global file. But we will typically have additional hiera configuration files for each environment. So we can include the configuration files that apply to production, staging, etc, plus global configuration files that should be included for every environment.
Importantly, we can also have hiera configuration files for each module. So, for example, a separate mariadb/hiera.yaml
file may defined the hierarchies for MariaDB servers. This allow us to define, for example, different configuration files for MariaDB and for MaxScale, as most of the needed settings are typically different.
Configuration files
You probably noticed that, in the previous example, we defined data_hash: yaml_data
, which indicates that configuration files are written in YAML. Other allowed formats are JSON and HOCON. The data_hash
setting is defined in defaults
, but it can be overridden by hierarchies.
Content initially contributed by Vettabase Ltd.