3 ms·
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 n
by subway 10y ago
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.
- user5994461 10y agoFYI: The networks and the disks are entirely abstracted, with multiple extremely complex abstraction layers.
- gnufied 10y agoVolume mounts inside containers bypass unionfs. There isn't anything inherently different about using a partition from container or from a host.
- brobinson 10y agoNot 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.
- throwawayish 10y agoThe 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.