Add command line flag to parallel client.options.consul.address.

[bradobro]

Short Version: We have Consul and Nomad driving our small staging cluster, but I have to hack a configuration file to get Nomad to properly register services. I'd like a better way to tell Nomad clients where their local Consul agent http interface is.

TL;DR: It seems that for Consul to behave correctly in a cluster we have to bind it to the private LAN interface (call it 192.168.0.10). Nomad needs to find that interface, but by default looks to localhost:8500.

Nomad works if I create a config file and set client.options.consul.address = 192.168.0.10:8500. But since Nomad can't deploy itself, I use systemd units to start it.

The only way I've found to correctly set the consul address is by sedding the config file before the service starts. I don't see a CLI flag to to set -consul_http_addr, and Nomad doesn't seem to notice the environment variable CONSUL_HTTP_ADDR

This might be from me not being clear about which interfaces Consul API's--serf, http, and rpc--should be published on in a cluster to cooperate with Nomad. The default, localhost seems safe, a good security default, but doesn't. I'd be glad to edit documentation if that's the only problem here.

Proposal: Short term, add a -consul-addr flag to Nomad that does exactly what client.options.consul.address does in the HCL. OR, inject environment variables into the Nomad HCL for interpolation.

Long term, given we have this great configuration ecosystem, let Nomad draw it's full configuration from Consul's kv store, with a way to inject IP address information, either environment variables or an environment variable file. For example:

/usr/local/bin/nomad -consul-addr=${PRIVATE_IPV4} -consul-config-root='/services/consul'

[diptanu]

@bradobro Can you bind consul to 0.0.0.0? That way Consul would bind to both loopback and any other interface and the default configuration should work or you could use localhost:port_number as your consul addr in nomad config.

However, I am not against adding support for making it easier for operators for specifying the Consul addr. We might be able to tackle this in 0.4, thanks for your proposal!

[bradobro]

Thanks for the input, @diptanu.

As for binding consul to 0.0.0.0, I thought that still binds to a single interface. The published Consul docs say:

-bind - The address that should be bound to for internal cluster communications. This is an IP address that should be reachable by all other nodes in the cluster. By default, this is "0.0.0.0", meaning Consul will use the first available private IP address.

I'm glad to move that part of the question to the consul project, but from my quick scour of open issues, listening on multiple interfaces isn't supported yet. I could be wrong (and hope I am!).

[schmichael]

The -consul-address flag was added in 0.7.1 thanks to #3504.

Sorry for not finding and closing this issue in a timely matter!

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.