Hacker News Reader

Comment by seldo | Hacker News Reader

Indeed. One way you can use Docker in production[1] is one container per machine: even when you're not using the containers to split resources, the ability to snapshot and move an application and all of its dependencies in a single, lightweight, easily deployed package is very exciting. And because there's no translation etc. happening, running a single container is pretty much identical, performance-wise, to running it directly on the machine[2].

[1] dotCloud don't actually yet recommend running Docker in production, but if you did...

[2] This was part of what Mailgun (part of Rackspace) said in their presentation at the Docker workshop in SF today.

View on HN

You can actually do the same thing with LXC containers; it is trivial to rsync a snapshot or compressed archive of a snapshot to another host machine and run it there.

Why the downvote? Simple tools always work well. If you want process isolation on Linux, LXC + rsync might as well be the simplest route.

Anything not pro-docker usually gets downvoted by shykes and his ring of cronies.

There's definitely hype behind Docker, but this is a ridiculous accusation.

People do crazy things for money.

You have rationalized away the people who disagree with you by making them into a conspiracy. I don't know about said ring of cronies, but I guarantee that many downvoters are not associated.

My claim seems validated. Just look at both of my comments in this thread; they've both been downvoted deep into the negatives.

My downvotes because the comments were disparaging and lacked proof. My only Docker affiliation is reading a bit about it lately. I had to search the page to see who shykes is.

Docker is based on LXC containers. It bundles it's own management layer that replaces the "rsync" solution you propose.

The point of Docker is the standardized container/management interface. Of course you can write your own, but then it's not too standardized is it?

What you describe is standardizing complexity where a simple solution is available. Naturally, when feasible, I prefer keeping things simple and straightforward enough that standardization is unnecessary.

Standardization for the sake of standardization is not defensible.

Regarding your first footnote:

Is there an explanation why 'in production' is actively discouraged? Is that a limitation of the underlying lxc stuff?

I ask, because the interesting parts of docker _for me_ seem to be focused on the setup, deployment - and not the runtime. So if I create a working image and want to use that in production, wouldn't docker become passive as soon as I run that thing?

What's the danger here?

I expect the danger is that someone will lose money and blame the developers for as-yet unforeseen issues which can only be smoked out after a few years of heavy use. But a specific danger would be interesting to hear.

Docker maintainer here. That's basically it. There's no specific danger that we're worried about - just engineering best practices.

As long as we're not comfortable operating Docker at large scale ourselves (we run quite a lot of containers in production at dotCloud), we won't recommend that others do it.

Reply on news.ycombinator.com