Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weave – The Docker Network

github.com

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Weave – The Docker Network

#61

Post by bboreham »

brazzledazzle wrote: post #54

Has anyone compared this to rudder ( https://coreos.com/blog/introducing-rudder/ )?

Rudder has a central configuration (via etcd); Weave communicates network changes across all nodes by itself - as long as each new node knows how to contact at least one other node, it will learn of all other nodes and connect to as many as it can.

Also Rudder is Layer 3 and Weave is Layer 2 and Weave can encrypt traffic.

Re: Weave – The Docker Network

#62

Post by weavenetwork »

brazzledazzle wrote: post #54

Has anyone compared this to rudder ( https://coreos.com/blog/introducing-rudder/ )?

The most significant conceptual difference is that in rudder sub-nets are tied to hosts. So containers on different hosts will always be on different sub-nets. By contrast, in weave containers belonging to the same application reside in the same sub-net, regardless of what host they are running on. In other words, weave makes the network topology fit the application topology, not the other way round.

Re: Weave – The Docker Network

#63

Post by wmf »

CMCDragonkai wrote: post #56
wmf wrote: post #49

Earlier quoted context omitted.

Snabb and DPDK aren't magic though. Because they poll you have to dedicate a whole core to the vSwitch. Containers are a different case than VMs because the packets start in the kernel TCP/IP stack; to get into a userspace vSwitch they'd have to exit the kernel.

So which would you prefer? Userspace or Kernel?

The kernel has a lot of accumulated network functionality that has already been optimized for performance (under certain assumptions). Let's use it.

Re: Weave – The Docker Network

#64

Post by sciurus »

nl wrote: post #60
sciurus wrote: post #36

Earlier quoted context omitted.

I don't see how Docker solves the speed problem without a workflow change that could already be accomplished with Vagrant. * Install your stack from scratch in 6 VMs: slow * Install your stack from scratch via 6 Dockerfilea: slow * Download prebuild vagrant boxes with your stack installed: faster * Download prebuilt docker images with your stack installed: fastest The main drawback of Vagrant is that afaik it has to…

Running 6 VMs has non-trivial overhead though. That just isn't there using containers.

I have to disagree, although I'll admit that what's "trivial" is subjective. Sure, a container means you don't have to run another kernel. If the container is single-purpose like docker encourages, you skip running some other software like ssh and syslog as well. That software doesn't use much CPU or memory though. I just booted Ubuntu 12.04 and it's using 53MB of memory. Multiplied across 6 VMs that's 318MB, not quite 4% of the 8GB my laptop has. I'd call that trivial.

On the last project where I had to regularly run many VMs on my laptop, the software being tested used more than 1GB. Calling it 1GB total per VM and sticking with the 53MB overhead, switching to containers would have reduced memory usage by 5%. Again, to my mind that's trivial.

Post reply on HN