Have You Met weaveDNS?
Today we’re releasing a preview of weaveDNS: a distributed DNS service for your weave network. As with DNS in general, the main use of weaveDNS is to be able to refer to things by name rather than address. For instance, a database...
Today we’re releasing a preview of weaveDNS: a distributed DNS service for your weave network. As with DNS in general, the main use of weaveDNS is to be able to refer to things by name rather than address. For instance, a database container can be named "postgres", so your application code can find it without having a hard-coded or injected IP address.
In a nutshell
You will first need to re-up your weave script, per the weave README.
$ sudo weave launch $ sudo weave launch-dns 10.1.0.3/16 $ sudo weave run 10.1.1.25/24 -ti -h shell.weave.local debian /bin/bash $ SHELL2=$(sudo weave run 10.1.1.26/24 -ti -h shell2.weave.local debian /bin/bash) $ docker attach $SHELL2 # ping shell
(You can substitute ubuntu, or indeed just about anything, for debian)
More information on running weaveDNS is given in its README.
How it works
Any container you attach to the weave network can be given a name: this is done simply by giving the container a hostname in the domain .weave.local. The weaveDNS server runs in a container on each host, and accepts queries on the host network. Containers that are run with weave run ... are given the local weaveDNS container’s IP address as a DNS server. Meanwhile, any container given a weave IP address and hostname will be registered with the local weaveDNS. For any query of a name in weave.local, weaveDNS looks to see if the name is known to it; if not, it asks the other weaveDNS servers, over the weave network, if the name is known to them. For anything outside the weave.local domain, the server will ask its fallback DNS server (which is probably the host’s DNS server).
Subdomains and search paths
By default, name resolution will look for unqualified names (e.g., "postgres") in the container’s domain; so, in general you will be able to use unqualified names in your application and expect things to work. You can also exploit this to partition your names, by putting things in subdomains of weave.local; for example, postgres.app1.weave.local.
How weaveDNS is different
There are already tools for service discovery, with or without Docker: etcd, SkyDNS and Consul, for example. weaveDNS is broadly similar to these (though somewhat younger), but has a different outlook, I would say. There’s three main points of difference:
1. weaveDNS needs little to no configuration.
weaveDNS picks up what it needs from the Docker configuration; or you can drive it from your own source of configuration. It does the minimum needed to keep its records straight, like watching for containers dying, but will let you change things on a more fine-grained level too.
2. weaveDNS avoids costly synchronisation.
Consul and etcd (and thereby SkyDNS) use a consensus protocol, Raft, so that all nodes agree on state synchronously. We think that this is unnecessary for the purpose of discovery, since synchronously agreed stale information is no better than any other kind of stale information, and probably slower. You may want consensus for other purposes of course! weaveDNS is cool with that.
3. weaveDNS works with unmodified applications.
Because having a weave network essentially means no more port-shuffling shenanigans, you don’t usually need to look up a port for a service, or resort to proxying – weaveDNS concentrates on matching names to IPs in the tried and tested way, and doesn’t ask you to use a special client API or SRV records.
The status of weaveDNS
This really is a preview – it’s pretty minimal, the simplest things that works, and far from battle-tested. We’re releasing it to elicit feedback, so please do comment below, email us at weave@zett.io, tweet @weavenetwork, or talk to us on #weavenetwork. Among its current limitations:
- weaveDNS uses weave’s UDP multicast to solicit answers from other servers when it doesn’t know a name. This probably won’t scale up very far, so we’re looking at other ways of doing that;
- It’s far from a complete implementation of a DNS server — we don’t support recursive queries, or caching, for example. Caching is likely to be essential for most production deployments.
There are some features that we are still feeling our way through, as well. For instance, should we always give the first answer we find back to queries, or all answers (within some bound)? Do we need to prevent duplicates, or could they be a way to load-balance? And so on. Here too your comments and ideas are very welcome.
