Puppet – external data – Hiera

Hiera is nothing, but a key value look up tool, which can be ordered and organized nicely without meddling with the actual code. Just give hiera the data that your modules need, and you are ready to go.

“Hiera makes your data separate from the module’s, so that the module code remains untouched. This helps your module’s to be reusable and clean, and save you from repetition”.

The configuration data inside hiera can be in two formats(mentioned below.)

YAML
JSON

—————

Using Hiera with Puppet 3

If you are using hiera with puppet 3, then you do not need to install anything to get hiera working. But still keep the below points about its configuration in mind.

Puppet will look for hiera configuration file in /etc/puppet directory. Hence the config file path becomes /etc/puppet/hiera.yaml.
Also you can easily change this path, if you want to keep the hiera configuration file separate by adding hiera_config parameter inside puppet.conf file.

Now let’s get inside the configuration part of hiera with puppet.

Puppet will ask hiera, for a configuration data value. And its hiera’s job to return the correct value depending upon the environment and hierarchy.

Step 1: Create a configuration file called hiera.yaml inside /etc/puppet/ directory. Please note the fact that this is the default location where puppet will look for hiera config file. You can change this with hiera_config setting inside puppet.conf.

All configuration settings that you see inside hiera.yaml file is considered and looked up in the order you define. That is, if your :backends: settings has got two values (- yaml, and – json), then hiera will first search all yaml files first, and then search all .json files. Hierarchy is core concept behind hiera in puppet.

:hierarchy setting in hiera can contain a string or an array of strings as values. And all these strings you provide will be considered as a data source for hiera to lookup. Strings can be static or dynamic.

A dynamic data source in hiera is the one that contains %{your data source variable}. An example of a dynamic data source is the one that we gave in our hiera.yaml file for osfamily ie: %{::osfamily}. A normal string like common in our example is static data source.

:datadir setting in hiera can contain a string value, which defines the location of the data source files. These files will contain user defines values(the files inside this directory will be searched, when puppet asks for a configuration data in a module).

Only keep two things in mind as of now. That is, :hierarchy setting is used to define your own hierarchy of data source(which files to look first and which to look last). And :datadir setting is used to specify the location of these data source files(basically you will be creating files inside that location with the name/variable you provided in :hierarchy setting, with .yaml extension if you are using backends as :yaml).

hiera.yaml

puppet@<server>:/opt/puppetserver/conf> ll hiera.yaml
lrwxrwxrwx 1 root root 15 May 29 13:19 hiera.yaml -> /etc/hiera.yaml

cat hiera.yaml
—
:backends:
– yaml
:yaml:
:datadir: /opt/puppetserver/conf/environments/%{::environment}/hieradata
:hierarchy:
– “node/%{::fqdn}”
– “%{::osfamily}”
– common

As the first backend is YAML, it will first look for all .yaml files in the data source folder(provided by the :datadir settings).

puppet@<server>:/opt/puppetserver/conf> find . -name “*.yaml”
./environments/test/hieradata/RedHat.yaml
./environments/test/hieradata/node/server1.example.com.yaml
./environments/test/hieradata/node/server2.example.com.yaml
./environments/test/hieradata/Suse.yaml
./environments/test/hieradata/common.yaml
./environments/quality/hieradata/RedHat.yaml
./environments/quality/hieradata/node/server1.example.com.yaml
./environments/quality/hieradata/node/server2.example.com.yaml
./environments/quality/hieradata/Suse.yaml
./environments/quality/hieradata/common.yaml
./hiera.yaml

hiera lookup

Puppet can read info from the hiera yaml files , example

./environments/test/hieradata/RedHat.yaml

—
sshservicename: ssh
packagemanagername: rpm

./environments/test/hieradata/Suse.yaml

—
sshservicename: sshd
packagemanagername: zypper

In a manifest:

modules/helloworld/manifests/init.pp: $sshservicename_test = hiera(“sshservicename”)
modules/helloworld/manifests/init.pp:  notify { “AAA hiera variable sshservicename : $sshservicename_test”: }
modules/helloworld/manifests/init.pp: $packagemanager = hiera(“packagemanagername”)
modules/helloworld/manifests/init.pp: notify { “retrieving hiera variable packagemanagername : $packagemanager”: }