gliderlabs / gliderlabs/docker-consul
DNS recursor issue with --net="host"
- Dominant language
- Shell
- Stars
- 1.1k
- Forks
- 270
- PR merge metrics
- No merged PRs in 30d
Description
This is a somewhat convoluted issue, please bear with me.
It is related to these issues:
https://github.com/hashicorp/consul/issues/602
https://github.com/hashicorp/consul/pull/724
When running on an environment such as AWS, you may need (as i do) to be able to resolve both the Amazon servers (for example) and the services that are registered at the Consul cluster.
(from inside other containers)
There is an issue with the Consul Docker image, where you must run the container using --net="host".
otherwise, communication is unstable.
Your local Consul-agent is used as DNS, but recurse to 8.8.8.8 - an issue that was addressed in the link above.
So now you could use -recursor=[internal-network-DNS], and you would be able to resolve both
ec2.internal (for example) and service.consul.
great! right?
but wait! you are using --net="host", so you are getting your container's resolve.conf file from the host!
and in that file, the consul search domain, and the localhost nameserver are not configured. (isolation!)
AND you can NOT use the -dns and -dns-search flags!
(and port 53 in now occupied)
so, for this feature to actually work, you will need to either get the Consul-Docker container to work without using --net="host" OR allow the -dns-search flag so you could modify the /etc/resolve.conf file using the "docker run" command.
(or hack it in the Dockerfile using env vars and bash)
otherwise this will require you to modify the resolve.conf on each and every host you are running the Consul agent on, to something like:
"search ec2.internal service.consul
nameserver 127.0.0.1
nameserver [internal-network-DNS]"
which, of course, goes against the entire Docker concept of containment / isolation / run anywhere etc.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.