Hacker News Reader

Comment by subway | Hacker News Reader

At no time was the claim made that containers were more reliable than any other method of running a process, only that running a process within a container is not inherently less reliable than un-contained.

Unless you've gone out of your way, Docker (as well as other Linux container systems) are just namespacing your process. There's no extra abstraction layer, it's just a more restricted execution environment.

View on HN

The numerous performance and stability issues (not just in the containers, but also affecting the main cgroup / "host" rather badly) I had with Docker, but never with LXC, which, according to you would be pretty much the same thing - "just namespacing your process". But it isn't.

Docker is ok when it works, hell when it doesn't, has lots of bugs and regularly regresses. I don't understand why you'd run production infrastructure on that and not on any of the alternatives.

FYI: The networks and the disks are entirely abstracted, with multiple extremely complex abstraction layers.

Volume mounts inside containers bypass unionfs. There isn't anything inherently different about using a partition from container or from a host.

Not necessarily. You could use --net=host and -v /db_data:/db_data (equivalent of `sudo mount --bind /db_data /the/containers/root/fs/dir/db_data`)

Run like this, there is no disk or network performance difference between running the db process directly on the host or via a Docker container.

As others have mentioned, this is a really poor article.

Reply on news.ycombinator.com