Now that we have a complete overview on the Puppet DSL and its concepts, it is time to look at the newest Puppet features that 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 does not only offer new functionality, but breaks with old practices and removes some functionality that is not considered a best practice anymore. This necessitates that any existing manifest code needs proper testing and potentially 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 engine
- Handling multiline with HEREDOC
- Breaking old practices
Let's first look at how users of the older Puppet 3 series can approach the update.
The new Puppet 4 version 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 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 2.1 installation, which is not available on most modern Linux distributions.
- Update to Puppet 3.8, enable and migrate to the environment path settings, and enable the future parser only on a special testing environment:
The latter solution is the smartest and most backward compatible one.
Note
With Puppet 4 and the All-in-One (AIO) packaging from Puppet Labs, paths to Puppet configuration, modules, environments, and SSL certificates will change.
- Puppet 4 stores its configuration (
puppet.conf) in/etc/puppetlabs/puppet. - Hiera config will be located in
/etc/puppetlabs/hiera/hiera.yaml. - Puppet 4 CA and certificates can be found at
/etc/puppetlabs/puppet/ssl. - Puppet Code (environments and modules) are looked up in
/etc/puppetlabs/code.
The new parser was introduced in Puppet 3.5 alongside the old parser. To make use of the new language features, a special configuration item needed to be set explicitly. This allowed early adopters and people interested in the new technology to test the parser and check for code incompatibilities in an early stage.
On Puppet 3.x, the new parser was subject to change without further notice. Therefore it is recommended to upgrade to the latest 3.x release.
With directory environments, it is possible to specify environment specific settings within an environment.conf configuration file:
# /etc/puppet/environments/puppet_update/environment.conf # environment config file for special puppet_update environment parser = future
Next, all your puppet code needs to be put into the newly created environment path, including node classification.
On each of the different node types, it is now possible to manually run:
puppet agent --test --environment=puppet_update --noop
Check both Master and Agent output and logfiles for any errors or unwanted changes and adapt your Puppet code if necessary.
Spinning up a new Puppet Master is another approach. The following process assumes that the Puppet CA has been created using the DNS alt names setting in the puppet.conf file. In case no DNS alt names have been configured, it is required to completely recreate the Puppet CA.
Puppet CA needs to know about the CN (common name) of the Puppet Master fqdn. It is possible to provide DNS alternative names, for which the CA will also be valid.
Normally, Puppet uses the Master fqdn for the common name. But if you provide the configuration attribute dns_alt_names prior to generating the CA, this configuration option will be added to the CA.
It is highly recommended to configure dns_alt_names. Having this enabled allows you to scale up to multiple compile masters and add an additional Puppet Master for the migration process.
To find out whether DNS alt names have been added, you can use the puppet cert command:
puppet cert list –all
This command will print all certificates. Check for the certificate of your Puppet Master.
For example, consider the following:
puppet cert list --all + "puppetmaster.example.net" (SHA256) 7D:11:33:00:94:B3:C4:48:D2:10:B3:C7:B0:38:71:28:C5:75:2C:61:3B:3E:63:C6:95:7C:C9:DF:59:F7:C5:BE (alt names: "DNS:puppet", "DNS:puppet.example.net", "DNS:puppetmaster.example.net")
The following steps will guide you through the Puppet 4 setup. On a Debian 7 based system add the PC1 Puppet Labs repository:
curl -O http://apt.puppetlabs.com/puppetlabs-release-pc1-wheezy.deb dpkg -i puppetlabs-release-pc1-wheezy.deb apt-get update apt-get install puppetserver puppet-agent
Do not start the Puppet server process yet! It is required to run the new Puppet 4 Master as CA Master, which needs the CA and certificates from the Puppet 3 Master copied over to the new Puppet 4 Master.
Within the next step, all Puppet agents need a change on the puppet.conf file. You will need to provide different settings for ca_server and server:
ini_setting { 'puppet_ca_server':
path => '/etc/puppet/puppet.conf',
section => 'agent',
setting => 'ca_server',
value => 'puppet4.example.net'
}Now place all your Puppet code onto the new Puppet 4 Master into an environment (/etc/puppetlabs/code/environments/development/{manifests,modules}).
Test your code for Puppet 4 errors by running the following command on each of your nodes:
puppet agent --test --noop --server puppet4.example.net --environment development
Change your Puppet code to fix potential errors. Once no errors and no unwanted configuration changes occur on the Puppet 4 Master and agents, your code is Puppet 4 compatible.
It is important to make sure that your existing agents are prepared to operate with a master that is already at version 4. Check the following aspects:
- All agents should use the latest version of Puppet 3
- The agent configuration should specify
stringify_facts = false
The latter step prepares you for the agent update, because Puppet 4 will always behave like that and refrain from converting all fact values to the string type.
Do make sure that you update to Puppet Server 2.1 or later. Passenger-based masters and Puppet Server 2.0 are not compatible with Puppet 3 agents.
Tip
The Puppet online documentation contains many helpful details about this update path: http://docs.puppetlabs.com/puppetserver/latest/compatibility_with_puppet_agent.html.
Another approach for verifying whether the existing Puppet code will work on Puppet 4 is unit and integration testing using rspec-puppet and beaker. This procedure is not within the scope of this book.
Whether you started fresh with Puppet 4, or used one of the preceding procedures to migrate your Puppet 3 infrastructure, it is now time to discover the benefits of the new version.