`dns` key is not valued as within `docker run`

[ChristianKniep]

I use the latest homebrew version of docker and docker-compose.

➜  temp  docker version
Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.6
 Git commit:   c3959b1
 Built:        Tue Feb 23 21:12:32 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 22:37:33 2016
 OS/Arch:      linux/amd64
➜  temp  compose version
docker-compose version 1.6.2, build unknown
docker-py version: 1.7.2
CPython version: 2.7.10
OpenSSL version: OpenSSL 0.9.8zg 14 July 2015
➜  temp

When running a container the --dns option is handled correctly.

$ docker run -d --hostname consul \
                  --dns=127.0.0.1 -p 8500 -e DC_NAME=dc1 \
                  -e CONSUL_BOOTSTRAP=true qnib/alpn-consul
$ docker exec -ti 86e7f95119c5 cat /etc/resolv.conf
search ad.gaikai.biz
nameserver 127.0.0.1
$

When starting the exact container using docker-compose v2, I get the embedded DNS server. :(

➜  temp  cat docker-compose.yml
version: '2'
services:
  consul:
    image: qnib/alpn-consul
    hostname: consul
    dns:
     - 127.0.0.1
    ports:
     - 8500
    environment:
     - DC_NAME=dc1
     - CONSUL_BOOTSTRAP=true
➜  temp  compose up -d
Creating temp_consul_1
➜  temp  docker exec -ti temp_consul_1 cat /etc/resolv.conf
search ad.gaikai.biz
nameserver 127.0.0.11
options ndots:0
➜  temp

docker-compose v1, consideres the correct DNS though...

➜  temp  compose up -d
Creating temp_consul_1
➜  temp  docker exec -ti temp_consul_1 cat /etc/resolv.conf
search ad.gaikai.biz
nameserver 127.0.0.1
➜  temp  cat docker-compose.yml
consul:
    image: qnib/alpn-consul
    hostname: consul
    dns:
     - 127.0.0.1
    ports:
     - 8500
    environment:
     - DC_NAME=dc1
     - CONSUL_BOOTSTRAP=true
➜  temp

[mavenugo]

@ChristianKniep this is the expected behavior since Compose V2 creates a docker network for every compose application while Compose V1 uses the default network. Default network doesnt use the embedded DNS server and hence you will see the DNS server that is passed in -dns as part of /etc/resolv.conf.

The embedded DNS server internally manages and handles the external DNS servers that is passed via -dns (but the /etc/resolv.conf will only contain the embedded DNS server : 127.0.0.11).

I have a question on this use-case though. Why would you want to use --dns=127.0.0.1 ?
Does dock.gaikai.org/qnib/alpn-consul depend on a DNS server that is installed within the same container ?

[ChristianKniep]

I use Consul for service and node discovery.

Hmm, that's a bummer then. Is there now way of controlling the DNS? Wouldn't it make sense to keep this --dns option? What harm does it introduce?

qnib.org

[mavenugo]

@ChristianKniep maybe I didnt communicate it clearly. the --dns option is infact used internally by the embedded DNS server and directs the requests to the DNS servers that is specified by --dns.

The only case that doesn't work is the --dns=127.0.0.1. hence am trying to understand the validity of the use-case for trying --dns=127.0.0.1.

[ChristianKniep]

Sorry @mavenugo,

a quick response from my phone. Let me eleborate a bit.
As Consul exposes DNS records of all nodes (as <name>.node.consul) and all services (as <service>.service.consul), it's very convenient to use this within docker containers.
An example I wrote up here: http://qnib.org/2015/01/15/Consul-example/

For this to work the resolver for the container should be the consul agent itself. I configure consul to use port 53 and point the dns to localhost and I am good.

Ok, but you wrote that the embedded DNS will deal with the option and will handle it.
So if I provide the option --dns 127.0.0.1 and query the DNS records of Consul, it should be resolved?

Sorry for the confusion, if the Consul DNS still works; I am good. :)

[ChristianKniep]

Hmm... If I provide two dns servers (127.0.0.1, 8.8.8.8), they do not seem to be asked by the embedded one.

bash-4.3# dig @127.0.0.1 consul.service.consul +short
172.18.0.2
bash-4.3# dig @127.0.0.11 consul.service.consul +short
^Cbash-4.3#
bash-4.3#

[ChristianKniep]

The DNS entries are reflected in the container config.

$ docker inspect -f '{{ .HostConfig.Dns }}' temp_consul_1
[127.0.0.1 8.8.8.8]

[mavenugo]

@ChristianKniep yes. as explained in the previous comment, the DNS entries configured by the user are infact used by libnetwork's embedded DNS to provide the appropriate resolution. My question to you was only on the need for 127.0.0.1 as an external DNS param. I dont understand the usefulness of it.

For example, I do understand that if we have 2 containers, server and client (as in your example), it make sense to have the --dns=<SERVER-IP> while running the client container. But why is it required to have --dns=127.0.0.1 on the server container when it serves the DNS ? Is it purely for testing itself in the loopback scenario ? Or is it required that the server must point itself as a DNS server ?

[ChristianKniep]

@mavenugo As within this example: https://github.com/ChristianKniep/orchestra/blob/master/consul/docker-compose.yml

➜  consul git:(master) ✗ compose up -d
Creating consul
Creating terminal
➜  consul git:(master) ✗ compose ps
  Name                Command               State           Ports
--------------------------------------------------------------------------
consul     /opt/qnib/supervisor/bin/s ...   Up      0.0.0.0:8500->8500/tcp
terminal   /opt/qnib/bin/start_superv ...   Up
➜  consul git:(master) ✗ docker exec -ti consul consul members
Node      Address          Status  Type    Build  Protocol  DC
consul    172.17.0.2:8301  alive   server  0.6.3  2         dc1
terminal  172.17.0.3:8301  alive   client  0.6.3  2         dc1
➜  consul git:(master) ✗

Each container runs its own consul agent. There is at least one running in server mode and the rest are just clients, to provide the localhost RESTful API and the DNS interface.

It could be modeled in a way where the DNS interface of a non-localhost container is used, but the model of having everything localhost is quite tempting as I do not have any external dependencies.

If I get it right, the problem here is that the embedded server is not in the namespace of the container, hence it can deal with external DNS servers easily (like 8.8.8.8), but dealing with 127.0.0.1 is not possible.
I am sure, that my need of a localhost DNS server is not unique. I talked about my stack (https://www.youtube.com/playlist?list=PLfE3_wJGw9KS3PBvqEcDdpiODeDjAs5v8) it encapsulates a given environment (stack conected to a distinct [docker] network) perfectly.

If I get the documentation right (https://docs.docker.com/engine/userguide/networking/configure-dns/), I might be able to workaround this issue, by providing 127.0.0.1 as a DNS server of the docker host and do not provide any DNS options. I'll check that out.
But if you could bring back a way to provide it as a runtime option, I would appreciate it, since it's essential to my plan forward.

[ChristianKniep]

I thought maybe I have an easy way out by providing the DNS server to the docker-engine: EXTRA_ARGS="--dns 127.0.0.1"

But it seems docker-compose v2 does not respect it as well. :(
EDIT: And if I want to use Docker networking I got now way out at all? So I have to downgrade to 1.9?

[mavenugo]

If I get it right, the problem here is that the embedded server is not in the namespace of the container, hence it can deal with external DNS servers easily (like 8.8.8.8), but dealing with 127.0.0.1 is not possible.

@ChristianKniep we recently merged moby/libnetwork#895. that will make its way to 1.11 docker release. I was still trying to understand the real use-case for --dns=127.0.0.1

BTW, the engine will honor the --dns flags in both daemon or container flags. But the question of what 127.0.0.1 mean (is it container namespace or host namespace) still exists...

[ChristianKniep]

By 127.0.0.1 I refer to the loopback address of the container itself. So the original title of the PR you point to (Retain 1.9 behavior when --dns IP is container's loopback) is very near and dear to my heart. :)

[mavenugo]

well ... we are looking at many use-cases and it is not clear on how to treat --dns=127.0.0.1 and is not documented as well. That is the problem with such virtual-IPs.

Regardless, I think we can propose an enhancement to compose for an ability to accept service-name to parameters such as --dns or -log so that applications need not hard-code these IPs and let the dynamic IPs be resolved by the service names.

[mavenugo]

@ChristianKniep btw. am trying to understand from your compose file on how qnib/alpn-terminal works to connect to the consul server ? By any chance do you depend on the /etc/hosts update to get the ip-address of the consul server ?