gliderlabs / resolvable Goto Github PK

View Code? Open in Web Editor NEW

315.0 10.0 36.0 70 KB

Host-level DNS gateway for Docker

License: MIT License

Go 97.86% Shell 0.53% Makefile 1.61%

resolvable's Introduction

Resolvable - Docker DNS resolver

A simple DNS server to resolve names of local Docker containers.

resolvable is intended to run in a Docker container:

docker run -d \
	--hostname resolvable \
	-v /var/run/docker.sock:/tmp/docker.sock \
	-v /etc/resolv.conf:/tmp/resolv.conf \
	mgood/resolvable

The docker.sock is mounted to allow resolvable to listen for Docker events and automatically register containers.

resolvable can insert itself into the host's /etc/resolv.conf file by mounting this file to /tmp/resolv.conf in the container. When starting, it will insert itself as the first nameserver in the file, and remove itself when shutting down.

Systemd integration

On systems using systemd, resolvable can integrate with the systemd DNS configuration. Instead of mounting /etc/resolv.conf, mount the systemd configuration path /run/systemd and the DBUS socket as follows:

docker run -d \
	--hostname resolvable \
	-v /var/run/docker.sock:/tmp/docker.sock \
	-v /run/systemd:/tmp/systemd \
	-v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket \
	mgood/resolvable

resolvable will generate a systemd network config, and then use the DBUS socket to reload systemd-networkd to regenerate the host's /etc/resolv.conf.

Container Registration

resolvable provides DNS entries <hostname> and <name>.docker for each container. Containers are automatically registered when they start, and removed when they die.

For example, the following container would be available via DNS as myhost and myname.docker:

docker run -d \
	--hostname myhost \
	--name myname \
	mycontainer

DNS Forwarding

resolvable also supports forwarding DNS queries to other containers providing DNS servers. This integrates well with tools like Consul or SkyDNS that offer a DNS endpoint for service discovery.

Containers configured with the DNS_RESOLVES environment variable are registered in resolvable to forward DNS queries for any domains listed.

To run an example consul container, supporting DNS queries for the .consul domain on port 8600:

docker run -d \
	-e DNS_RESOLVES=consul \
	-e DNS_PORT=8600 \
	-p 8600/udp \
	consul

DNS_RESOLVES must contain least one domain to forward to this container. Multiple values can be provided as a comma-separated list.

DNS_PORT is optional, and defaults to 53.

Interface Addresses

resolvable also provides a DNS entry for the Docker bridge interface address, usually docker0. This can be used to communicate with services with a known port bound to the Docker bridge.

See this article on Docker network configuration for additional details on the Docker bridge interface.

resolvable's People

Contributors

Stargazers

Watchers

resolvable's Issues

No entry in resolv.conf

I am executing the following command on a MacOS:
docker run -d --hostname resolvable -v /var/run/docker.sock:/tmp/docker.sock -v /etc/resolv.conf:/tmp/resolv.conf mgood/resolvable

Thereafter my /etc/resolv.conf remains untouched.

Also tried to execute it with sudo but no success either.

PS: I noticed that something is regenerating /etc/resolv.conf as also manual edits disappear immediately.

use labels instead of environment

namely DNS_RESOLVES and DNS_PORT to become labels dns.resolves and dns.port.

Document reasons for use (eg, vs dnsmasq)

@progrium suggested using resolvable as an alternative to dnsmasq at gliderlabs/docker-alpine#8.

What prompted the creation of resolvable? Are there any downsides to using resolvable instead of dnsmasq?

option/env to configure host ip

https://github.com/mgood/resolvable/blob/master/main.go#L84

Unable to use dns search

I seem to be unable to use the DNS_RESOLVES variable to use the "dns search" functionality of resolvable.

After starting resolvable, this is the output I get:

resolvable_1 | 2015/07/18 20:35:11 systemd: disabled, cannot read /tmp/systemd: stat /tmp/systemd: no such file or directory
resolvable_1 | 2015/07/18 20:35:11 Starting resolvable 0.2 ...
resolvable_1 | 2015/07/18 20:35:11 got local address: 172.17.42.207
resolvable_1 | 2015/07/18 20:35:11 updating resolv.conf: /tmp/resolv.conf

Resolvable starts after the Consul container, which has -e DNS_RESOLVES=consul set. If I start a third container, and enter it, I can see the following:

% cat /etc/hosts
172.17.42.217   f0ca83d2d315
127.0.0.1   localhost
172.17.42.208   consul 9c4e27c17d50 dev_consul_1
172.17.42.208   consul_1 9c4e27c17d50 dev_consul_1
172.17.42.208   dev_consul_1 9c4e27c17d50
172.17.42.212   dev_registrator_1
172.17.42.212   dev_registrator_1.bridge
172.17.42.217   dev_r_run_1.bridge
172.17.42.207   dev_resolvable_1
172.17.42.217   dev_r_run_1
172.17.42.207   dev_resolvable_1.bridge
172.17.42.208   dev_consul_1
172.17.42.208   dev_consul_1.bridge

% cat /etc/resolv.conf 
nameserver 172.17.42.207 # added by resolvable

% ping consul.service.consul
PING consul.service.consul (172.17.42.208): 56 data bytes

% ping consul.service
ping: bad address 'consul.service'

Note: I was redirected to this tool from gliderlabs/docker-alpine#8. I already had DNS querying solved using the FQDN, but I was hoping the use of resolvable would help me use dns search to simplify the domains.

[Question] ROS networking

Hello resolvable devs,

I've got a question for you: what is it about using resolvable that is perhaps "resolving" a docker networking issue that we've been having the the ROS community. I've made a gist describing the possible fix, and a question on ros.answers, but I'd like to invite you to inform us of what subtle nuance I may be missing.

Thanks!

--net=host causes loop?

I have many services under --net=host, but this appears in the logs continuously:

2015/12/07 20:18:10 error adding container a3fac3a90373: IP not available with network mode "host"
2015/12/07 20:18:11 error adding container a3fac3a90373: IP not available with network mode "host"
2015/12/07 20:18:13 error adding container ea440bf54b63: IP not available with network mode "host"
2015/12/07 20:18:13 error adding container ea440bf54b63: IP not available with network mode "host"
2015/12/07 20:18:15 error adding container 8d302b8d7e89: IP not available with network mode "host"
2015/12/07 20:18:15 error adding container 8d302b8d7e89: IP not available with network mode "host"
2015/12/07 20:18:20 error adding container c93085880387: IP not available with network mode "host"

Anyway for it just to ignore those ? So it can take less resources?

support service records?

thoughts on supporting service records?

Respect the domainname if set

Currently the domainname is ignored, if the hostname should be resolvable as 'hostname.docker' one needs to set the hostname to 'hostname.docker' and the domainname to 'docker'.

Example config:

        "Hostname": "host",
        "Domainname": "docker",

Currently needed workaround:

        "Hostname": "host.docker",
        "Domainname": "docker",

[readme] Add recommendation to bind host's resolv.conf

When containers started BEFORE resolvable starts, those are unable to resolve .docker domains via Resolvable because the Docker daemon uses an old copy of the resolv.conf

If I use the -v /etc/resolv.conf:/etc/resolv.conf:ro to all my docker run command and docker-compose definition, it seems to resolve this issue.

This issue potentially occur when the Docker daemon starts and you use many auto-restarting container where the containers starting in random order.

Support for systemd-resolve

This image uses systemd-networkd to regenerate the host's /etc/resolv.conf. However, on Ubuntu 20.04-based systems resolv.conf is linked to ../run/systemd/resolve/stub-resolv.conf which hints to the use of systemd-resolve service.

This causes error as /tmp/systemd/network is not present.

$ docker run  --hostname resolvable -v /var/run/docker.sock:/tmp/docker.sock -v /run/systemd:/tmp/systemd   -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket  mgood/resolvable

2021/01/05 00:59:19 Starting resolvable 0.2 ...
2021/01/05 00:59:19 got local address: 172.17.0.2
2021/01/05 00:59:19 systemd: systemd-resolved.service: loading config from /config/systemd/resolved.conf.d/*.conf
2021/01/05 00:59:19 systemd: template: pattern matches no files: `/config/systemd/resolved.conf.d/*.conf`
2021/01/05 00:59:19 systemd: systemd-networkd.service: loading config from /config/systemd/network/*.network
2021/01/05 00:59:19 systemd: generating /tmp/systemd/network/99-resolvable.network
2021/01/05 00:59:19 systemd: open /tmp/systemd/network/99-resolvable.network: no such file or directory
2021/01/05 00:59:19 systemd: %s: no configs written, skipping reload systemd-networkd.service

resolvable entry disappears from resolv.conf

I've seen this behavior on Ubuntu and Boot2Docker, after a period of time (resolvable is still running) the nameserver for resolvable disappears from resolv.conf and it does not come back.

nameserver resolv.conf format is invalid on alpine linux

nameserver IP # comment

this is invalid on alpine linux, the comment makes it so that nameserver isn't used

I'm getting DNS_PROBE_FINISHED_BAD_CONFIG after start resolvable container

After get DNS_PROBE_FINISHED_BAD_CONFIG. I need stop resolvable to my DNS work again.

Run resolvable container:

docker run -d \
    --name resolvable \
    --hostname resolvable \
    -v /var/run/docker.sock:/tmp/docker.sock \
    -v /run/systemd:/tmp/systemd \
    -v /run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket \
    mgood/resolvable

Create a container test:

erick.cirrus@pat01550 ~/testedocker $ docker rm -f teste; docker run -it --name teste ubuntu bash
teste
root@ba0ee56c01bf:/#

Ping to new container.

pat01550 testedocker # ping teste.docker
PING teste.docker (172.17.0.3) 56(84) bytes of data.
64 bytes from 49f7ec106ff3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from 49f7ec106ff3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 49f7ec106ff3 (172.17.0.3): icmp_seq=3 ttl=64 time=0.036 ms
64 bytes from 49f7ec106ff3 (172.17.0.3): icmp_seq=4 ttl=64 time=0.068 ms
64 bytes from 49f7ec106ff3 (172.17.0.3): icmp_seq=5 ttl=64 time=0.056 ms
^C
--- teste.docker ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.036/0.057/0.083/0.019 ms

Provide a way to add more than two names for one docker container

First of all: Great tool! Thanks to all developers!

If I'm reading the docs correctly, there are currently two docker params that will cause gliderlabs/resolvable to add resolvable names on the host: --name and --hostname

What about applications that require more than two domain names? (For example, if the application's behaviour depends on the domain name with which it has been called.)

I currently resort to manually calling a makeshift script, that writes a docker's IP address to /etc/hosts. But is there any way to do this automatically with gliderlabs/resolvable instead? - That would be a lot neater!

Support multiple servers per-domain

At least when recursing for servers defined in resolv.conf, it should support multiple upstream servers. Right now it only expects one DNS server per domain suffix.

emulate search domain

We should read in the search domain option of resolv.conf, as well as let it be configured, to then emulate search domain behavior if a domain is provided. This way resolvable "patches" this missing feature of Alpine that musl developers I hear aren't too keen on fixing.

Google.com and others stop resolving

On some of my servers, resolvable works fine, and others, it stops resolving to external TLDs when the resolv.conf file is prepended.

Config recommendations for resolvconf

The documentation should provide more information on how to work with the "resolvconf" tool used to generate "resolv.conf".

This should include the options to bind-mount the proper config file, and how to trigger the "resolvconf" tool on the Docker host after "resolvable" has started.

resolvable should support Docker networks

I am attempting to use resolvable as a DNS resolver on my local host node (ie, developer workflow) so that I can access my docker containers by name (specifically looking to use the containter's hostname/container id/name).

however it appears that resolvable doesn't support docker networks:

2016/12/30 12:34:59 got local address: 172.17.0.2
2016/12/30 12:34:59 error adding container 5cc92799c26a: unknown network mode%!(EXTRA string=stormdocker_default)
2016/12/30 12:34:59 error adding container a9bf59ad937d: unknown network mode%!(EXTRA string=stormdocker_default)
2016/12/30 12:34:59 error adding container 9ca9b1a6ffb0: unknown network mode%!(EXTRA string=stormdocker_default)
2016/12/30 12:34:59 error adding container 0c69b5e8fe5c: unknown network mode%!(EXTRA string=stormdocker_default)

#15 seems to reference this same issue, but mentions that if networks need to be supported then a new issue should be created specifically for that. so, here it is.

systemd-networkd / dhcp being stopped by resolvable

I'm trying to run resolvable on CoreOS and AWS but my instances are losing their network connectivity periodically. I have narrowed it down to resolvable and that the machines with resolvable running don't have systemd-networkd running and when resolvable is not run systemd-networkd remains working.

I'm starting resolvable in a docker container with -e DNS_RESOLVES="8.8.8.8,8.8.4.4" -v /var/run/docker.sock:/tmp/docker.sock -v /run/systemd:/tmp/systemd -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket gliderlabs/resolvable:master

Obviously AWS is running with a DHCP network not static IPs. It seems that unless I explicit add a network unit (like the one below, coreos doesn't have any by default) resolvable will effectively shutdown systemd-networkd which could be causing my issues (I'm still testing with the extra network unit).

[Match]
Name=eth*

[Network]
DHCP=ipv4