Upgrading Puppet Enterprise
Upgrade your PE installation as new versions become available.
Upgrade paths
These are the valid upgrade paths for PE.
If you're on version... | Upgrade to... | Notes |
---|---|---|
2023.0 (latest) | You're up to date! | |
2021.7.z | latest | Review the upgrade cautions and other information on this page. |
2021.y or 2019.8.z | 2021.7.z | For important information about this upgrade, refer to Upgrading Puppet Enterprise in the 2021.7.z documentation. |
2019.y | 2019.8.12 | |
Earlier versions | Refer to Upgrade paths in the 2019.8.z documentation. |
Upgrade cautions
These are the major changes to PE since the last long-term support release, 2021.7. Review these recommendations and plan accordingly before upgrading to this version.
Java 17 upgrade in PE 2023.0
PE 2023.0 includes an upgrade from Java version 11 to version 17. With this upgrade, PE uses the G1 garbage collector by default, instead of Parallel.
Thoroughly test PE 2023.0 in a non-production environment before upgrading if you customized PE Java services or you use plug-ins that include Java code.
FIPS-enabled PE 2023.0 can't use the default system cert store
FIPS-compliant builds running PE 2023.0 can't use the
default system cert store, which is used automatically with some reporting services.
This setting is configured by the report_include_system_store
Puppet parameter that ships with PE.
Removing the puppet-cacerts
file (located at /opt/puppetlabs/puppet/ssl/puppet-cacerts
) can allow a
report processor that eagerly loads the system store to continue with a warning that
the file is missing.
If HTTP clients require external certs, we recommend using a custom cert store
containing only the necessary certs. You can create this cert store by concatenating
existing pem
files and configuring the ssl_trust_store
Puppet parameter to point to the new cert
store.
Platforms removed in 2023.0
Platforms that were previously deprecated have been removed in PE 2023.0.
Before upgrading to 2023.0, remove the pe_repo::platform
class for these operating systems from the PE Master node group
in the console, and from your code and Hiera.
- Removed platforms
- Removed primary server platforms
- CentOS 8
- Removed agent platforms
- CentOS 8
- Removed client tools platforms
- No client tools platforms removed.
- Removed patching platforms
- Debian 9
Test modules before upgrading
Before upgrading, make sure your modules work with the newest PE version by using the Puppet Development Kit (PDK) to update and test your modules.
If you're already using PDK, your modules should pass validation and unit tests with your currently installed version of PDK.
Updating PDK with each new release ensures module compatibility with new versions of PE.
Upgrade PE
Upgrade PE infrastructure components to get the latest features and fixes. Follow the upgrade instructions for your installation type to ensure you upgrade components in the correct order. Coordinate upgrades to ensure all infrastructure nodes are upgraded in a timely manner, because agent runs and replication fail if infrastructure nodes are running a different agent version than the primary server.
Review the upgrade cautions for major changes to architecture and infrastructure components which might affect your upgrade.
Configure non-production environment for infrastructure nodes
If your infrastructure nodes are in an environment other than production
, you must manually configure PE to
use your chosen environment before you upgrade.
production
.pe.conf
, set both of these parameters to the
environment your infrastructure nodes are in:
pe_install::install::classification::pe_node_group_environment
puppet_enterprise::master::recover_configuration::pe_environment
Upgrade a standard installation
To upgrade a standard installation, run the PE installer on your primary server, and then upgrade any additional components.
Back up your PE installation.
If you're upgrading a replica, ensure you have a valid admin RBAC token.
In Hiera, pe.conf
, or the console (in the PE Master node
group), remove any agent_version
parameters you set
in the pe_repo
class that matches your
infrastructure nodes. This ensures the upgrade isn't blocked by attempting to
download non-default agent versions for your infrastructure OS and architecture.
Upgrade a large installation
To upgrade a large installation, run the PE installer on your primary server, and then upgrade compilers and any additional components.
Back up your PE installation.
Ensure you have a valid admin RBAC token in order to upgrade compilers or a replica.
In Hiera, pe.conf
, or the console (in the PE Master node
group), remove any agent_version
parameters you set
in the pe_repo
class that matches your
infrastructure nodes. This ensures the upgrade isn't blocked by attempting to
download non-default agent versions for your infrastructure OS and architecture.
Optionally convert legacy compilers to the new style compiler running the PuppetDB service.
Upgrade an extra-large installation
You can use the PEADM module to upgrade extra-large installations. Contact your technical account manager for additional support.
Upgrade a standalone PE-PostgreSQL installation
To upgrade a large installation with standalone PE-PostgreSQL, run the PE installer first on your PE-PostgreSQL node, then on your primary server, and then upgrade any additional components.
Back up your PE installation.
Ensure you have a valid admin RBAC token in order to upgrade compilers.
In Hiera, pe.conf
, or the console (in the PE Master node
group), remove any agent_version
parameters you set
in the pe_repo
class that matches your
infrastructure nodes. This ensures the upgrade isn't blocked by attempting to
download non-default agent versions for your infrastructure OS and architecture.
Optionally convert legacy compilers to the new style compiler running the PuppetDB service.
Upgrade an unmanaged PostgreSQL installation
You can upgrade a Puppet Enterprise (PE) installation that relies on an unmanaged PostgreSQL database.
Optionally, convert existing compilers to the new style compiler running the PuppetDB service.
CONCURRENTLY
with PostgreSQL 14.0 through 14.3. However, if you do,
ensure that you REINDEX
without using CONCURRENTLY
.Migrate PE
As an alternative to upgrading, you can migrate your PE installation. Migrating results in little or no downtime, but it requires additional system resources because you must configure a new primary server.
For standard installations with disaster recovery, follow the steps to Upgrade a standard installation.
For large installations with or without disaster recovery, follow the steps to Upgrade a large installation.
For all extra-large installations or any size installation where either upgrading or migrating is not possible, contact your technical account manager.
Migrate a standard installation
Migrate a standard installation by standing up a new primary server, restoring it with your existing installation, upgrading it, and then pointing agents at the new primary.
Review the upgrade cautions for major changes to architecture and infrastructure components which might affect your upgrade.