Hiera: Module Data

Length: 00:13:58

Lesson Summary:

At this point, we've separated out our OS-family-specific variables, but still have bits of our manifests that we need to parameterize out. In an ideal world, every value would be able to be overridden. But since every value isn't affected by the operating system of our servers, we have another data store to work with: Hiera. Hiera lets us store key-value pairs in a hierarchy of directories.

We'll start by parameterizing our existing manifest further, storing those values in our module's data/common.yaml file. Later in the video, we'll create a vhosts class where we'll store our Hiera data in the production environment's data directory. There, we can supply Hiera data on a per-node basis, since we might not want the same website virtual hosts for every node, or if we're using nginx to support a web frontend to some other application.

common.yaml

Hiera is configured in a multitude of places: There's an architectural-wide configuration file at /etc/puppetlabs/puppt/hiera.yaml, one within the environment itself (for production: /etc/puppetlabs/code/environments/production/niera.yaml), then one for each module using Hiera (for nginx: /etc/puppetlabs/code/environments/production/modules/nginx/hiera.yaml). As with much of this course, we're going to focus on the environment and module files because the overall default configuration for Hiera doesn't need to be changed for our purposes.

Let's start small, with our module data. Open up or cat out the hiera.yaml file from the nginx module directory:

---
version: 5

defaults:  # Used for any hierarchy level that omits these keys.
  datadir: data         # This path is relative to hiera.yaml's directory.
  data_hash: yaml_data  # Use the built-in YAML backend.

hierarchy:
  - name: 'common'
    path: 'common.yaml'

Under defaults, we have the datadir setting: This just tells Hiera that for this module, the Hiera data is under data. Hiera reads this from the directory the hiera.yaml file is located in, so in this case the full path to our datadir is:

/etc/puppetlabs/code/environments/production/modules/nginx/data

From here, we can see that Hiera will specifically look for our common hierarchy, located at common.yaml in the datadir. Let's close this file and open common.yaml, which the Puppet Dev Kit generated for us.

# $EDITOR data/common.yaml

Right now, it only contains the three dashes that signify the start of a YAML file. What we want to do is add variables and values for the rest of our existing attributes, which are as follows:

install.pp:

  • package_ensure

config.pp

  • config_ensure

service.pp

  • service_ensure
  • service_enable
  • service_hasrestart

We just have to use simple key-value pairs to add these to Hiera:

---
nginx::package_ensure: 'present'
nginx::config_ensure: 'present'
nginx::service_ensure: 'running'
nginx::service_enable: true
nginx::service_hasrestart: true

Then we need to update our init.pp so that it calls these values. Now, Hiera has one benefit to params.pp in that we only have to specify our variables at the top of the class here, not in each file. We do still have to update our hardcoded attributes though!

When we define our variables in the init.pp file, we also want to supply the data type it should be expecting:

class nginx (
  $package_name  = $nginx::params::package_name,
  $config_path   = $nginx::params::config_path,
  $config_source = $nginx::params::config_source,
  $service_name  = $nginx::params::service_name,
  String $package_ensure,
  String $config_ensure,
  String $service_ensure,
  Boolean $service_enable,
  Boolean $service_hasrestart,
) inherits nginx::params {

We now want to update our other manifests to call our variables:

config.pp:

class nginx::config (
  $config_path   = $nginx::params::config_path,
  $config_source = $nginx::params::config_source,
) inherits nginx::params {
  file { 'nginx_config':
    path   => $config_path,
    source => $config_source,
    ensure => $nginx::config_ensure,
    notify => Service['nginx_service'],
  }
}

install.pp

class nginx::install(
  $package_name  = $nginx::params::package_name,
) inherits nginx::params {
  package { 'install_nginx':
    name   => $package_name,
    ensure => $nginx::package_ensure,
  }
}

service.pp:

class nginx::service (
  $service_name  = $nginx::params::service_name,
) inherits nginx::params {
  service { 'nginx_service':
    name       => $service_name,
    ensure     => $nginx::service_ensure,
    enable     => $nginx::service_enable,
    hasrestart => $nginx::service_hasrestart,
  }
}

When we're finished, let's reopen our data/common.yaml file and make one change to the package_ensure variable, to test our Hiera. Switch it from present to purged:

nginx::package_ensure: 'present'

Save and exit, then perform a Puppet run on the agent node:

# puppet agent -t

We'll definitely get some errors, but when we run which nginx, we can see that the nginx package as been removed from our server.

On the Master, switch package_ensure back to present, then rerun the puppet agent -t command on the agent:

# puppet agent -t

Everything installs, configures, and starts correctly! We can see that Hiera is up and working with our module!


This lesson is only available to Linux Academy members.

Sign Up To View This Lesson
Or Log In

Looking For Team Training?

Learn More