DNS resolution does not work for built services in docker-compose.

[derekssmith]

I have a docker compose file that is a mix of image based services and built services (using build). When I run the docker-compose up on my Ubuntu linux box everything works properly. However running docker-compose up on my WIndows 10 box my built services can't perform name resolution to the image based services.

Expected behavior

I have a Zookeeper (zoo1) service, Kafka (streams1), and my application (ingest1). zoo1 and streams1 are services configured with images. When they start up they communicate just fine with each other. I expect that when I start up ingest1 it will be able to resolve the address of zoo1 properly.

Actual behavior

On Docker for Windows, the ingest1 box gets an invalid IP address for zoo1.

Information

Here is my docker-compose.yml file:

version: '2'
services:
    zoo1:
        image: xxxxx/zookeeper-test
        ports:
            - "2181:2181"
    streams1:
        image: xxxxxxx/kafka
        ports:
            - "9092:9092"
            - "9010:9010"
        links:
            - zoo1
        environment:
            KAFKA_ZOOKEEPER_CONNECT: "zoo1:2181"
            KAFKA_ADVERTISED_HOST_NAME: "streams1"
            KAFKA_ADVERTISED_PORT: "9092"
            KAFKA_CREATE_TOPICS: "pipeline:1:1,logs:1:1"
            JMX_PORT: "9010"

    ingest1:
        build: 
            context: .
            dockerfile: ./pipeline/stages/ingestion/Dockerfile
        ports:
            - "8080:8080"
        links: 
            - zoo1
            - streams1
        environment:
            ZOOKEEPER_CONNECT: "zoo1:2181"
        restart: "on-failure:10"

Here is part of the output of docker network insepct for my network:

    {
        "Name": "naveego_default",
        "Id": "14d50fc7702025cb6e8d79f390d224d02f3b5bf6070bb572bc344c11637bd083",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1/16"
                }
            ]
        },
        "Internal": false,

This is the log file from ingest1:

ingest1_1       | time="2016-08-22T00:43:23Z" level=debug msg="Connecting to configuration servers: zoo1:2181"
ingest1_1       | 2016/08/22 00:43:25 Failed to connect to 198.105.254.24:2181: dial tcp 198.105.254.24:2181: i/o timeout
ingest1_1       | 2016/08/22 00:43:26 Failed to connect to 198.105.244.24:2181: dial tcp 198.105.244.24:2181: i/o timeout
ingest1_1       | time="2016-08-22T00:43:26Z" level=fatal msg="Error reading configurationzk: could not connect to a server"

I should be getting an address in the same network (i.e. 172.18.0.x).

Note: I have another container that is being built in the file and I get the same result.

Why aren't my built services able to use name resolution?

[rn]

@derekssmith We have several compose tests which are run regular and most of them use the service name and they all pass. However, I don't think we have one where we pass the service name as part of the environment.

@friism could you take a look and maybe work with @derekssmith on an simpler repro?

[derekssmith]

To provide some more information on this. If I manually configure a network, and then provide "extra_hosts" to map the names to the IP addresses. It works.

I added this network configuration:

networks:
    internal:
        driver: bridge
        driver_opts:
            com.docker.network.enable_ipv6: "false"
        ipam:
            driver: default
            config:
                - subnet: 10.1.1.0/24
                  gateway: 10.1.1.1

I gave each of my services a manual ipv4_address. Then uses extra_hosts like this:

extra_hosts:
            - "zoo1:10.1.1.10"

NOTE: I only have to do this on the services that are built by docker-compose. The image services work as expected.

[friism]

@derekssmith can you post output of docker version and docker-compose version please?

As Rolf mentioned, it be great if you could help narrow down the problem with a simpler repro or alternatively provide a repro that I can run with public images and/or a public project.

[derekssmith]

Here are the versions:

docker version

Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:15:28 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:15:28 2016
 OS/Arch:      linux/amd64

docker-compose version

docker-compose version 1.8.0, build d988a55
docker-py version: 1.9.0
CPython version: 2.7.11
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015

I will see if I can put a simple script together that will recreate the issue.

[rn]

could you retry with Beta27 which we released today. with recent Beta's there have been a lot of improvements around DNS resolutions.
thanks

[derekssmith]

I installed Beta27 however I was not able to confirm the fix. Running docker-compose up sent the build process into an infinite loop, where it kept re-building two of my docker images over and over again.

[derekssmith]

I just tried again with the 1.12.3 release and it appears to be working. So whatever issue I was having before has been fixed in the latest stable release.

[rn]

Thanks for getting back. The update had both compose and core engine updates, so maybe one of them did the trick. Glad that it's working for you and I'm closing the issue

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked