CODEWITHSUNDEEP
dockerdocker-compose
thwint
thwint

Reputation: 303

docker-compose does not update resolv.conf

I have the following simplified docker-compose file:

version: '2'
services:
    test.base:
        container_name: test.base
        image: docker.pnet.ch/r-base:latest
        restart: on-failure
        networks:
            - mynet
        dns: 192.168.198.2
        dns_search:
            - pext.ch
            - pnet.ch
networks:
    mynet:
        driver: bridge
        driver_opts:
            com.docker.network.enable_ipv4: "true"
        ipam:
            driver: default
            config:
                - subnet: 192.168.198.0/24
                  gateway: 192.168.198.1

With this I expect to have the following entries in the containers /etc/resolv.conf:

search pext.ch pnet.ch
nameserver 192.168.198.2

But instead I have the following:

search pext.ch pnet.ch
nameserver 127.0.0.11
options ndots:0

When I manually start the container using docker run with --dns 192.168.199.2 /etc/resolv.conf contains a nameserver with the given ip address.

Is there anything wrong with my docker-compose file or is it a bug in docker-compose?

I'm using docker version 1.10.3 on RHEL and docker-compose 1.9.0

Upvotes: 14

Views: 23884

Answers (4)

Aurelio Vivas
Aurelio Vivas

Reputation: 86

I was running the ubuntu version of docker holded in this respository (docker.io 18.06.0). I removed that version an install docker.io using apt-get install docker.io. So now I have this version:

Client:
Version:    17.12.1-ce
API version:    1.35
Go version: go1.10.1
Git commit: 7390fc6
Built:  Wed Apr 18 01:23:11 2018
OS/Arch:    linux/amd64

Server:
Engine:
Version:    17.12.1-ce
API version:    1.35 (minimum version 1.12)
Go version: go1.10.1
Git commit: 7390fc6
Built:  Wed Feb 28 17:46:05 2018
OS/Arch:    linux/amd64
Experimental:   false

Containers running with docker-compose don't have the file resolv.conf with the dns configured as expected, but each container can access the Internet. I think that change solve my problem.

Upvotes: 0

lucidyan
lucidyan

Reputation: 3893

As pointed earlier resolv.conf does not change for quite certain reasons, so I found dirty hack for docker-compose: changing resolv.conf inplace during docker build.

You should make file changes in the beginning of your command and it remain unchanged until it end.

Like this:

RUN echo "nameserver 10.100.1.13" > /etc/resolv.conf && apt update

I know this is far from good coding practices, but I think it's more elegant, than mounting /etc/resolf.conf from outer world.

Upvotes: 0

Frank Wong
Frank Wong

Reputation: 1826

I used volumes: to work around this problem. In your case:

version: '2'
services:
    test.base:
        container_name: test.base
        image: docker.pnet.ch/r-base:latest
        restart: on-failure
        networks:
            - mynet
        volumes:
            - ./resolv.conf:/etc/resolv.conf

Where the ./resolv.conf file contains what exactly you expected as:

search pext.ch pnet.ch
nameserver 192.168.198.2

Here assumes the resolv.conf file is on the same folder as your docker-compose file.

Upvotes: 13

charli
charli

Reputation: 1778

Networking in Docker Compose file format v2 it's different from version 1, and I think that's the actual problem. It's also confusing that a docker run ... command works while the docker-compose ... don't. I experienced the same issue.

What I found is that Docker Compose v2 creates a user-defined network for the containers defined in the docker-compose.yml file, whereas docker run ... by default uses the bridged network, named docker0 on the host. Also, with custom networks docker uses an embedded DNS server (that's the 127.0.0.11). The docs say:

The IP addresses passed via the --dns option is used by the embedded DNS server to forward the DNS query if embedded DNS server is unable to resolve a name resolution request from the containers. These --dns IP addresses are managed by the embedded DNS server and will not be updated in the container's /etc/resolv.conf file.

I think the last line answers your question. Anyway, your container should be resolving correctly, doesn't it?

Upvotes: 10

Related Questions