diff --git a/website/content/commands/license.mdx b/website/content/commands/license.mdx
index 3998d7ae81b2..133e2f0dbfaa 100644
--- a/website/content/commands/license.mdx
+++ b/website/content/commands/license.mdx
@@ -14,7 +14,7 @@ Command: `consul license`
The `license` command provides a datacenter-level view of the Consul Enterprise license. This was added
in Consul 1.1.0 but Consul 1.10.0 removed the ability to set and reset the license using the CLI.
-See the [licensing documentation](/docs/enterprise#licensing) for more information about
+See the [licensing documentation](/docs/enterprise/license/overview) for more information about
Consul Enterprise license management.
If ACLs are enabled then a token with operator privileges may be required in
diff --git a/website/content/commands/snapshot/agent.mdx b/website/content/commands/snapshot/agent.mdx
index eab04e69a3dd..dcbe1fe61035 100644
--- a/website/content/commands/snapshot/agent.mdx
+++ b/website/content/commands/snapshot/agent.mdx
@@ -394,5 +394,6 @@ then the order of precedence is as follows:
2. `CONSUL_LICENSE_PATH` variable
3. `license_path` configuration.
-See the [licensing documentation](/docs/enterprise#licensing) for more information about
-Consul Enterprise license management.
\ No newline at end of file
+The ability to load licenses from the configuration or environment was added in v1.10.0,
+v1.9.7 and v1.8.13. See the [licensing documentation](/docs/enterprise/license/overview) for
+more information about Consul Enterprise license management.
\ No newline at end of file
diff --git a/website/content/docs/agent/options.mdx b/website/content/docs/agent/options.mdx
index f543c18cdcdc..d4c49811b1ee 100644
--- a/website/content/docs/agent/options.mdx
+++ b/website/content/docs/agent/options.mdx
@@ -1636,7 +1636,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
- `leave_on_terminate` If enabled, when the agent receives a TERM signal, it will send a `Leave` message to the rest of the cluster and gracefully leave. The default behavior for this feature varies based on whether or not the agent is running as a client or a server (prior to Consul 0.7 the default value was unconditionally set to `false`). On agents in client-mode, this defaults to `true` and for agents in server-mode, this defaults to `false`.
-- `license_path` This specifies the path to a file that contains the Consul Enterprise license. Alternatively the license may also be specified in either the `CONSUL_LICENSE` or `CONSUL_LICENSE_PATH` environment variables. See the [licensing documentation](/docs/enterprise#licensing) for more information about Consul Enterprise license management.
+- `license_path` This specifies the path to a file that contains the Consul Enterprise license. Alternatively the license may also be specified in either the `CONSUL_LICENSE` or `CONSUL_LICENSE_PATH` environment variables. See the [licensing documentation](/docs/enterprise/license/overview) for more information about Consul Enterprise license management. Added in versions 1.10.0, 1.9.7 and 1.8.13. Prior to version 1.10.0 the value may be set for all agents to faciliate forwards compatibility with 1.10 but will only actually be used by client agents.
- `limits` Available in Consul 0.9.3 and later, this is a nested
object that configures limits that are enforced by the agent. Prior to Consul 1.5.2,
diff --git a/website/content/docs/upgrading/instructions/index.mdx b/website/content/docs/upgrading/instructions/index.mdx
index 11c0997601f6..7487f6c2fa6a 100644
--- a/website/content/docs/upgrading/instructions/index.mdx
+++ b/website/content/docs/upgrading/instructions/index.mdx
@@ -9,7 +9,7 @@ description: >-
# Upgrade Instructions
This document is intended to help users who find themselves many versions behind to upgrade safely.
-Our recommended upgrade path is moving from version 0.8.5 to 1.2.4 to 1.6.9 to 1.8.10 to the current version. To get
+Our recommended upgrade path is moving from version 0.8.5 to 1.2.4 to 1.6.9 to 1.8.13 to the current version. To get
started, you will want to choose the version you are currently on below and then follow the instructions
until you are on the latest version. The upgrade guides will mention notable changes and link to relevant
changelogs – we recommend reviewing the changelog for versions between the one you are on and the
@@ -29,6 +29,8 @@ To get instructions for your upgrade, please choose the release series you are _
- [1.5.x](/docs/upgrading/instructions/upgrade-to-1-6-x)
- [1.6.x](/docs/upgrading/instructions/upgrade-to-1-8-x)
- [1.7.x](/docs/upgrading/instructions/upgrade-to-1-8-x)
+- [1.8.x](/docs/upgrading/instructions/upgrade-to-1-10-x)
+- [1.9.x](/docs/upgrading/instructions/upgrade-to-1-10-x)
If you are using <= 0.7.x, please contact support for assistance:
diff --git a/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx b/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx
new file mode 100644
index 000000000000..f27405cecb3f
--- /dev/null
+++ b/website/content/docs/upgrading/instructions/upgrade-to-1-10-x.mdx
@@ -0,0 +1,251 @@
+---
+layout: docs
+page_title: Upgrading to 1.10.0
+description: >-
+ Specific versions of Consul may have additional information about the upgrade
+ process beyond the standard flow.
+---
+
+# Upgrading to 1.10.0
+
+
+
+## Introduction
+
+This guide explains how to best upgrade a single Consul Enterprise datacenter to v1.10.0
+from a version of Consul that is forwards compatible with v1.10. If you are on a major
+version of Consul prior to 1.8, you will need to complete and [upgrade to 1.8.13](/docs/upgrading/instructions)
+or higher before continuing with this guide. If you are already on major versions 1.8 or 1.9
+this guide will go over the procedures required for upgrading to v1.10. This process
+will require intermediate version upgrades to a forwards compatible release of v1.8 or v1.9
+as well as other licensing related configuration changes. If you have multiple Consul datacenters
+then they are upgraded in the normal order with each upgrade taking into account the instructions below.
+
+For the open source version of Consul please follow the
+[General Upgrade Process](/docs/upgrading/instructions/general-process).
+
+~> You can only upgrade to Consul Enterprise 1.10 from a version of Consul Enterprise
+1.8 >= 1.8.13 or 1.9 >= 1.9.7. Other versions of Consul Enterprise are not forwards
+compatible with v1.10 and will cause issues during the upgrade that could result in
+agents failing to start due to [changes in the way we manage licenses](/docs/enterprise/license/faq).
+
+## Requirements
+
+- All Consul servers, clients and snapshot agents should be on a version of Consul >= 1.8.0 and < 1.10.0. If
+ they are not at the minimum version or higher, follow [normal upgrade procedures](/docs/upgrading) to get them there.
+
+## Assumptions
+
+This guides makes the following assumptions:
+
+- You are familiar with the [General Upgrade Process](/docs/upgrading/instructions/general-process).
+- You have the ability to run Consul CLI commands.
+- If ACLs are in use then you possess a token with at least `operator:read` permissions.
+
+## Considerations
+
+The main breaking changes in Consul Enterprise 1.10 that need special handling during upgrading are
+the licensing changes outlined on the [Specific Version Details](/docs/upgrading/upgrade-specific#consul-1-10-0)
+page. There are notes on that page about other changes that might cause issues during an upgrade as well.
+You can find more granular details in the [licensing FAQ](/docs/enterprise/license/faq) as well as the full
+[changelog](https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#1100-june-22-2021).
+Looking through these changes prior to upgrading is highly recommended.
+
+## Procedures
+
+~> Any steps in the following section that mention upgrading servers/clients assume that normal safe upgrade
+procedures are followed. These instructions require licensing related configuration changes
+needed to upgrade to 1.10, and also require intermediate version upgrades to ensure forward compatibility.
+Refer to our documentation for the [basic server upgrade process](/docs/upgrading/instructions/general-process),
+and for [autopilot assisted upgrades](https://learn.hashicorp.com/tutorials/consul/upgrade-automation)
+for more information.
+
+**1.** Retrieve the datacenter's current license by executing the following CLI command:
+
+```shell
+consul license get -signed > consul.hclic
+```
+
+ Note that the command can be run on anywhere that is running Consul already or from some other location
+ that has network access to the cluster. If run elsewhere than other options to the command may be neede
+ to direct the request to the right Consul API.
+
+
+ This will save the license to a file in the local directory named `consul.hclic`. Having this
+ will be useful when preparing the license for the 1.10 upgrades later on in the process.
+
+**2.** Take a snapshot of the cluster by running the following command:
+
+```shell
+consul snapshot save original.snap
+```
+
+ Note that the command can be run on anywhere that is running Consul already or from some other location
+ that has network access to the cluster. If run elsewhere than other options to the command may be neede
+ to direct the request to the right Consul API.
+
+ Note that you will need to ensure there is enough disk space in the current directory
+ to store the snapshot. In the worst case, the snapshot size could be close to the amount
+ of RAM the Consul server processes are consuming.
+
+ This snapshot should not be needed but if something were to go wrong, having
+ the snapshot would make it possible to restore the previous state.
+
+**3.** Determine if ACLs are enabled by running the following CLI command.
+
+```shell
+consul info | grep "acl ="
+````
+
+ If you receive output like either of the following then ACLs are enabled:
+
+```text
+Error querying agent: Unexpected response code: 403 (Permission denied)
+```
+
+```text
+ acl = enabled
+
+```
+
+ Select the correct tab below based on whether ACLs are enabled or disabled or if you
+ are operating Consul within Kubernetes.
+
+
+
+
+**4.** Upgrade all server agents to the latest 1.8.x or 1.9.x release.
+
+**5.** Upgrade all client agents to the latest 1.8.x or 1.9.x release.
+
+**6.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to the latest 1.8.x or 1.9.x release.
+
+**7.** Take a snapshot of the upgraded cluster by running the following command:
+
+```shell
+consul snapshot save intermediate.snap
+```
+
+ Note that the command can be run on anywhere that is running Consul already or from some other location
+ that has network access to the cluster. If run elsewhere than [other options](/docs/commands/snapshot/save#api-options)
+ to the command may be needed to direct the request to the right Consul API.
+
+ Note that you will need to ensure there is enough disk space in the current directory
+ to store the snapshot. In the worst case, the snapshot size could be close to the amount
+ of RAM the Consul server processes are consuming.
+
+ This snapshot should not be needed but if something were to go wrong, having
+ the snapshot would make it possible to restore the previous state.
+
+**8.** Pre-configure the server agents with a license.
+
+ This can either be set with the `license_path` configuration item, the
+ `CONSUL_LICENSE_PATH` environment variable or the `CONSUL_LICENSE`
+ environment variable. See the [licensing documentation](/docs/enterprise/license/overview)
+ for more information about how to configure the license.
+
+**9.** Upgrade all server agents to v1.10.0.
+
+**10.** Upgrade all client agents to v1.10.0.
+
+**11.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to v1.10.0.
+
+
+
+
+~> We do not recommend running in production with ACLs disabled. An alternative upgrade
+ path involves first enabling ACLs by following [this tutorial](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production)
+ and then proceeding with the instructions within the "ACLs Enabled" tab.
+
+**4.** Upgrade all server agents to the latest 1.8.x or 1.9.x release.
+
+**5.** Pre-configure the client agents with a license.
+
+ This can either be set with the `license_path` configuration item, the
+ `CONSUL_LICENSE_PATH` environment variable or the `CONSUL_LICENSE`
+ environment variable. See the [licensing documentation](/docs/enterprise/license/overview)
+ for more information about how to configure the license. Note that while
+ Consul Enterprise 1.8.13 and 1.9.7 have the ability to load the license
+ from these configurations, it is intended to only be used during upgrades.
+ Licenses loaded this way are not online reloadable. It is therefore important
+ to promptly proceed with the upgrade and not leave agents in the intermediate state.
+
+**6.** Upgrade all client agents to the latest 1.8.x or 1.9.x release.
+
+**7.** Pre-configure the snapshot agents with a license. This is the same process that
+ was executed for the servers in step 5.
+
+**8.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to the latest 1.8.x or 1.9.x release.
+
+**9.** Take a snapshot of the upgraded cluster by running the following command:
+
+```shell
+consul snapshot save intermediate.snap
+```
+
+ Note that the command can be run on anywhere that is running Consul already or from some other location
+ that has network access to the cluster. If run elsewhere than other options to the command may be neede
+ to direct the request to the right Consul API.
+
+ Note that you will need to ensure there is enough disk space in the current directory
+ to store the snapshot. In the worst case, the snapshot size could be close to the amount
+ of RAM the Consul server processes are consuming.
+
+ This snapshot should not be needed but if something were to go wrong, having
+ the snapshot would make it possible to restore the previous state.
+
+**8.** Pre-configure the server agents with a license. This is the same process that
+ was executed for the servers in step 5.
+
+**9.** Upgrade all server agents to v1.10.0.
+
+**10.** Upgrade all client agents to v1.10.0.
+
+**11.** Upgrade all [snapshot agents](/docs/commands/snapshot/agent) to v1.10.0.
+
+
+
+
+**4.** **If** the Consul servers are running outside the Kubernetes cluster, ensure they are upgraded
+to the latest 1.8.x or 1.9.x before the next steps. Otherwise, this step can be skipped.
+
+**5.** Upgrade to the latest Consul helm chart v0.32.0+.
+
+**6.** Update the value of `global.image` in the values file to the latest 1.8.x or 1.9.x image.
+
+ Additionally, ensure that the Kuberenetes secret with the license is specified in the
+ values `server.enterpriseLicense.secretName` and `server.enterpriseLicense.secretKey`.
+
+**7.** Upgrade the cluster.
+
+ Follow the steps in the [Kubernetes Upgrade Guide](/docs/k8s/upgrade#upgrade-consul-on-kubernetes)
+ to upgrade the cluster. Ensure you check the steps to upgrade the [servers](/docs/k8s/upgrade#upgrading-consul-servers)
+ and the [clients](/docs/k8s/upgrade#upgrading-consul-clients).
+
+**8.** **If** the Consul servers are running outside the Kubernetes cluster, ensure they are upgraded
+ to 1.10.0 before the next steps. Otherwise, this step can be skipped.
+
+ This will require pre-configuring the servers with a license
+ before running 1.10. This can either be set with the `license_path` configuration item, the
+ `CONSUL_LICENSE_PATH` environment variable or the `CONSUL_LICENSE`
+ environment variable. See the [licensing documentation](/docs/enterprise/license/overview)
+ for more information about how to configure the license. Note that while
+ Consul Enterprise 1.8.13 and 1.9.7 have the ability to load the license
+ from these configurations, it is intended to only be used during upgrades.
+ Licenses loaded this way are not online reloadable. It is therefore important
+ to promptly proceed with the upgrade and not leave agents in the intermediate state.
+
+**9.** Update the value of `global.image` in the values file to the 1.10.0 image.
+
+**10.** Upgrade the cluster.
+
+ Follow the steps in the [Kubernetes Upgrade Guide](/docs/k8s/upgrade#upgrade-consul-on-kubernetes)
+ to then upgrade the cluster. Ensure you check the steps to upgrade the [servers](/docs/k8s/upgrade#upgrading-consul-servers)
+ and the [clients](/docs/k8s/upgrade#upgrading-consul-clients).
+
+
+
+
+## Post-Upgrade Configuration Changes
+
+No configuration changes are required for this upgrade.
diff --git a/website/content/docs/upgrading/instructions/upgrade-to-1-8-x.mdx b/website/content/docs/upgrading/instructions/upgrade-to-1-8-x.mdx
index 104e168b3fbb..6a685b8de9d1 100644
--- a/website/content/docs/upgrading/instructions/upgrade-to-1-8-x.mdx
+++ b/website/content/docs/upgrading/instructions/upgrade-to-1-8-x.mdx
@@ -1,17 +1,17 @@
---
layout: docs
-page_title: Upgrading to 1.8.10
+page_title: Upgrading to 1.8.13
description: >-
Specific versions of Consul may have additional information about the upgrade
process beyond the standard flow.
---
-# Upgrading to 1.8.10
+# Upgrading to 1.8.13
## Introduction
This guide explains how to best upgrade a multi-datacenter Consul deployment that is using
-a version of Consul >= 1.6.9 and < 1.8.10 while maintaining replication. If you are on a version
+a version of Consul >= 1.6.9 and < 1.8.13 while maintaining replication. If you are on a version
older than 1.6.9, please follow the link for the version you are on from [here](/docs/upgrading/instructions).
In this guide, we will be using an example with two datacenters (DCs) and will be
@@ -19,7 +19,7 @@ referring to them as DC1 and DC2. DC1 will be the primary datacenter.
## Requirements
-- All Consul servers should be on a version of Consul >= 1.6.9 and < 1.8.10.
+- All Consul servers should be on a version of Consul >= 1.6.9 and < 1.8.13.
## Assumptions
@@ -87,7 +87,7 @@ You should receive output similar to this:
}
```
-**3.** Upgrade the Consul agents in all DCs to version 1.8.10 by following our [General Upgrade Process](/docs/upgrading/instructions/general-process).
+**3.** Upgrade the Consul agents in all DCs to version 1.8.13 by following our [General Upgrade Process](/docs/upgrading/instructions/general-process).
**4.** Confirm that replication is still working in DC2 by issuing the following curl command from a
consul server in that DC:
diff --git a/website/content/docs/upgrading/upgrade-specific.mdx b/website/content/docs/upgrading/upgrade-specific.mdx
index becb1b0502a7..d3c839343781 100644
--- a/website/content/docs/upgrading/upgrade-specific.mdx
+++ b/website/content/docs/upgrading/upgrade-specific.mdx
@@ -21,7 +21,7 @@ upgrade flow.
Consul Enterprise 1.10 has removed temporary licensing capabilities from the binaries
found on https://releases.hashicorp.com. Servers will no longer load a license previously
set through the CLI or API. Instead the license must be present in the server's configuration
-or environment prior to starting. See the [licensing documentation](/docs/enterprise#licensing)
+or environment prior to starting. See the [licensing documentation](/docs/enterprise/license/overview)
for more information about how to configure the license. Client agents previously retrieved their
license from the servers in the cluster within 30 minutes of starting and the snapshot agent
would similarly retrieve its license from the server or client agent it was configured to use. As
@@ -35,18 +35,8 @@ agents require that either the [`start_join`](/docs/agent/opts#start_join) or
agents. If those stipulations are not met, attempting to start the client or snapshot agent will
result in it immediately shutting down.
-#### Migration
-Prior to upgrading Consul Enterprise to v1.10 you should ensure the license is set in all the right places.
-In general following these steps should be all thats necessary to ensure a smooth upgrade.
-
-1. Retrieve the existing license from your existing cluster by running `consul license get -signed`
-2. Ensure that the license is configured on all your servers by setting the one of the `license_path`
- configuration item, the `CONSUL_LICENSE_PATH` environment variable or the `CONSUL_LICENSE`
- environment variable.
-3. If ACLs are not in use or if not all client agents are configured with the necessary `start_join` /
- `retry_join` configurations pointing to servers, then repeat step 2 for all client agents.
-4. If ACLs are not in use then repeat step 2 for all snapshot agents.
-5. Now proceed with the [standard upgrade procedure](/docs/upgrading#standard-upgrades).
+For the step by step upgrade procedures see the [Upgrading to 1.10.0](/docs/upgrading/instructions/upgrade-to-1-10-x) documentation.
+For answers to common licensing questions please refer to the [FAQ](/docs/enterprise/license/faq)
### Envoy xDS Protocol Upgrades
diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json
index 75791414d86a..66f5e3259a4d 100644
--- a/website/data/docs-nav-data.json
+++ b/website/data/docs-nav-data.json
@@ -939,8 +939,12 @@
"path": "upgrading/instructions/upgrade-to-1-6-x"
},
{
- "title": "Upgrading to 1.8.10",
+ "title": "Upgrading to 1.8.13",
"path": "upgrading/instructions/upgrade-to-1-8-x"
+ },
+ {
+ "title": "Upgrading to 1.10.0",
+ "path": "upgrading/instructions/upgrade-to-1-10-x"
}
]
}
@@ -987,4 +991,4 @@
"path": "guides",
"hidden": true
}
-]
+]
\ No newline at end of file