task-networking: allowing easier discovery or connectivity to local Consul agents

[jrasell]

It would be helpful to provide a nicer experience in situations where tasks require access to the Consul API. It is possible to hook this up currently, but the way in which it needs to be done seems suboptimal. The request has came about due to work being performed on the Nomad Autoscaler which will optionally use Consul in the future.

Nomad Connect native tasks receive a number of Consul environment variables, including the HTTP address via the connectNativeHook which could potentially be replicated here as an opt-in for tasks running on nodes where there is a configured Consul client from the nodes view.

This functionality could also be extended to Vault, allowing for better integration across commonly used HashiCorp products.

Internal discussions points regarding potential solutions for context:

• Maximal: Nomad runs Consul and Vault agents and knows how best to expose them to each task.
• Minimal: Env vars for the agent's Consul + Vault address configuration.
• Middle: What we do for Connect/Envoy; there's a unix socket in there to work around the communication from inside the network namespace to outside. When the Nomad agent goes down, the UDS goes dark. Up until recently this means you'd have a local Connect outage every time Nomad or Consul restarted, recently Consul fixed that so Envoy can keep working even when it's unable to contact the Consul agent.

[jboero]

Consul is just about to release UDS support as well. Looking forward to this in the 1.10 release but support is available as of the 1.10beta2 release. 👍