vault/website/source/docs/configuration/storage/foundationdb.html.md
Jeff Escalante a43e292424 New Docs Website (#5535)
* 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
2018-10-19 08:40:11 -07:00

4.6 KiB
Raw Blame History

layout, page_title, sidebar_title, sidebar_current, description
layout page_title sidebar_title sidebar_current description
docs FoundationDB - Storage Backends - Configuration FoundationDB docs-configuration-storage-foundationdb The FoundationDB storage backend is used to persist Vault's data in the FoundationDB KV store.

FoundationDB Storage Backend

The FoundationDB storage backend is used to persist Vault's data in FoundationDB table.

The backend needs to be explicitly enabled at build time, and is not available in the standard Vault binary distribution. Please refer to the documentation accompanying the backend's source in the Vault source tree.

  • High Availability the FoundationDB storage backend supports high availability. The HA implementation relies on the clocks of the Vault nodes inside the cluster being properly sychronized; clock skews are susceptible to cause contention on the locks.

  • Community Supported the FoundationDB storage backend is supported by the community. While it has undergone review by HashiCorp employees, they may not be as knowledgeable about the technology. If you encounter problems with them, you may be referred to the original author.

storage "foundationdb" {
  api_version  = 510
  cluster_file = "/path/to/fdb.cluster"
  path         = "vault-top-level-directory"
  ha_enabled   = "true"
}

foundationdb Parameters

  • api_version (int) - The FoundationDB API version to use; this is a required parameter and doesn't have a default value. Future versions will impose a minimum API version to access newer features.

  • cluster_file (string) - The path to the cluster file containing the connection data for the target cluster; this is a required parameter and doesn't have a default value.

  • path (string: "vault") - The path of the top-level FoundationDB directory (using the directory layer) under which the Vault data will reside.

  • ha_enabled (string: "false") - Whether or not to enable Vault high-availability mode using the FoundationDB backend.

foundationdb tips

Cluster file

The FoundationDB client expects to be able to update the cluster file at runtime, to keep it current with changes happening to the cluster.

It does so by first writing a new cluster file alongside the current one, then atomically renaming it into place.

This means the cluster file and the directory it resides in must be writable by the user Vault is running as. You probably want to isolate the cluster file into its own directory.

Multi-version client

The FoundationDB client library version is tightly coupled to the server version; during cluster upgrades, multiple server versions will be running in the cluster, and the client must cope with that situation.

This is handled by the (primary) client library having the ability to load a different version of the client library to connect to a particular server; it is referred to as the multi-version client feature.

Client setup with LD_LIBRARY_PATH

If you do not use mlock, you can use LD_LIBRARY_PATH to point the linker at the location of the primary client library.

$ export LD_LIBRARY_PATH=/dest/dir/for/primary:$LD_LIBRARY_PATH
$ export FDB_NETWORK_OPTION_EXTERNAL_CLIENT_DIRECTORY=/dest/dir/for/secondary
$ /path/to/bin/vault ...

Client setup with RPATH

When running Vault with mlock, the Vault binary must have capabilities set to allow the use of mlock.

# setcap cap_ipc_lock=+ep /path/to/bin/vault
$ getcap /path/to/bin/vault
/path/to/bin/vault = cap_ipc_lock+ep

The presence of the capabilities will cause the linker to ignore LD_LIBRARY_PATH, for security reasons.

In that case, we have to set an RPATH on the Vault binary at build time to replace the use of LD_LIBRARY_PATH.

When building Vault, pass the -r /dest/dir/for/primary option to the Go linker, for instance:

$ make dev FDB_ENABLED=1 LD_FLAGS="-r /dest/dir/for/primary "

(Note the trailing space in the variable value above).

You can verify RPATH is set on the Vault binary using readelf:

$ readelf -d /path/to/bin/vault | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [/dest/dir/for/primary]

With the client libraries installed:

$ ldd /path/to/bin/vault
...
    libfdb_c.so => /dest/dir/for/primary/libfdb_c.so (0x00007f270ad05000)
...

Now run Vault:

$ export FDB_NETWORK_OPTION_EXTERNAL_CLIENT_DIRECTORY=/dest/dir/for/secondary
$ /path/to/bin/vault ...