starred/dns-proxy-server-mageddo

Fork 0

mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-25 09:25:56 +03:00

[GH-ISSUE #80] Compose not supported with latest docker #36

New issue

Closed

opened 2026-02-26 04:33:50 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 04:33:50 +03:00

Owner

Originally created by @gliviu on GitHub (Jul 8, 2018).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/80

According to this answer and #70, DPS seem to have worked for containers started from docker compose.
Tried with docker version 18.03 and id din't work.

I used the compose file from SO answer.

version: '3'
services:
  redis:
    image: redis:2.8
    hostname: redis.dev.intranet
  elasticsearch:
    image: elasticsearch:2.2
    hostname: elasticsearch.dev.intranet

Started DPS with docker run --rm --hostname dns.mageddo --na....

Then

> docker stack deploy -c compose.yaml dps_stack
Creating network dps_stack_default
Creating service dps_stack_elasticsearch
Creating service dps_stack_redis

> nslookup redis.dev.intranet
Server:         172.17.0.2
Address:        172.17.0.2#53

Non-authoritative answer:
Name:   redis.dev.intranet
Address: 10.0.0.4

> ping redis.dev.intranet
PING redis.dev.intranet (10.0.0.4) 56(84) bytes of data.
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

Tried with docker run instead of compose and DPS correctly uses '172.17..' network.

Specs:

OS: inux liviu 4.13.0-45-generic #50~16.04.1-Ubuntu SMP
Docker Version: 18.03.1-ce, build 9ee9f40
DPS Version: 2.5.4
Logs: dps_stack.log

Originally created by @gliviu on GitHub (Jul 8, 2018). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/80 According to [this answer](https://stackoverflow.com/a/45071126) and #70, DPS seem to have worked for containers started from docker compose. Tried with docker version 18.03 and id din't work. I used the compose file from SO answer. ``` version: '3' services: redis: image: redis:2.8 hostname: redis.dev.intranet elasticsearch: image: elasticsearch:2.2 hostname: elasticsearch.dev.intranet ``` Started DPS with `docker run --rm --hostname dns.mageddo --na...`. Then ```bash > docker stack deploy -c compose.yaml dps_stack Creating network dps_stack_default Creating service dps_stack_elasticsearch Creating service dps_stack_redis > nslookup redis.dev.intranet Server: 172.17.0.2 Address: 172.17.0.2#53 Non-authoritative answer: Name: redis.dev.intranet Address: 10.0.0.4 > ping redis.dev.intranet PING redis.dev.intranet (10.0.0.4) 56(84) bytes of data. 2 packets transmitted, 0 received, 100% packet loss, time 1007ms ``` Tried with `docker run` instead of compose and DPS correctly uses '172.17..' network. **Specs:** - OS: `inux liviu 4.13.0-45-generic #50~16.04.1-Ubuntu SMP` - Docker Version: `18.03.1-ce, build 9ee9f40` - DPS Version: `2.5.4` - Logs: [dps_stack.log](https://github.com/mageddo/dns-proxy-server/files/2173747/dps_stack.log)

kerem

2026-02-26 04:33:50 +03:00

closed this issue
added the
discussion
label

kerem commented

2026-02-26 04:33:51 +03:00

Author

Owner

@mageddo commented on GitHub (Jul 8, 2018):

Thank you for your great question.

The main point here is that the containers (redis, elasticsearch) are running at different networks than dns-proxy-server so dns-proxy-server have not firewall permissions to talk with them, this is a docker premise

To make it work you'll have to put then on same network, as I see you are using docker stack deploy, if you use docker-compose up you can put them on same network by adding network_mode option

version: '3'
services:
  server-01:
    image: alpine:3.7
    hostname: server-01.intranet
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
   network_mode: bridge
  server-02:
    image: alpine:3.7
    hostname: server-02.intranet
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    network_mode: bridge

To make it work with docker stack deploy you'll have to use networks option (it works for docker-compose as well)

Creating a common network

docker network create --attachable --driver overlay github

Running DPS at just created network

docker run --rm --hostname dns.mageddo --name dns-proxy-server \
  --network github \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc/resolv.conf:/etc/resolv.conf \
  defreitas/dns-proxy-server

version: '3'
services:
  server-01:
    image: alpine:3.7
    hostname: server-01.intranet
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    networks:
      - github
  server-02:
    image: alpine:3.7
    hostname: server-02.intranet
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    networks:
      - github

networks:
  github:
    external: true

Then it should work, note that create a external network is necessary since all containers must ran at same network and DPS was started without docker stack deploy

If you don't want to manually create an external network then you will have to start DPS at the same stack file that way docker will create a network for that deploy and assign all those containers at same network

version: '3'
services:
  dps:
    image: defreitas/dns-proxy-server
    hostname: dns.mageddo
    volumes:
      - /etc/resolv.conf:/etc/resolv.conf
      - /var/run/docker.sock:/var/run/docker.sock
  server-01:
    image: alpine:3.7
    hostname: server-01.intranet
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    volumes:
      - /etc/resolv.conf:/etc/resolv.conf
  server-02:
    image: alpine:3.7
    hostname: server-02.intranet
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    volumes:
      - /etc/resolv.conf:/etc/resolv.conf

The drawback is that you will have to volume resolv.conf to have sure others containers will bind it correctly

Observation
Not related to your question but as you are using docker stack deploy then you are using docker swarm, you must be aware DPS will solve just containers started at the current machine, it will not solve containers from others cluster nodes.

PS: I used alpine container because is more lite to pull and start.

UPDATE Must run DPS specifying network at example 2

@mageddo commented on GitHub (Jul 8, 2018): Thank you for your great question. The main point here is that the containers (redis, elasticsearch) are running at different networks than dns-proxy-server so dns-proxy-server have not firewall permissions to talk with them, this is a docker premise To make it work you'll have to put then on same network, as I see you are using `docker stack deploy`, if you use `docker-compose up` you can put them on same network by adding `network_mode` option ```yaml version: '3' services: server-01: image: alpine:3.7 hostname: server-01.intranet command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' network_mode: bridge server-02: image: alpine:3.7 hostname: server-02.intranet command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' network_mode: bridge ``` To make it work with `docker stack deploy` you'll have to use `networks` option (it works for docker-compose as well) Creating a common network ``` docker network create --attachable --driver overlay github ``` Running DPS at just created network ``` docker run --rm --hostname dns.mageddo --name dns-proxy-server \ --network github \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/resolv.conf:/etc/resolv.conf \ defreitas/dns-proxy-server ``` ```yaml version: '3' services: server-01: image: alpine:3.7 hostname: server-01.intranet command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' networks: - github server-02: image: alpine:3.7 hostname: server-02.intranet command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' networks: - github networks: github: external: true ``` Then it should work, note that create a external network is necessary since all containers must ran at same network and DPS was started without docker stack deploy If you don't want to manually create an external network then you will have to start DPS at the same stack file that way docker will create a network for that deploy and assign all those containers at same network ```yaml version: '3' services: dps: image: defreitas/dns-proxy-server hostname: dns.mageddo volumes: - /etc/resolv.conf:/etc/resolv.conf - /var/run/docker.sock:/var/run/docker.sock server-01: image: alpine:3.7 hostname: server-01.intranet command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' volumes: - /etc/resolv.conf:/etc/resolv.conf server-02: image: alpine:3.7 hostname: server-02.intranet command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' volumes: - /etc/resolv.conf:/etc/resolv.conf ``` The drawback is that you will have to volume resolv.conf to have sure others containers will bind it correctly **Observation** Not related to your question but as you are using `docker stack deploy` then you are using `docker swarm`, you must be aware `DPS` will solve just containers started at the current machine, it will not solve containers from others cluster nodes. **PS:** I used alpine container because is more lite to pull and start. **UPDATE** Must run DPS specifying network at example 2

kerem commented

2026-02-26 04:33:51 +03:00

Author

Owner

@gliviu commented on GitHub (Jul 9, 2018):

Thanks for the quick answer. I'll check and get back with results.

@gliviu commented on GitHub (Jul 9, 2018): Thanks for the quick answer. I'll check and get back with results.

kerem commented

2026-02-26 04:33:51 +03:00

Author

Owner

@gliviu commented on GitHub (Jul 11, 2018):

Using docker-compose works as expected which should be enough for developer machines.
Didn't manage to make it work using stack deploy.
My docker network inspect github:

        "Containers": {
            "9db3d4c7876c6dbe720f29ee37530b1f549edb0db0e13f25939ba0b2adc10a6d": {
                "Name": "ds_server-01.1.sj1k887ignu1i7qfujmhw7osg",
                "EndpointID": "e21e64602839e0652ea6b856feb1b25539e56de9e963444790851083b2711877",
                "MacAddress": "02:42:0a:00:00:05",
                "IPv4Address": "10.0.0.5/24",
                "IPv6Address": ""
            },
            "a7c86a08351c50d09cfc4662db5b2b6c5941dfa898a3cfb7825b25fe62c1a669": {
                "Name": "dns-proxy-server",
                "EndpointID": "6969623d441e8781e7a1e918176cb2c4000360ab95482f662e2cc8775db0843c",
                "MacAddress": "02:42:0a:00:00:03",
                "IPv4Address": "10.0.0.3/24",
                "IPv6Address": ""
            },
            "e20d75174f3293c10bb86e81c9b0a7c4133427ab2373855315a836c14b2a85f3": {
                "Name": "ds_server-02.1.r2g3jbkvd1lo5ak086vltx7dn",
                "EndpointID": "d4517ef443a913d8e26e9443783e0ae300af531956b3244d3dc555d72bec98b9",
                "MacAddress": "02:42:0a:00:00:07",
                "IPv4Address": "10.0.0.7/24",
                "IPv6Address": ""
            }
        }

And /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# nameserver 127.0.1.1 # dps-comment
nameserver 10.0.0.3 # dps-entry

And I can't even ping 10.0.0.3 from my host machine.

However since docker-compose solution works fine I suppose we can safely close this issue.

@gliviu commented on GitHub (Jul 11, 2018): Using `docker-compose` works as expected which should be enough for developer machines. Didn't manage to make it work using stack deploy. My `docker network inspect github`: ``` "Containers": { "9db3d4c7876c6dbe720f29ee37530b1f549edb0db0e13f25939ba0b2adc10a6d": { "Name": "ds_server-01.1.sj1k887ignu1i7qfujmhw7osg", "EndpointID": "e21e64602839e0652ea6b856feb1b25539e56de9e963444790851083b2711877", "MacAddress": "02:42:0a:00:00:05", "IPv4Address": "10.0.0.5/24", "IPv6Address": "" }, "a7c86a08351c50d09cfc4662db5b2b6c5941dfa898a3cfb7825b25fe62c1a669": { "Name": "dns-proxy-server", "EndpointID": "6969623d441e8781e7a1e918176cb2c4000360ab95482f662e2cc8775db0843c", "MacAddress": "02:42:0a:00:00:03", "IPv4Address": "10.0.0.3/24", "IPv6Address": "" }, "e20d75174f3293c10bb86e81c9b0a7c4133427ab2373855315a836c14b2a85f3": { "Name": "ds_server-02.1.r2g3jbkvd1lo5ak086vltx7dn", "EndpointID": "d4517ef443a913d8e26e9443783e0ae300af531956b3244d3dc555d72bec98b9", "MacAddress": "02:42:0a:00:00:07", "IPv4Address": "10.0.0.7/24", "IPv6Address": "" } } ``` And `/etc/resolv.conf` ``` # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # nameserver 127.0.1.1 # dps-comment nameserver 10.0.0.3 # dps-entry ``` And I can't even ping 10.0.0.3 from my host machine. However since `docker-compose` solution works fine I suppose we can safely close this issue.

kerem commented

2026-02-26 04:33:51 +03:00

Author

Owner

@mageddo commented on GitHub (Jul 11, 2018):

Did you try all of the examples I've presented and none of them worked with docker stack?

@mageddo commented on GitHub (Jul 11, 2018): Did you try all of the examples I've presented and none of them worked with docker stack?

kerem commented

2026-02-26 04:33:51 +03:00

Author

Owner

@gliviu commented on GitHub (Jul 11, 2018):

Yes, I've tested both the above examples with docker stack. Although the first example uses network_mode: bridge which is ignored for swarm deploys according to spec.

@gliviu commented on GitHub (Jul 11, 2018): Yes, I've tested both the above examples with docker stack. Although the first example uses `network_mode: bridge` which is ignored for swarm deploys according to [spec](https://docs.docker.com/compose/compose-file/#network_mode).

kerem commented

2026-02-26 04:33:51 +03:00

Author

Owner

@mageddo commented on GitHub (Jul 11, 2018):

All right, the first one is expected to not work with docker stack, the others are. Thank you for your feedback. Then I'm closing this issue

@mageddo commented on GitHub (Jul 11, 2018): All right, the first one is expected to not work with `docker stack`, the others are. Thank you for your feedback. Then I'm closing this issue

kerem referenced this issue

2026-02-26 04:34:34 +03:00

[PR #36] [MERGED] removing travis branch #235