Hacker News Reader

Comment by guardiangod | Hacker News Reader

Leaving aside there's now yet another abstraction layer to have bugs, it is not a straw-man to imply that current container technology is not as reliable as bare metal.

Or do you mean that Docker etc. are as reliable as bare metal?

Heck, you can go on Docker's webpage (https://www.docker.com/what-docker). Notice that while they make the claims that Docker is-

1. More lightweight

2. 'Open'/run anywhere

3. Secure

They don't say 'more reliable'.

I use Docker for systems I design; I also recognize current container technologies have their limitations. It is my job to know and avoid these pitfalls.

View on HN

This conversation should distinguish between Docker as a product and container technology in general.

A lot of issues that people encounter with Docker specifically disappear if you run Kubernetes (such as volume management), simply by ignoring what Docker does and doing something sane instead.

> Or do you mean that Docker etc. are as reliable as bare metal?

This doesn't really mean anything, Docker the product has a lot issues - sure. Container technology in general? No. Where do you draw the line here? Is a chroot 'as reliable as bare metal'? At what point is a container not running on bare metal anymore?

Of course Namespace in Linux kernel is very mature. But if that's all people use, then there wouldn't be a need for Docker and its extra features- people would still be using LXC (no disrespect to LXC). People have to evaluate the entire software as a whole, instead of just looking at the core technology. I personally feel that Docker is still unproven in terms of maturity. Stateless? Hell yes. Stateful app? Well...

As you said, a lot of problems would disappear if people use Kubernetes instead of Docker. At the same time, a lot of replication problems would disappear if people use PostgreSQL instead of MySQL. My point is, when a novice mixes immature technology with immature technology, he is going to have more issues than what's necessary.

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.

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.

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.

Reply on news.ycombinator.com