

Getting started with LXD – the container lightervisor - onestone
https://www.stgraber.org/2015/04/21/lxd-getting-started/

======
mixmastamyk
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?

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

~~~
23david
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.

