Separation of concerns between code and data

Hiera separates Puppet DSL from business data, allowing us to use some of the same generic Puppet DSL repeatedly. In fact, as much as 80% of the Puppet DSL most organizations use is entirely generic; only the business data varies. Hiera allows us to make this full separation of concerns between functionality and business data, instead handily passing in the business data to our modules as parameters.

Hiera works by first setting business values at the widest catchment (that is, site-wide, or common in Puppet parlance), and then moving up the hierarchy, overriding this global value at the appropriate level.

Data specific to infrastructure lends itself incredibly well to a hierarchical model. Infrastructure always tends to consist of sets of configurable attributes: IP addresses, ports, hostnames, and API endpoints. There is a ton of settings that we configure within our infrastructures, and most of them are best represented hierarchically.

A lot of infrastructure data starts out with a default, let's say, the DNS resolver your data center uses. You first set this as a key-value pair in the common.yaml data file. After Puppet is first installed, the hierarchy hash inside hiera.conf provides initially just this common (default) level:

---
version: 5
hierarchy:
- name: Common
path: common.yaml
defaults:
data_hash: yaml_data
datadir: data
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.184.90