Puppet modules are designed to be generic and not contain data specific to your environment. This data does have to come from somewhere and typically that is Hiera. It is worthwhile to spend some up front time on developing your Hiera data structure. This can help you determine what custom facts are needed, as well as classification and parameterization needs, as you continue to develop your Puppet implementation.
Version and installation information
Puppet version: 5.0, 6.0
Installation type: All
Hiera is a hierarchical data structure for automatic data lookups in your Puppet code. This Hiera hierarchy allows Puppet to leverage facts available during catalog compilation to retrieve the proper data for the node requesting the catalog. With this dynamic data, your Puppet code can be clean and trim leaving out complex logic to make those determinations.
Think of a hiera hierarchy like a pyramid. The hiera data lookups would start at the top hiera hierarchy layer in
hiera.yaml and proceed downward to the bottom layer in the
The base of the pyramid is going to be where the majority of your data lives, it is basically all the settings, defaults, and base data for your organization. This hiera hierarchy layer is called global or common. The top of the pyramid is usually going to be the more specific data, or more precisely the node specific data. We often call this layer node/%
trusted.certname or node layer for short. Each node would have a yaml file in the node directory of your hiera data directory.
Then think of what decision points would make you change that base data if manually performing the actions. For example, datacenter is a common level to override base data. Only create hiera hierarchy layers where you would manually make decisions to override the base data.
You will also want to keep your hiera hierarchy levels few in number, but add what is needed for your organization. Definitely shoot for less than 12 though. Keep in mind that each layer you add in hiera will increase your catalog compilation time and slow down your Puppet agent runs. The goal of the layers is to only provide what data is different based on that decision point. Removing layers can be difficult, but adding layers in is much easier. Start few and add only when necessary.
Well we know that component modules should not have site specific data stored in them, but what about profiles? Take a look at the Data Escalation Path Best Practices. This document gives a lot of advice on when to use hard coded data or parameterization in your profiles.