Vault

Channel Revision Published Runs on
latest/edge 222 20 Jan 2024
Ubuntu 23.10
1.8/stable 209 05 Jan 2024
Ubuntu 22.04
1.8/edge 164 09 Aug 2023
Ubuntu 23.04
1.15/beta 276 18 Apr 2024
Ubuntu 22.04
1.15/edge 290 09 May 2024
Ubuntu 22.04
1.7/stable 210 10 Jan 2024
Ubuntu 22.04 Ubuntu 20.04
1.6/stable 289 05 May 2024
Ubuntu 20.04 Ubuntu 18.04
1.5/stable 268 11 Apr 2024
Ubuntu 20.04 Ubuntu 18.04
juju deploy vault --channel 1.15/beta
Show information

Platform:

Ubuntu
22.04

Starting Vault with Multiple Units

Vault’s Raft backend configuration is automatically generated and loaded onto all vault workloads in vault units. This configuration tells vault to search for other Vault units in the same application, and attempt to join their cluster.

In order for this to happen, there needs to be at least 1 vault unit that’s initialized and unsealed, and the joining unit and the active vault unit needs to share a root CA in their loaded certificates.

On first deployment, if you decide to deploy ,for example, 3 units, you will notice that they will all be awaiting initalization. After you initialize 1 unit, the other 2 will still be reporting that they need to be initialized. In this case, avoid initializing more than 1 vault unit. Once you unseal the unit you’ve already initialized, the other vault units will be able to join the cluster, replicate the Raft database, and automatically move to the unsealing stage.

There is no need for the active vault unit that you choose to initialize to match the juju leader unit. All vault units will automatically redirect any incoming requests to the leader unit (with one rare exception that’s handled by the charm).

Connecting to Vault

After all units are unsealed, vault units will send symmetrical responses. If you’re on K8s, you will have no issue simply using the application IP to allow the load balancer to decide which vault unit to serve.