Introduction and How to Configure Hiera | DevOps | VisualPath

Introducing Hiera

In Puppet, Hiera is a key-value lookup tool for configuration data. Hiera is integrated into Puppet to provide dynamic lookup of configuration data for the manifest files.
With Hiera, we can provide node-specific information to a Puppet module. Hiera uses a customizable hierarchy to lookup the data.
For example, We can organize our data in this way:
1. Company-wide defaults
2. Operating system specific changes
3. Site-specific information
Creating Hiera Backends
Hiera has two built-in data file backends, YAML and JSON, and then the Puppet data provider. Each backend supports four data types:
1. Arrays
2. Strings
3. true/false (Boolean)
4. Hashes
Let’s go through how to utilize these data types in each backend.
Hiera Data in YAML
The most common way to provide data to Hiera is using the YAML file format. The file has a .yaml file extension. Files in YAML format always start with three dashes on the first line. The YAML format utilizes white spaces indentation to indicate the relationships between data. YAML should always be written using spaces, never tabs, for indentation. Here are some examples of strings, Boolean, arrays, and hashes in YAML

# strings
agent_running: 'running'
# boolean expression
agent_atboot: true
# arrays
puppet_components:
- facter
- puppet
# hash of values
puppet:
ensure: 'present'
version: '4.0.4'
# variable loopup
hostname: %{facts::hostname}

We can organize all the data within a single hash That could look as simple as this:
puppet:
agent_running: 'running'
agent_atboot: true
components:
- 'facter'
- 'puppet'
We can see, YAML provides a clean, easy to read way to provide data without too much-complicated syntax.
Configuring Hiera
Puppet looks for a Hiera configuration file at the location specified by the hiera_config configuration variable. By default this is $codedir/hiera.yaml, or /etc/puppet/code/hiera.yaml in Puppet.
Backends
The configuration key : backends should provide an array which lists the backend data providers that Hiera should use. There are three built-in backends, the two data types we discussed previously, YAML and JSON, plus Hiera can utilize data from Puppet.
If you wish to utilize both built-in file types, you could configure it as follows.

:backends:
- yaml
- json

We will only be utilizing YAML within this book.
Backend Configuration
For each backend data provider, you name in the backends array, you should create an atop-level entry with the name of the provider. For each backend provide a hash of configuration data.
For the two built-in file-based backends the only configuration key necessary is:datadir, which identifies the directory in which the data files reside.
:yaml:
:datadir: /etc/puppetlabs/code/environments/%{::environment}/hieradata
:json:
:datadir: /etc/puppetlabs/code/environments/%{::environment}/hieradata
As the files read by each backend must be named differently, you can use the same data directory for both data sources as shown above.
You’ll note that we’re using the top-level environment variable (defined by puppet master or client) to allow different environment data in each environment. Let’s go ahead and create the hieradata directory now in the environment directories we created in the last chapter.
mkdir /etc/puppetlabs/code/environments/test/hieradata
mkdir /etc/puppetlabs/code/environments/production/hieradata
For the Puppet backend place the name of a Puppet module which contains the data in a:datasource configuration key.
:puppet:
:datasource: hieradata

With this configuration variables from a module named heiradata would be accessed for Hiera lookups. As mentioned previously this is only useful when the module provides dynamic lookup of data.

Hierarchy

The final mandatory parameter is :hierarchy. The hierarchy defines the priority order for lookup of configuration data. For single values Hiera will proceed through the hierarchy until it finds a value and then stop. For arrays and hashes Hiera will merge data from each level of the hierarchy, selecting the winner of conflicts based on the :merge_behavior configuration setting.
There are two types of data sources: static and dynamic. Static data sources are files explicitly named in the hierarchy which contain data. Dynamic data sources are files which are named using interpolation of local configuration data, such as the host‐name or operating system of the node.
In a larger enterprise, the data lookup hierarchy could be quite complex, however I recommend the following for a good starting point.
1. Put default values in a file named global.yaml.
2. Put all operating system specific information in a file named for the OS family as returned by Factor, e.g. RedHat.yaml, Debian.yaml, FreeBSD.yaml, etc.
3. Put information specific to a single node within a file named the full hostname of the node with a .yaml extension.
You would implement this hierarchy using the following configuration syntax. As you can see, we are interpolating data provided by Factor to choose which files will be read.
:hierarchy:
- defaults
- "%{::hostname}"
- "%{::osfamily}"
- global

Naturally, you can extend this hierarchy to use information like the domain name of the node or any other factor-provided node value.
If you have multiple backends configured, then Hiera will evaluate the entire hierarchy for the first configured backend, then evaluate the entire hierarchy in order forthe 2nd configured backend, etc.
Complete Example
Following is a complete example of a Hiera configuration file. This example is what we will use for the remainder of this book.
It enables YAML data input from etc/puppetlabs/code/hieradata, with a hierarchy that uses host-specific information in preference to operating system family information, finally defaulting to values global to every host.

---
:backends:
- yaml
:yaml:
:datadir: /etc/puppetlabs/code/hieradata
:hierarchy:
- defaults
- "%{facts::clientcert}"
- "%{facts::osfamily}"
- global

For more information about Visualpath, visit www.visualpath.in and follow the company on Facebook and Twitter.

For DevOps training contact us at +91 9704455959 / info@visualpath.in