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

51–60 of 65 posts

Re: Weave – The Docker Network

#51

Post by St-Clock »

jfoutz wrote: post #43
St-Clock wrote: post #22

Earlier quoted context omitted.

I have yet to see real, complex, and distributed applications that share the exact same config in dev and production. I know that having the same versions of system libs in dev and prod can be a problem in some context and docker can help with that, but it's not the only solution and does not take care of the whole landscape (e.g., npm packages.json, pip requirements.txt, etc.). I totally agree that startup time of a…

First, I'm a dilettante. I haven't used docker in production. I've really only set up a handful of containers. That said, all of those fiddly library dependencies are where i struggle the most at work. If i could just build a docker image and hand that off, it would save me a lot of grief with regard to getting deployment machines just right. I do have a great deal of experience with legacy environments, and it seems…

I hear you about legacy systems. Two years ago, I had to support a Python 2.4 system that used a deprecated crypto c library and I did not want to "pollute" my clean production infrastructure. Containers would definitively help with this scenario. The thought never occurred to me that docker could be used to reproduce/encapsulate legacy systems, thanks!

Re: Weave – The Docker Network

#52

Post by weavenetwork »

SEJeff wrote: post #47
weavenetwork wrote: post #42

Earlier quoted context omitted.

Weave itself does not provide addressability beyond IP. That is the situation now, but this area is very much high on the agenda for us - service discovery is definitely in scope for weave. Meanwhile, two points of note: 1) In weave the IP addresses can be much "stickier" than in other network setups, i.e. a moving a container from one host to another can retain the containers IP. That means it is quite amenable to r…

Perhaps you'd consider looking for the best way to "weave" weave into consul? http://consul.io

We are certainly aware of consul, and have indeed been thinking of weaving weave into it. Would love to see an experiment along those lines, if there are any volunteers.

Re: Weave – The Docker Network

#53

Post by ferrantim »

justinmayer wrote: post #39
ferrantim wrote: post #12

Earlier quoted context omitted.

At the expensive of sounding like I'm just plugging my own company, this is what we're working on in the open-source project Flocker ( https://github.com/ClusterHQ/flocker ). We think that data-services like databases, queues and key-value stores, and anything else with state should be able to run inside docker containers too. Yes, you can already run a database in a docker container, but from an ops perspective, thi…

You say that running a database in a Docker container is "a nightmare and very far from what you want to be able to do in a production system," but you do not explain why. Perhaps you might substantiate such a claim?

This blog post about the problems running databases in container-based PaaS is a good starting point: http://blog.lusis.org/blog/2014/06/22/feedback-on-paas-reali...

Generally, you want to be able to answer these questions when it comes to operating your databases:

What are the failure points? What is the impact of each failure point? What are the SINGLE points of failure? What is my recovery pattern? What is my upgrade experience? What is the operational overhead in the applications running ON the product? What is my DR strategy? What is my HA strategy?

Pure Docker, and no other tool that we are aware of in the docker/container ecosystem that we are aware of provide really good answers to these questions when it comes to databases. That is what I mean when I said running databases in containers in a nightmare. It is possible today, for sure, but it is extremely complex operationally and its why it is so rare to see prod databases running in production today.

Re: Weave – The Docker Network

#55

Post by jpgvm »

shykes wrote: post #21
jpgvm wrote: post #9

I hope all of these Docker overlay networks start using the in-kernel overlay network technologies soon. User-space promiscuous capture is obscenely slow. Take a look at GRE and/or VXLAN and the kernels multiple routing table support. (This is precisely why network namespaces are so badass btw). Feel free to ping me if you are working on one of these and want some pointers on how to go about integrating more deeply w…

I would love to take you up on that. I want to bake vxlan support into Docker upstream (as an optional plugin, like everything else). Edit: Hi Joseph! Just realized it was you :)

Haha for sure Solomon, I have some other ideas now too that I am using Docker in production. I will hit you up to have a chat. :)

Re: Weave – The Docker Network

#56

Post by CMCDragonkai »

wmf wrote: post #49
darren0 wrote: post #44

Earlier quoted context omitted.

You have to pick either kernel or user space, not both. Either implement it purely in the kernel or purely in user space. In reality pure user space is faster, just look at Snabb switch https://github.com/SnabbCo/snabbswitch/wiki

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?

Re: Weave – The Docker Network

#57

Post by kijiki »

vishvananda wrote: post #45
jpgvm wrote: post #9

I hope all of these Docker overlay networks start using the in-kernel overlay network technologies soon. User-space promiscuous capture is obscenely slow. Take a look at GRE and/or VXLAN and the kernels multiple routing table support. (This is precisely why network namespaces are so badass btw). Feel free to ping me if you are working on one of these and want some pointers on how to go about integrating more deeply w…

Since you seem to have some kernel expertise, do you know if there is an easy way (via an iptables/ebtables plugin or some such) to get packets to switch namespaces? It seems like you could do a whole lot with just simple kernel packet rewriting if you could have an in-container-namespace rule to jump into another namespace before routing. You could do some analog of this with a veth device, but it seems like it woul…

"just switching namespaces" isn't easy, since a packet (in the kernel represented by an SKB) has to have an interface it came in on. The main role an veth pair has is to move the packet between namespaces, and to provide a new in interface, one that is visible in the new namespace.

Unless someone did something crazy, traversing a veth pair should just be doing a little bookkeeping on the SKB, no data copies at all.

Re: Weave – The Docker Network

#58

Post by kijiki »

shykes wrote: post #21
jpgvm wrote: post #9

I hope all of these Docker overlay networks start using the in-kernel overlay network technologies soon. User-space promiscuous capture is obscenely slow. Take a look at GRE and/or VXLAN and the kernels multiple routing table support. (This is precisely why network namespaces are so badass btw). Feel free to ping me if you are working on one of these and want some pointers on how to go about integrating more deeply w…

I would love to take you up on that. I want to bake vxlan support into Docker upstream (as an optional plugin, like everything else). Edit: Hi Joseph! Just realized it was you :)

If you're going down the path of VXLAN support in Docker, I'd love to talk. The company I founded built a Linux distribution for commodity hardware switches that can do VXLAN encap/decap in hardware at 2+ Tbit/sec. The same configuration that works in a Linux container host or a hypervisor works on the switches.

nolan@cumulusnetworks.com

Re: Weave – The Docker Network

#59

Post by nl »

pas wrote: post #33
yebyen wrote: post #14

Earlier quoted context omitted.

Unfortunately I haven't read enough 12fa, but I know I can address most of your questions with one factoid: Volumes. You are absolutely right that Docker containers are meant to be disposable, and should not contain backing data. That is what Volumes are for. I haven't done enough with volumes to give you a real primer on the use of them, but volumes can run on whatever backing store you want and they are not so inte…

I'm familiar with volumes, and here's how I see the problem: On a docker host you have the docker daemon, and whatever auxiliary stuff you need to orchestrate either the containers or the host (update docker itself, and so on), you have space for /var/lib/docker, and that's it. Volumes are always somewhere on /host/data. That means you have to make up a scheme and convention, and cook up scripts and add it to your al…

Yeah, the problem isn't that you can't do it. The problem is there are too many ways that mostly do what you need.

Re: Weave – The Docker Network

#60

Post by nl »

sciurus wrote: post #36
saryant wrote: post #28

Earlier quoted context omitted.

At the company I work for, we went through all the trouble of getting our distributed backend application running Vagrant using Chef so that we could have identical local, dev and production environments. In the end, it's just so slow that nobody uses it locally. Even on a beefy Macbook Pro, spinning up the six VMs it needs takes nearly 20 minutes. We're looking at moving towards docker, both for local use and produc…

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.
Post reply on HN