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:
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.
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.
> 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.
15 comments
[ 2.9 ms ] story [ 41.7 ms ] threadWeave - 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.
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.
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.