4 ms·

Seems like a straw-man. Why is a process running within a container failing over more frequently than a process running directly on bare metal -- seems like mor

by subway 10y ago

Seems like a straw-man. Why is a process running within a container failing over more frequently than a process running directly on bare metal -- seems like more of a resource/process scheduling issue than anything to do with containers.

guardiangod 10y ago
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 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.
- tazjin 10y ago
  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?
  - guardiangod 10y ago
    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.
- 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 ago
    FYI: The networks and the disks are entirely abstracted, with multiple extremely complex abstraction layers.
    - gnufied 10y ago
      Volume mounts inside containers bypass unionfs. There isn't anything inherently different about using a partition from container or from a host.
    - brobinson 10y ago
      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.
  - throwawayish 10y ago
    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.
user5994461 10y ago
> Why is a process running within a container failing over more frequently than a process running directly on bare metal Because the way to change anything in a container is to kill it and restart it. That's a fundamental difference compared to managing/maintaining a database not in a container.
- subway 10y ago
  Unless you've written very poorly behaving software, you kill it by sending it a SIGTERM, and waiting for it to exit. This is true of software both within and outside of containers. The fact `docker kill` defaults to using SIGKILL instead of SIGTERM is unfortunate, and something one should be aware of before deploying a process with docker, but again, this does not make the process running within the container inherently less reliable. edit: Looks like `docker stop` does the right-ish thing -- sends a SIGTERM, then only resorts to SIGKILL after a timeout has expired.
  - brazzledazzle 10y ago
    Also worth noting that the timeout is a configurable parameter with `docker stop`.
- ec109685 10y ago
  You don't have operate your container like that. If you need to push configuration to it, you can make it writeable.

by subway 10y ago

guardiangod 10y ago

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 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.

tazjin 10y ago
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?
- guardiangod 10y ago
  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.
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 ago
  FYI: The networks and the disks are entirely abstracted, with multiple extremely complex abstraction layers.
  - gnufied 10y ago
    Volume mounts inside containers bypass unionfs. There isn't anything inherently different about using a partition from container or from a host.
  - brobinson 10y ago
    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.
- throwawayish 10y ago
  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.

user5994461 10y ago

> Why is a process running within a container failing over more frequently than a process running directly on bare metal Because the way to change anything in a container is to kill it and restart it. That's a fundamental difference compared to managing/maintaining a database not in a container.

subway 10y ago
Unless you've written very poorly behaving software, you kill it by sending it a SIGTERM, and waiting for it to exit. This is true of software both within and outside of containers. The fact `docker kill` defaults to using SIGKILL instead of SIGTERM is unfortunate, and something one should be aware of before deploying a process with docker, but again, this does not make the process running within the container inherently less reliable. edit: Looks like `docker stop` does the right-ish thing -- sends a SIGTERM, then only resorts to SIGKILL after a timeout has expired.
- brazzledazzle 10y ago
  Also worth noting that the timeout is a configurable parameter with `docker stop`.
ec109685 10y ago
You don't have operate your container like that. If you need to push configuration to it, you can make it writeable.