vault: protect against empty Vault secret response
Fixes#4921
Sadly, we don't have proper mechanism to mock Vault client, so not sure how to best test this.
I inspected the Vault client interactions, specially for cases where returned value is nil even if the error is also nil. I believe we covered all correctly now:
* [`v.client.Sys().InitStatus()`](f3853f11da/nomad/vault.go (L427)) - the value is non-nil boolean
* [`v.client.Sys().CapabilitiesSelf(path)`](f3853f11da/nomad/vault.go (L812)): Capabilities handles empty bodies in [`hasCapability`](f3853f11da/vendor/github.com/hashicorp/vault/api/sys_capabilities.go (L43-L45)) - also the `nil` array is handled with proper fail-safe default.
* [`v.client.Logical().Read(fmt.Sprintf("auth/token/roles/%s", role))`](f3853f11da/nomad/vault.go (L834-L840)) handles when `rsecret` is nil
Looking at NewTaskRunner I'm unsure whether TaskRunner.TaskResources
(from which req.TaskResources is set) is intended to be nil at times or
if the TODO in NewTaskRunner is intended to ensure it is always non-nil.
The old approach was incomplete. Hook env vars are now:
* persisted and restored between agent restarts
* deterministic (LWW if 2 hooks set the same key)
This PR introduces a device hook that retrieves the device mount
information for an allocation. It also updates the computed node class
computation to take into account devices.
TODO Fix the task runner unit test. The environment variable is being
lost even though it is being properly set in the prestart hook.
This allows the container to be tagged with a user friendly image name
(e.g. `redis:3.2`) rather than the image ID (e.g.
`sha256:87856cc39862cec77541d68382e4867d7ccb29a85a17221446c857ddaebca916`).
Useful for human debugging, as well as some debugging and image scanning
tools.
This risks two bad changes:
1. Discrepancy in image resolution between docker and Nomad's image
loader.
* I checked the image creation paths in Nomad, and noticed that we
either pulled the image or inspect the image with the user provided
name.
2. A race in image tagging where the tag is modified between image
loading and container creation.
* I, personally, don't think this case is cause for concern, as it is
analogous to the task running a bit later. As long as the image is
still present, creating the container should be good.
* add vault integration guide in guides section and move current vault integration content to docs section
* complete guide with image
* fix typos
* rename step 6 and fix typos
* fix typos and awkward phrasing along with links
* fix duplicated step #
* fix typo
* fix links so that pages that pointed to the original vault integration content still point there
