WeaveDNS – A distributed DNS service for a weave network | Hacker News Reader

WeaveDNS – A distributed DNS service for a weave network

weaveblog.com

43 pointsweavenetwork15 comments

Great work! I was exploring the distributed docker networking space yesterday for an open source project I'm working on (https://github.com/pnegahdar/sporedock) and the ones I have currently found are:

Weave - https://github.com/zettio/weave

Ambassadord - https://github.com/progrium/ambassadord

Warmhole - https://github.com/vishvananda/wormhole

QTunnel (not docker specific) - https://github.com/getqujing/qtunnel

Flannel - https://github.com/coreos/flannel

I'd love a comparison write up if you guys ever get to it.

As far as flannel goes, the comparison can be boiled down to that Weave doesn't rely on etcd or anything other to store the sate.

Weave is also topology agnostic - see the explanation vs Flannel (formerly "Rudder") here http://www.infoworld.com/article/2608941/application-virtual...

Another one for your list:

https://github.com/zerotier/ZeroTierOne

Docker integration by a third party user: https://github.com/davide/docker-zerotier

ZeroTier isn't Docker-specific, but people are using it there.

(Disclosure: I wrote it.)

No DNS-like component (yet), though it's possible to use mDNS/Avahi or other existing methods. Seems like DNS+Docker wants an orthogonal solution, maybe something built into Docker itself or otherwise transport-agnostic. I can imagine deployments with multiple different kinds of transports running to connect Docker containers to different sorts of things.

The mDNS protocol tries to solve this problem in a more universal platform-independent way, but in my experience it isn't that reliable and doesn't scale well enough for mission-critical infrastructure use. Maybe the right thing to do would be to fix mDNS by changing it over to a Kademelia DHT or something else more intelligent, scalable, and closed-form-provably correct.

Weave is not Docker-specific either.

we are hiring ;-)

Throwing our hat to the ring: http://docknet.io (vxlan overlays for Docker)

> 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;

Does weaveDNS's use of UDP multicast go beyond simply finding other Weave nodes? i.e. Weave can discover other nodes via UDP multicast but you can also tell it addresses of other nodes if for instance, you are running in an environment that doesn't have UDP multicast available. I'm wondering if this same workaround can be used for weaveDNS.

The weave environment always constructs a network between the nodes that supports multicast.

I'm disappointed to see Weave adding features instead of fixing the foundation. Userspace encapsulation is garbage; it's both slower and more work than using the kernel's built-in encapsulation.

Today it's becoming harder and harder if users have to make sure that feature X is enabled in kernel version N or even compile and load a module. I do not disagree that your suggestion would benefit the performance.

@wmf, with respect, it's not garbage and actually works well for many cases. At the same time, it is quite possible to see ways to integrate weave with kernel features! We welcome your input and help on that -- why not get in touch? weave@zett.io

You make it sound like achieving what weave does would be straightforward with the existing in-kernel encapsulation mechanisms. That's not the case. Even if putting some parts in the kernel would make sense in the long term, getting it right in userspace first is not a ridiculous idea.

Why not just use http://en.wikipedia.org/wiki/Multicast_DNS and Avahi?

One thing that would require is either run Avahi deamon in each container or embed it in you application somehow.

Reply on news.ycombinator.com