Book Image

Mastering Puppet 5

By : Ryan Russell-Yates, Jason Southgate
Book Image

Mastering Puppet 5

By: Ryan Russell-Yates, Jason Southgate

Overview of this book

Puppet is a configuration management system and a language written for and by system administrators to manage a large number of systems efficiently and prevent configuration drift. The core topics this book addresses are Puppet's latest features and mastering Puppet Enterprise. You will begin by writing a new Puppet module, gaining an understanding of the guidelines and style of the Puppet community. Following on from this, you will take advantage of the roles and profiles pattern, and you will learn how to structure your code. Next, you will learn how to extend Puppet and write custom facts, functions, types, and providers in Ruby, and also use the new features of Hiera 5. You will also learn how to configure the new Code Manager component, and how to ensure code is automatically deployed to (multiple) Puppet servers. Next, you will learn how to integrate Puppet with Jenkins and Git to build an effective workflow for multiple teams, and use the new Puppet Tasks feature and the latest Puppet Orchestrator language extensions. Finally, you will learn how to scale and troubleshoot Puppet. By the end of the book, you will be able to deal with problems of scale and exceptions in your code, automate workflows, and support multiple developers working simultaneously.
Table of Contents (19 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
Index

Using the new Hiera 5 module level data


For quite some time when module writing, we've been using the params.pp pattern. One class in the module, by convention called <MODULENAME>::params, sets the variables for any of the other classes:

class zope::params {
  $autoupdate = false,
  $default_service_name = 'ntpd',


  case $facts['os']['family'] {
    'AIX': {
      $service_name = 'xntpd'
    }
    'Debian': {
      $service_name = 'ntp'
    }
    'RedHat': {
      $service_name = $default_service_name
    }
  }
}

So, you can see here that we are using some conditional logic depending on the os::family fact, so that the service_name variable can be set appropriately. We are also exposing the autoupdate variable, and giving it a default value.

This params.pp pattern is an elegant little hack, which takes advantage of Puppet's idiosyncratic class inheritance behavior (using inheritance is generally not recommended in Puppet). Then, any of the other classes in the module inherit from the params class, to have their parameters set appropriately, as shown in the following example:

class zope (
  $autoupdate   = $zope::params::autoupdate,
  $service_name = $zope::params::service_name,
) inherits zope::params {
 ...
}

Since the release of Hiera 5, we are able to simplify our module complexity considerably. By using Hiera-based defaults, we can simplify our module's main classes, and they no longer need to inherit from params.pp. Additionally, you no longer need to explicitly set a default value with the = operator in the parameter declaration.

Let's look at the equivalent configuration to the params.pp pattern using Hiera 5.

First of all, in order to use this new functionality, the data_provider key needs to be set to the heiravalue in the module's metadata.json file:

...
"data_provider": "hiera",
...

Next, we need to add a hiera.yaml file to the root directory of the module:

---
version: 5
defaults:
  datadir: data
  data_hash: yaml_data
hierarchy:
  - name: "OS family"
    path: "os/%{facts.os.family}.yaml"


  - name: "common"
    path: "common.yaml"

We can then add three files to the /data directory (note that the datadir setting in the hiera.yaml file). The first file of these three is used to set the AIX service_name variable:

# zope/data/os/AIX.yaml
---
zope::service_name: xntpd

The second file is used to set the Debian service_name variable:

# zope/data/os/Debian.yaml
zope::service_name: ntp

 

 

And finally, there is the common file, and Hiera will fall through to this file to find its values if it doesn't find a corresponding operating system file when looking for the service_name setting, or a value for autoupdate when searching the previous two files:

# ntp/data/common.yaml
---
ntp::autoupdate: false
ntp::service_name: ntpd

We will look at Hiera 5 in much more detail in Chapter 4, Hiera 5.