Upgrading to Puppet 4

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

Tip

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 version can be installed in several ways:

  1. 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.

  2. 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.

  3. 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.

Using Puppet 3.8 and environment directories

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.

The new Puppet 4 Master

Note

Make sure that your agents are prepared for operations with a Puppet 4 Master. See the notes about agents in the following section.

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.

Note

As of this writing, the Puppet 4 Java-based Master process is not yet available for Debian 8.

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'
}

Tip

The ini_setting resource type is available through the puppetlabs-inifile module from the Forge.

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.

Updating the Puppet agent

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.

Testing Puppet DSL code

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.

上一章目录下一章