Looks interesting, however this article needs to improve the section where it talks about how this compares with Docker, etc. The difference between "system" and "app" containers doesn't say much to me.
What is better here, the design? I like Docker, but find the command-line (and maintenance) a bit awkward, will this project improve on that?
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.
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.
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) you can see that it supports various normal init systems and not just the process managers that can run under Docker.
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.
The distinction between "system" and "app" containers is almost entirely artificial and down to philosophy. LXC containers can very easily be single app, and Docker containers can be full systems.
Lxd looks interesting, though, in particular in not actively trying to make running your on registry/image server awkward, which appears to be a design goal with Docker, though they are trying hard to describe it as more different to Docker than it appears to actually be. Also if they get live migrations working well (having dealt with live migrations with e.g. OpenVz, live migrations is one of those things that is full of gotcha's, and I've come to prefer to spawn new containers and do quick and dirty ip switches couples with gratuitous arp instead whenever I can get away with it).
LXD sounds like another (rkt also...) promising alternative to Docker for running containerized workflows. A few major differences that I can see between LXD and Docker are: a) the security model and focus, where LXD uses LXC natively for security/isolation and is trying to further enhance with cpu-level isolation of some kind b) it sounds like LXD containers will support running init systems, which will make it much easier to deploy bare-metal and VM workloads in LXD containers versus Docker containers c) live-migration, and d) no 'batteries included' so the equivalent of the docker registry isn't installed and setup by default as is the case with Docker.
It appears that Canonical is positioning LXD as more of a drop-in and simple alternative to VMs. It's also nice to see that LXD containers will support running docker containers within them. So you can have your 'pod' of application containers all running within one big LXD container if you want. Good times.
What is better here, the design? I like Docker, but find the command-line (and maintenance) a bit awkward, will this project improve on that?