Your upgrade questions answered – webinar Q&A
As part of our Puppet Upgrade webinar series, we recently hosted a webinar that discussed how to upgrade to Puppet Enterprise 2016.2. The replay is now available. Many great questions came up during the Q&A, so we decided to share the most common questions here and provide some additional detail.
What are the release numbers for 2016.1, 2016.2, etc? Can they be used in the Puppet 4 parser?
Back in July 2015 we moved to a date-based version numbering method for Puppet Enterprise. We did this in an effort to be more explicit about product versioning, and make it easy for you to know how current your implementation is. This started with Puppet Enterprise 2015.2, which came after Puppet Enterprise 3.8. All releases of Puppet Enterprise 2015.2 and newer use the Puppet 4 parser. Check out the component versions table for more details.
How big are the changes between future releases?
It really depends on the feature. “Z” releases, for example 3.8.1, contain smaller changes - typically security and high-priority bug fixes. Larger release transitions, such as from Puppet Enterprise 3.8 to Puppet Enterprise 2015.2, we deliver more significant changes.
Is it safe and supported to run an older version (for example version 3.3.2) of the Puppet agent with a newer version of Puppet Enterprise (for example 2016.2)?
We typically do support running recent agent versions with a newer master to enable you to make a gradual transition to the new release across your infrastructure. However, we recommend you upgrade agents as soon as possible. Running 3.3 agents with a Puppet Enterprise 2016.2 master is supported.
I have Puppet Enterprise 3.8 infrastructure and need to move to the new 2016.x infrastructure. Should I use the puppetlabs-puppet_agent module to do the upgrade? Do I cut the nodes over to the new master first, and then do the upgrade?
The puppet-agent module supports upgrading individual agent nodes from Puppet Enterprise 3.8 to 2016.x, and it does this during a Puppet run against the new 2016.x master. This means you have a 3.8 agent contacting a 2016.x master, which, while not recommended on a long-term basis, is sufficient to perform the upgrade operation.
What options do we have when running Puppet Enterprise 3.1 since the puppet_agent module is not compatible there?
We only test the module on Puppet Enterprise 3.8 and higher. While it may work with older versions, any issue encountered is not supported. You can still file a support ticket and the team will direct you as best they can with the available resources.
Aim to get your agents to Puppet Enterprise 3.8 by some other mechanism first (i.e. mpssh or the very old pe_upgrade module) and then use puppet-agent to go from version 3.8 to the 2016 series and handle the puppet.conf setting changes if there are any.
For the latest version of Puppet Enterprise (2016.2), what are the number of recommended nodes that a 1) a monolithic install can handle and 2) three-way-split install handle?
We have estimates in the system requirements section of the installation docs.
When we build the new environment do we not upgrade the current master of masters (MOM) servers? What about split installs and multiple compile masters?
The MoM should be upgraded first as it is used to upgrade other components. The new installer introduced in Puppet Enterprise 2016.2 has improved this to allow for less interaction between masters.
We have a manifest that configures r10k with the zack/r10k module. Will that still work the same for hiera?
r10k is shipped in Puppet Enterprise as of version 3.8 and is installed automatically. In Puppet Enterprise 2015.3 and later we offer Code Manager, a fully supported tool to subsume the webhook capability of zack/r10k.
You can read more about Code Manager, and switching from r10k in particular. If you aren’t already on a version of Puppet Enterprise that ships r10k, you should cut over to that first and this page has configuration details.
How can we implement eyaml in pe-puppet?
Eyaml works with Puppet Enterprise as long as you have the most recent version of eyaml. Older versions(< hiera-eyaml 2.1.0) had memory leaks when run in puppetserver. From there you simply need to install the gem with puppet_gem and puppetserver_gem providers. These are just implementing the gem commands for both Puppet 4’s ruby stack and puppetserver gem quarantine.
On puppet_agent a new pc_repo is being deployed in /etc/yum.repos.d. What is the main purpose of this file?
Puppet Enterprise does not manage the yum repo’s in the simplified agent installer. This repo is configured manually to align with the repos that exist on the local master infrastructure.
Optionally you can also get the puppet agent packages from the internet as the agent package is no longer specific to Puppet Enterprise.
The webinar focused on Puppet Enterprise 3.8 to 2016.2. Is the process comparable for 2016.1 to 2016.2 (or later)?
The process covered in the webinar is considered a migration. Going from 2016.1 to 2016.2 can be completed in place with an upgrade if preferred. You can read more about upgrading in our docs.
We have deployed Puppet Enterprise 3.7.4. What is the recommended upgrade path for this version?
We recommend setting up a test infrastructure on PE 3.8.6 and testing with the Catalog Preview module. Puppet Enterprise 3.8 provides the bridge between Puppet 3 and the new language constructs in Puppet 4, and Catalog Preview guides you in updating your code.
With a Monolithic + compile master installation, what are the recommended hardware requirements?
Details on tuning monolithic installations can be found in the latest Puppet Enterprise docs. It includes a tables with tuning information for various sizes of monolithic installations. These recommendations may vary depending on the size and complexity of your Puppet infrastructure.
How does the SSL migration work? Which SSL folder do you copy from where to where?
You can copy the $ssldir configuration option which defaults to /etc/puppetlabs/puppet/ssl. Our migration documentation covers these steps.
We are considering moving back to a monolithic install from a split install as part of an upgrade. Do you have any recommendations beyond the regular upgrade process?
The migration steps related to setting up a new Puppet Enterprise infrastructure that were covered in the webinar can be used for moving from a split to a monolithic install. Check out the latest documentation for more information. You’ll follow the same steps, but you will backup the SSL directory on your master and backup your databases on your PuppetDB server. The restore steps will be the same. Our support team can help if you have further questions.
There are many other fantastic questions covered in the webinar recording. Be sure to check out the on-demand webinar to see for yourself the best way to upgrade to the latest version of Puppet Enterprise. Also check out the latest upgrade documentation before you start. This will save you lots of time and is the best way to get started and set yourself up for success.
Remember, you don’t have to do it all by yourself. We’re here to help. Leveraging best-in-class methodology and tooling, our Professional Services team can help simplify the process so your upgrade is completed faster and with lower cost and risk. Puppet Upgrade Services will help you convert or replace existing Puppet code for compatibility, install and configure the latest Puppet Enterprise release, and migrate nodes to run against our new Puppet infrastructure.
Check out the Puppet Upgrade Services data sheet to learn more.
Stephanie Stouck is a senior services marketing manager at Puppet.
Zack Smith, principal professional services engineer at Puppet, also contributed to this post