Announcing Docker 1.7: Multi-host networking, plugins and orchestration updates

https://blog.docker.com/2015/06/announcing-docker-1-7-multi-host-networking-plugins-and-orchestration-updates/

by eloycoto • 11 years ago

79 36 11 years ago

blog.docker.com

hmottestad• 11 years ago

Awesome awesomeness. I read a blog post here about vxlan adding some 10% overhead in terms of both latency and bandwith, which seems very acceptable to me :)

CoreOS has had this for a while in flannel (ref the same article as above), so it's not like it's a completely new thing, but if you prefer going with the crowd, then having overlay networking built right into docker will make for an awesome experience when using docker compose and docker swarm.

Edit:

Article: http://www.generictestdomain.net/docker/weave/networking/stu...

And the results: Flannel VXLan 96.55% bandwidth utilisation 140.52% latency. Without overlay latency was 91.8µs, and with vxlan it was 129µs.

Nrsolis6• 11 years ago

I can't say I'm particularly happy with the choice of VxLAN as a tunneling technology but I'm not particularly surprised either.

Nrsolis6• 11 years ago

THIS is what I'm talking about:

http://cloudarchitectmusings.com/2013/01/03/word-of-caution-...

VxLAN is a technology with a very limited horizon in terms of functionality. If you're intending to really leverage containers in a super dense use case, then you'd be well advised to adopt a technology that has ready made ASIC support for cross the physical-to-virtual network boundary.

andyl• 11 years ago

I can't keep up with the churn. Will come back to Docker in a year or two to see if things have stabilized.

shykes3• 11 years ago

FWIW we add a lot of new features, but we break very few APIs. API stability is extremely important to us, so you can actually build stable things on Docker and trust that we won't break it down the road.

jpallen2• 11 years ago

I've had APIs subtly break on me between at least 2 releases (I think it's actually 3, but one time may have been user error). The main culprits were changing the parameters which are passed on container creation vs on container start, and changing error messages/response codes.

cshimmin• 11 years ago

If I understood parent's comment (or maybe I just interpreted to agree with my own point of view), the implication is that some people are punting on even getting started w/ Docker, because things are moving too quickly. You may not break API's, but if the best-practices I learn today are completely obsolete by this time next year, that's still a bummer.

toomuchtodo• 11 years ago

Try using Docker in a production environment. :(

general_failure• 11 years ago

Still no user namespace support? I don't get how one can use for production websites without this. Especially if your run arbitrary containers from the docker registry. Or this not the suggested model anymore?

lk4d4• 11 years ago

There is support in runc https://github.com/opencontainers/runc.git It is still unsupported in docker though

davexunit3• 11 years ago

Do any other container projects support user namespaces? I'm curious about what the implementation would look like. Several things change when a user namespace is added to the mix, such as the container not being able to create new device nodes. Would it be possible for unprivileged users to create containers that had network access or is a daemon running as root still necessary?

wmf2• 11 years ago

pflask (which I don't think anyone has heard of) and the latest version of nspawn.

shykes3• 11 years ago

We have implemented user namespace support in runC, which we announced today :) https://runc.io

Integration of user namespaces into the developer-facing tools is ongoing, but there is an design discussion to finish on how to best handling uid mapping without breaking shared volumes.

TLDR: if you want to customize your docker install to support user namespaces today, you should try runC.

jpallen2• 11 years ago

The volume plugins look very interesting for our use case, but I can't find any documentation about how to actually write a plugin? Do I have to reverse engineer it from the Flocker example provided?

Edit: Nevermind, I found it (https://github.com/docker/docker/blob/master/experimental/pl...)! Three clicks in, through various blog articles with lots of other links. Maybe consider making this more obvious?

bkeroack• 11 years ago

Rather than run all network traffic through their single daemon, my feeling is that it's better to abstract your containers into pods and discoverable services like Kubernetes.

Increasingly my feeling regarding Docker, Inc is "too little, too late". They seem to be chasing every market (enterprise, startup, developer) and therefore are mediocre at a lot of things while expert at none.

shykes3• 11 years ago

Docker's new networking model is exactly what you describe. In fact it was developed with a lot of feedback from the Google team, so if you like Kubernete's networking model you'll be in known territory.

It's true that the Docker daemon by default bundles these functionalities by default. But under the hood, the networking system is actually a separate binary called "dnet", so it's going to be very easy to rip it out and make the daemon less monolithic.

falcolas3• 11 years ago

I'm sorry, I have to be a bit negative on this one.

- No release notes! (as of 1 hour after story posted)

- Network stack re-written. They kinda flubbed network the first time, creating assymetric network and double nat conditions. And within one release, there's a complete re-write with a new networking model? This is going to take a lot of proving to ensure that it's actually going to work for production systems. In the meantime, we at least are going to continue using --net=host for our containers.

- Another storage format. Can we simply get one that's stable, please?

- Volume re-write. Ditto networking.

- [EDIT2] Disregard previous edit entirely - now you're simply disallowed from using devicemapper entirely, if you're using the officially compiled Docker binary for Ubuntu 14.04 and 15.04? [4] What the actual fuck is going on here Docker? AUFS has significant performance issues (not even mentioning the deprecated part), OverlayFS requires a release candidate Linux kernel, ZFS as a storage backend is brand spanking new, and btrfs is as stable as a three legged chair. By the way, this affects CentOS and RHEL.

[EDIT]: 1.7 appears to have fixed the superficial problem - using the wrong devicemapper drivers. Would still prefer to have a proper package.

[ORIGINAL] The whole "devicemapper on Ubuntu 14.4" [1] snafu appears to still in full force [2]. Why can't they offer properly compiled OS packages? They're distributing them as OS/Architecture specific packages...

Note - AUFS is not a real choice for (at least) node applications, we ran into an issue back on 1.6 where there was a low level mutex limiting concurrency on AUFS which did not appear on devicemapper. [3]

[1] https://github.com/docker/docker/issues/4036

[2] https://github.com/Capgemini/Apollo/issues/315

[3] https://github.com/docker/docker/issues/13268

[4] https://github.com/docker/docker/issues/14035 (look down for "vbatts" comment with the bolded summary header)

zupancik• 11 years ago

Bit new to Docker - so does this mean Docker 1.7 won't work with RHEL? Specifically I'm working on RHEL 6.6 machines, and I'm already stuck with Docker 1.5 so curious to know whether this will affect me

falcolas3• 11 years ago

I'm not running RHEL myself, so I can't authoritatively speak about it. The backstory is that Docker, as statically compiled and released, uses the 1.02 release of the devicemapper driver, which has a bug in it. The OS has a 1.02.1 version (and has, for some time, it was patched in Dec 2013), but you have to make your own Docker build which will dynamically link to it.

Take a look at your version of libdevmapper, and you should be able to see if there will be a problem; what I've heard is that CentOS and RHEL also have a fixed version of devicemapper, which causes the mis-match and creates the problem outlined in the #4036 issue.

The ideal fix is to actually compile Docker on an Ubuntu (RHEL) OS when building the Ubuntu (RHEL) packages, but what's actually happening is that it's being built in a minimal Linux container - which gives it a different version.

shred45• 11 years ago

They've also RUINED their docs pages. The typography hurts my eyes and the link layout makes it a pain to find anything specific. Takes me 10 times as long to find anything.

falcolas3• 11 years ago

Yeah. I'm actually missing their previous documentation, which was much more readable and had some links on the left hand side down to anchors within a page. Now it's a bit of an inconsistent mess to find something.

geku• 11 years ago

Same here, I also find the new navigation a bit unconventional for such a large page structure.

Announcing Docker 1.7: Multi-host networking, plugins and orchestration updates

Related Stories