a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
87 lines
3.9 KiB
Markdown
87 lines
3.9 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Upgrading Vault - Guides"
|
|
sidebar_title: "Upgrade Guides"
|
|
sidebar_current: "docs-upgrading"
|
|
description: |-
|
|
These are general upgrade instructions for Vault for both non-HA and HA
|
|
setups. Please ensure that you also read the version-specific upgrade notes.
|
|
---
|
|
|
|
# Upgrading Vault
|
|
|
|
These are general upgrade instructions for Vault for both non-HA and HA setups.
|
|
_Please ensure that you also read any version-specific upgrade notes which can be
|
|
found in the sidebar._
|
|
|
|
**Always** back up your data before upgrading! Vault does not make
|
|
backwards-compatibility guarantees for its data store. If you need to roll back
|
|
to a previous version of Vault, it is always a good idea to roll back your data
|
|
store as well.
|
|
|
|
## Non-HA Installations
|
|
|
|
Upgrading non-HA installations of Vault is as simple as replacing the Vault
|
|
binary with the new version and restarting Vault. Any upgrade tasks that can be
|
|
performed for you will be taken care of when Vault is unsealed.
|
|
|
|
Always use `SIGINT` or `SIGTERM` to properly shut down Vault.
|
|
|
|
Be sure to also read and follow any instructions in the version-specific
|
|
upgrade notes.
|
|
|
|
## HA Installations
|
|
|
|
This is our recommended upgrade procedure, and the procedure we use internally
|
|
at HashiCorp. However, you should consider how to apply these steps to your
|
|
particular setup since HA setups can differ on whether a load balancer is in
|
|
use, what addresses clients are being given to connect to Vault (standby +
|
|
leader, leader-only, or discovered via service discovery), etc.
|
|
|
|
Whatever method you use, you should ensure that you never fail over from a
|
|
newer version of Vault to an older version. Our suggested procedure is designed
|
|
to prevent this.
|
|
|
|
Please note that Vault does not support true zero-downtime upgrades, but with
|
|
proper upgrade procedure the downtime should be very short (a few hundred
|
|
milliseconds to a second depending on how the speed of access to the storage
|
|
backend).
|
|
|
|
Perform these steps on each standby:
|
|
|
|
1. Properly shut down Vault on the standby node via `SIGINT` or `SIGTERM`
|
|
2. Replace the Vault binary with the new version
|
|
3. Start the standby node
|
|
4. Unseal the standby node
|
|
|
|
At this point all standby nodes will be upgraded and ready to take over. The
|
|
upgrade will not be complete until one of the upgraded standby nodes takes over
|
|
active duty. To do this:
|
|
|
|
1. Properly shut down the remaining (active) node. Note: it is _**very
|
|
important**_ that you shut the node down properly. This causes the HA lock to
|
|
be released, allowing a standby node to take over with a very short delay.
|
|
If you kill Vault without letting it release the lock, a standby node will
|
|
not be able to take over until the lock's timeout period has expired. This
|
|
is backend-specific but could be ten seconds or more.
|
|
2. Replace the Vault binary with the new version; ensure that `mlock()` capability is added to the new binary with [setcap](https://www.vaultproject.io/docs/configuration/index.html#disable_mlock)
|
|
3. Start the node
|
|
4. Unseal the node (it will now be a standby)
|
|
|
|
Internal upgrade tasks will happen after one of the upgraded standby nodes
|
|
takes over active duty.
|
|
|
|
Be sure to also read and follow any instructions in the version-specific
|
|
upgrade notes.
|
|
|
|
## Replication Installations
|
|
|
|
-> **Note:** Prior to any upgrade, be sure to also read and follow any instructions in the version-specific
|
|
upgrade notes which are found in the navigation menu for this documentation.
|
|
|
|
Upgrading installations of Vault which participate in [Enterprise Replication](/docs/enterprise/replication/index.html) requires the following basic order of operations:
|
|
|
|
- **Upgrade the replication secondary instances first** using appropriate guidance from the previous sections depending on whether each secondary instance is Non-HA or HA
|
|
- Verify functionality of each secondary instance after upgrading
|
|
- When satisfied with functionality of upgraded secondary instances, upgrade the primary instance
|