Live data from Hacker News

Docker 1.2.0, with restart policies

blog.docker.com

41–50 of 76 posts

Re: Docker 1.2.0, with restart policies

#41

Earlier quoted context omitted.

I don't think you are understanding what docker is doing. Docker interfaces with the kernel to provide security and isolation via cgroups and namespaces. This is exactly what jails does, and is indeed on the list of things to be added. It's really a matter of someone taking the time to write the driver for it. Docker also provides an image format and infrastructure for helping to make applications portable.

> I don't think you are understanding what docker is doing. Docker interfaces with the kernel to provide security and isolation via cgroups and namespaces. If I were to nitpick I would say docker is doing none of those things. LXC is. Docker is just freeloading off LXC while providing almost no benefits. I tried Docker, but quickly discovered it was a cumbersome interface on top of LXC, and if you wanted to get any r…

> If I were to nitpick I would say docker is doing none of those things. LXC is. Docker is just freeloading off LXC while providing almost no benefits.

This was true in early versions, but now the default container "exec driver" is libcontainer (a pure Go container implementation), and you can swap to LXC "exec driver" if you wish. To say Docker is piggybacking on top of LXC is unfair when in reality Docker wrote thier own container implementation.

> I tried Docker, but quickly discovered it was a cumbersome interface on top of LXC, and if you wanted to get any real work done, you needed to manage LXC yourself anyway. So ... Why should I bother with Docker in the first place then?

How long ago was this? The project moves fast and new features get added all the time.

Re: Docker 1.2.0, with restart policies

#42

Earlier quoted context omitted.

I don't think you are understanding what docker is doing. Docker interfaces with the kernel to provide security and isolation via cgroups and namespaces. This is exactly what jails does, and is indeed on the list of things to be added. It's really a matter of someone taking the time to write the driver for it. Docker also provides an image format and infrastructure for helping to make applications portable.

> I don't think you are understanding what docker is doing. Docker interfaces with the kernel to provide security and isolation via cgroups and namespaces. If I were to nitpick I would say docker is doing none of those things. LXC is. Docker is just freeloading off LXC while providing almost no benefits. I tried Docker, but quickly discovered it was a cumbersome interface on top of LXC, and if you wanted to get any r…

Almost no benefits? The good parts of Docker adds on top of plain LXC:

- Layered file system for containers, commiting - Images, easily transferable - Remote API - Network interfaces - Linking containers - Nice build system, one Dockerfile and you are almost good to go

I really wonder what is the real work you want to do, that you cannot do with Docker, and Docker becomes a cumbersome.

Re: Docker 1.2.0, with restart policies

#43
post #20

Earlier quoted context omitted.

Well, Docker just slapped a "1.0" sticker on and called itself "production ready" when it clearly wasn't (features like in this 1.2 release are kind of mandatory for any serious deployments).

You could already do these things outside of dockerland via the host-integration stuff (ie, systemd to handle restarts/monitoring). 1.0 was/is about API stability, engine stability, full ecosystem with Docker Hub, and enterprise support.

Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.

Re: Docker 1.2.0, with restart policies

#45
post #12

Maybe a bit off-topic. I haven't found a satisfactory solution to having communicating containers across multiple hosts. There seems to be quite a few solutions in the making (libswarm, geard, etc). How are other people solving this (in production, beyond two or three hosts)?

https://github.com/cpuguy83/docker-grand-ambassador https://github.com/progrium/ambassadord

Interesting, thanks! FWIW, ambassadord has consul integration and that's something I've wanted.

Re: Docker 1.2.0, with restart policies

#46
post #31

Earlier quoted context omitted.

> I don't think you are understanding what docker is doing. Seems like you actually are not understanding what docker is doing. Docker (and LXC for the matter) aren't about security -- they are about portability of the application and environment. Everything else is tertiary. > It's really a matter of someone taking the time to write the driver for it. It's a bit more complicated than that -- the two are different be…

The cgroups and namespaces do indeed provide a layer of security. We also drop certain capabilties, so for instance root inside the container can't (by default) manipulate iptables, mount things, change network settings, etc. To come later would also be user namespaces so root inside the container != root outside the container. There's also a significant amount of support within Docker for selinux/apparmor stuff. Ind…

I get the PR angle... But over-representing Docker is doing more harm than good. People are reading things like "We would like to add feature X" or "Implementing feature X is on the roadmap", but interpreting it as "Docker does all these things right now". Soon people will be talking about how Docker makes pizza too.

Can Docker be secure? Sure -- is it? No.

Re: Docker 1.2.0, with restart policies

#47
post #46

Earlier quoted context omitted.

The cgroups and namespaces do indeed provide a layer of security. We also drop certain capabilties, so for instance root inside the container can't (by default) manipulate iptables, mount things, change network settings, etc. To come later would also be user namespaces so root inside the container != root outside the container. There's also a significant amount of support within Docker for selinux/apparmor stuff. Ind…

I get the PR angle... But over-representing Docker is doing more harm than good. People are reading things like "We would like to add feature X" or "Implementing feature X is on the roadmap", but interpreting it as "Docker does all these things right now". Soon people will be talking about how Docker makes pizza too. Can Docker be secure? Sure -- is it? No.

These are all things that are there now, except user namespaces (which is indeed huge), not roadmap items.

Re: Docker 1.2.0, with restart policies

#48

Earlier quoted context omitted.

You could already do these things outside of dockerland via the host-integration stuff (ie, systemd to handle restarts/monitoring). 1.0 was/is about API stability, engine stability, full ecosystem with Docker Hub, and enterprise support.

Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.

FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc.

So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.

Re: Docker 1.2.0, with restart policies

#49

Any update on when the OS X version will be available? I'm only seeing version 1.1.2 here: https://github.com/boot2docker/osx-installer/releases

Use the Vagrant env, boot2docker is a mess IMO.

I liked the Vagrant env but I don't see it mentioned as an option here: https://docs.docker.com/installation/#installation

Are there any up-to-date installation instructions for the Vagrant env?

Re: Docker 1.2.0, with restart policies

#50
post #12

Maybe a bit off-topic. I haven't found a satisfactory solution to having communicating containers across multiple hosts. There seems to be quite a few solutions in the making (libswarm, geard, etc). How are other people solving this (in production, beyond two or three hosts)?

I simply expose ports (or do --net=host) and communicate between hosts in the normal fashion. Unless you don't trust your host I don't see the problem with that.
Post reply on HN