* 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
3.9 KiB
layout | page_title | sidebar_title | sidebar_current | description |
---|---|---|---|---|
docs | Upgrading Vault - Guides | Upgrade Guides | docs-upgrading | 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:
- Properly shut down Vault on the standby node via
SIGINT
orSIGTERM
- Replace the Vault binary with the new version
- Start the standby node
- 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:
- 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.
- Replace the Vault binary with the new version; ensure that
mlock()
capability is added to the new binary with setcap - Start the node
- 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 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