3 ms·

An app container is pared down to run a single app. That's why you need a third party process managers like runit, supervisor or a script to run multiple apps i

by tobbyb 11y ago

An app container is pared down to run a single app. That's why you need a third party process managers like runit, supervisor or a script to run multiple apps in a single app container format like Docker. A system container is similar to a VM, you can use it more or less as a VM environment, run multiple apps, ssh, schedule jobs, cron etc. A system container gives you a more complete OS environment within the constraints of a container. I have a post that goes into some depth comparing LXC to Docker, it's not updated to include LXD but could help. http://www.flockport.com/lxc-vs-docker/ http://www.flockport.com/lxc-vs-docker/

vidarh 11y ago
Nothing stops you from using Docker containers as what you describe as "system containers". The comparison you give to LXC is quite strange, given that Docker used to default to using LXC as it's backend. My most frequently used Docker container is primarily used for me to ssh in to a development environment that I use "more or less as a VM environment" and run multiple apps in, including sshd, screen and a ton of editors. Other differences you give such as "instances are ephemeral, persistent data is stored in bind mounts to host or data volume containers" is only true if that is how you decide to use it. Data persists in a Docker container as long as you don't destroy the container. E.g. there's nothing special about a "data volume container" other than that you decide to not destroy it. The only reason some people like to make this distinction about app and data is that it allows you to destroy the container containing the application code (e.g. to upgrade it) without destroying the data. Or, if you go the bind mount route, and set things up accordingly you can e.g. blow away the entire /var/lib/docker whenever you feel like it (just mkfs'd an entire partition containing /var/lib/docker on a server earlier to clean up some cruft - service files restarted everything again shortly after I started Docker back up). You can do the exact same thing with LXC if you want (including using "data containers" which are nothing but bind mounting parts of one container on top of parts of another). Unsuprisingly since Docker used to do the exact same thing using LXC as the backend mechanism. Most of what you write about LXC as a "system container" holds only if you choose to install a full OS image as an LXC container, but LXC containers can just as well be only a single application if you prefer. LXC, like Docker, doesn't care either way - it just sets up the environment and executes your specified application. "Docker restricts the container to a single process only" is wrong, as you point out yourself, when you write that "there is no way to run php-fpm, apache and mysqld in the same container without a shell script or install a separate process manager like runit or supervisor." Running a "separate process manager" is also exactly how you run more than a single process with LXC.
- tobbyb 11y ago
  Hi, Thanks for your comments. It's nice to hear from someone who is well informed and can tell the difference. Unfortunately as any container thread on HN itself will show and a lot of persistent questions we get on flockport.com confirm, there is still lot of needless confusion. And that post was written for new users to the world of containers who may not know for instance that you DO need a process manager or a script to run multiple apps in Docker. You do not 'think about running, installing a process manager' in LXC. It a default like any OS environment the average user would be used to for instance on their system or a VM. As an experienced user you can appreciate that distinction for new users. Also Docker was designed with the single app restriction. It's a significant difference with LXC. The Docker OS template is intentionally restricted to do this. You can work around it but if it is your intention to multiple apps why not just use LXC itself? It's there for a purpose which the Docker site, and ecosystem articulate. A lot of your other points are coming from an in-depth understanding of both LXC, Docker and the operating system. A lot of users do not have this perspective to being with. That post merely draws this out and hopes to inform.
- 23david 11y ago
  This is known as the PID-1 issue, and ever since Docker first came out it's been a major source of frustration for many users who want to use Docker containers to run their existing workloads. It's not possible to run a Docker container with systemd, upstart or sysvinit working without major workarounds. So while it is possible to use a custom and hacked environment to get a docker container that simulates a regular linux system, out of the box it's simply not possible. I think it's entirely accurate to call Docker a system for managing application containers. LXC can be run with various options, but by reading the lxc docs (one example here: https://wiki.debian.org/LXC https://wiki.debian.org/LXC) you can see that it supports various normal init systems and not just the process managers that can run under Docker.

by tobbyb 11y ago

vidarh 11y ago

Nothing stops you from using Docker containers as what you describe as "system containers". The comparison you give to LXC is quite strange, given that Docker used to default to using LXC as it's backend. My most frequently used Docker container is primarily used for me to ssh in to a development environment that I use "more or less as a VM environment" and run multiple apps in, including sshd, screen and a ton of editors. Other differences you give such as "instances are ephemeral, persistent data is stored in bind mounts to host or data volume containers" is only true if that is how you decide to use it. Data persists in a Docker container as long as you don't destroy the container. E.g. there's nothing special about a "data volume container" other than that you decide to not destroy it. The only reason some people like to make this distinction about app and data is that it allows you to destroy the container containing the application code (e.g. to upgrade it) without destroying the data. Or, if you go the bind mount route, and set things up accordingly you can e.g. blow away the entire /var/lib/docker whenever you feel like it (just mkfs'd an entire partition containing /var/lib/docker on a server earlier to clean up some cruft - service files restarted everything again shortly after I started Docker back up). You can do the exact same thing with LXC if you want (including using "data containers" which are nothing but bind mounting parts of one container on top of parts of another). Unsuprisingly since Docker used to do the exact same thing using LXC as the backend mechanism. Most of what you write about LXC as a "system container" holds only if you choose to install a full OS image as an LXC container, but LXC containers can just as well be only a single application if you prefer. LXC, like Docker, doesn't care either way - it just sets up the environment and executes your specified application. "Docker restricts the container to a single process only" is wrong, as you point out yourself, when you write that "there is no way to run php-fpm, apache and mysqld in the same container without a shell script or install a separate process manager like runit or supervisor." Running a "separate process manager" is also exactly how you run more than a single process with LXC.

tobbyb 11y ago
Hi, Thanks for your comments. It's nice to hear from someone who is well informed and can tell the difference. Unfortunately as any container thread on HN itself will show and a lot of persistent questions we get on flockport.com confirm, there is still lot of needless confusion. And that post was written for new users to the world of containers who may not know for instance that you DO need a process manager or a script to run multiple apps in Docker. You do not 'think about running, installing a process manager' in LXC. It a default like any OS environment the average user would be used to for instance on their system or a VM. As an experienced user you can appreciate that distinction for new users. Also Docker was designed with the single app restriction. It's a significant difference with LXC. The Docker OS template is intentionally restricted to do this. You can work around it but if it is your intention to multiple apps why not just use LXC itself? It's there for a purpose which the Docker site, and ecosystem articulate. A lot of your other points are coming from an in-depth understanding of both LXC, Docker and the operating system. A lot of users do not have this perspective to being with. That post merely draws this out and hopes to inform.
23david 11y ago
This is known as the PID-1 issue, and ever since Docker first came out it's been a major source of frustration for many users who want to use Docker containers to run their existing workloads. It's not possible to run a Docker container with systemd, upstart or sysvinit working without major workarounds. So while it is possible to use a custom and hacked environment to get a docker container that simulates a regular linux system, out of the box it's simply not possible. I think it's entirely accurate to call Docker a system for managing application containers. LXC can be run with various options, but by reading the lxc docs (one example here: https://wiki.debian.org/LXC https://wiki.debian.org/LXC) you can see that it supports various normal init systems and not just the process managers that can run under Docker.