Getting started with LXD – the container lightervisor
stgraber.org
stgraber.org
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?
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.
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.
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.
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.
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).
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.