New Features from Puppet 4 and 5

Now that we have a complete overview of the Puppet DSL and its concepts, it is time to look at the newest Puppet features, which were introduced with Puppet version 4. The parser, which compiles the catalog, was basically rewritten from scratch for better performance. The milestone release also added some missing functionality and coding principles.

Puppet 4 and newer versions do not only offer new functionality, but break with old practices and remove some functionality that is not considered best practice anymore. This necessitates that any existing manifest code needs proper testing, and potentially needs lots of changes to be compatible with Puppet 4.

Within this chapter, the following topics will be covered:

• Upgrading to Puppet 4
• Using the Puppet type system
• Learning lambdas and functions
• Creating Puppet 4 functions
• Leveraging the new template...

Upgrading to Puppet 4

Let's first look at how users of the older Puppet 3 series can approach the update.

Instead of upgrading your Puppet master machine, consider setting up a new server in parallel and migrating the service carefully. This has some advantages. For example, rolling back in case of problems is quite easy.

The new Puppet 4 and later versions can be installed in several ways:

• Using the Puppet Labs repositories, which will remove older Puppet packages
• This method means a hard cut without testing in advance, which is not recommended. The update to Puppet 4 and later versions should only take place after in-depth testing of your Puppet manifest code
• Installing as the Ruby gem extension or from tarball
• This approach requires a separate Ruby installation, which is not available on most modern Linux distributions. For Puppet 4, Ruby 2.1 is required. For Puppet 5...

Learning lambdas and functions

Functions have long been an essential part of Puppet. Due to the new type system, a complete new set of functions have become possible functions with different behavior based on parameter data types.

To understand functions, we first have to take a look at lambdas, which are introduced in Puppet 4. Lambdas represent a snippet of Puppet code, which can be used in functions. Syntactically, lambdas consist of an optional type and at least one variable with optional defaults set, enclosed in pipe signs (|), followed by Puppet code inside a block of curly braces:

$packages = ['htop', 'less', 'vim']
each($packages) |String $package| 
{
      package { $package:
        ensure => latest,
  }
}

Lambdas are typically used on functions. The preceding example uses the each function on the $packages variable, iterating over its contents...

Creating Puppet 4 functions

The Puppet 3 functions API has some limitations and is missing features. The new function API in Puppet 4 improves upon that substantially.

Some of the limitations of the old functions are as follows:

• The functions had no automatic type checking
• These functions had to have a unique name due to a flat namespace
• These functions were not private and, hence, could be used anywhere
• The documentation could not be retrieved without running the Ruby code

Running on Puppet 3 requires functions to be in a module in the lib/puppet/parser/functions directory. Therefore, people referred to these functions as parser functions, but this name is misleading. Functions are unrelated to the Puppet parser.

In Puppet 4, functions have to be put into a module in path lib/puppet/functions.

This is how you create a function that will return the hostname of the Puppet master...

Leveraging the new template engine

In Chapter 6, The Puppet Beginners Advanced Parts, we introduced templates and the ERB template engine. In Puppet 4, an alternative was added: the EPP template engine. The major differences between the template engines are as follows:

• In ERB templates, you cannot specify a variable in Puppet syntax ($variable_name)
• ERB templates will not accept parameters
• In EPP templates, you will use the Puppet DSL syntax instead of Ruby syntax

The EPP template engine requires scoped variables from modules:

# motd file - managed by Puppet 
This system is running on <%= $::operatingsystem %> 

The manifest defines the following local variable: <%= $motd::local_variable %>. The EPP templates also have a unique extension: they can take typed parameters.
To make use of this, a template has to start with a parameter declaration block:

<%- | String...

Handling multiline with HEREDOC

Writing multiline file fragments in Puppet mostly resulted in code that was hard to read, mostly due to indentation. With Puppet 4, the heredoc style was added. It is now possible to specify a heredoc tag and marker:

$motd_content = @(EOF) 
  This system is managed by Puppet 
  local changes will be overwritten by next Puppet run. 
EOF 

The heredoc tag starts with an @ sign followed by arbitrary string enclosed in parenthesis. The heredoc marker is the string given in the tag.

If variables are required inside the heredoc document, the variable interpolation can be enabled by putting the tag string in double quotes. Variables inside the heredoc are written the same as Puppet DSL variables: a dollar sign followed by the scope and the variable name:

$motd_content = @("EOF") 
  Welcome to ${::fqdn}. 
  This system is managed by Puppet version...

Using Puppet 5 server metrics

With Puppetserver Version 5 the former Puppet Enterprise only metrics system has been ported to Puppet Open Source.

The metrics system allows you to read internal information like compile times, status of file serving and function runtimes from a JMX console or to push the data to a graphite system.

Enabling the metrics system is straightforward by editing the puppet server metrics.conf file located at /etc/puppetlabs/puppetserver/conf.d/metrics.conf.

There are three important settings. At the metrics.server-id one can specify an ID which is later used in the Grafana dashboard. The metrics.registry.puppetserver.reporters.graphite.enabled value must be set to true and the metrics.reporters.graphite hash must mention the graphite hostname and port and the update interval setting:

# settings related to metrics
metrics: {
  # a server id that will be used...

Breaking old practices

When Puppet Labs decided to work on the parser and on the new features, they also decided to remove some features that had already been deprecated for a couple of releases.

Converting node inheritance

Node inheritance has been considered good practice during older Puppet releases. To avoid too much code on the node level, a generic, nonexistent host was created (basenode) and the real nodes inherited from basenode:

node basenode {
  include security
  include ldap
  include base
}
node 'www01.example.net' inherits 'basenode' {
  class { 'apache': }
  include apache::mod::php
  include webapplication
}

This node classification is no longer supported by Puppet 4.

As of 2012, the roles...

Summary

Upgrading to Puppet 3 should be done in a step-by-step procedure where your existing code will be evaluated using Puppet 3.8 and the new parser.

Thanks to the type system, it is now possible to deal with data in a far more elegant way directly in your Puppet DSL code. The new functions API allows you to immediately recognize to which module a function belongs by using namespaces. Similar functions can now be combined within a single file by making use of the dispatch method and data types, allowing a form of function overloading.

The new EPP templates offer better understanding of variable sources by using the Puppet syntax for variable references. Passing parameters to templates will allow you to make use of modules in a more flexible way.

Combining EPP templates and the HEREDOC syntax will allow you to keep template code and data directly visible inside your classes...