
A Quick Introduction to LXD - tych0
http://blog.scottlowe.org/2015/05/06/quick-intro-lxd/
======
tobbyb
LXC is really quite simple and makes a lot of sense when you need a
lightweight VM, that behaves like a VM. Docker takes a very specific view of
containers with layers, a modified container OS template and init that limits
the container to running a single app. This may be great for deployment or
PAAS specific use cases but adds needless complexity for more general use
cases.

There is more to containers than running a single app. Their potential as
lightweight, efficient and portable alternatives to VMs is immense. We have
tons of resources on LXC at Flockport, including ready to use containers [1]

VM workloads can transition seamlessly to LXC containers. And the large
ecosystem of Linux tools and apps that work on VMs and systems work perfectly
in LXC. And you do not need to find a container specific way to do things.

Take networking, overlay networks or clustering that works in VMs work as well
in containers. We have a largish number of tutorials on multi host container
networking over both layer 2 and 3 with GRE, L2TP, VxLAN, IPSEC, tinc and more
[2] A lot of Docker specific tools use these under the hood but they are easy
enough to use on their own.

The LXC team are trying to move the needle with LXD. It uses unprivileged
containers by default (non root users can run containers, this is not
capabilities drop) multi host management with a REST api so you can query the
LXD daemon for container orchestration across hosts and live migration. These
are big steps forward and they really do need the support of the community.
They have been doing this for 7 years and is thanks to then containers exist.

[1] [http://www.flockport.com/containers](http://www.flockport.com/containers)

[2] [http://www.flockport.com/news](http://www.flockport.com/news)

~~~
tribaal
> The LXC team are trying to move the needle with LXD. It uses unprivileged
> containers by default (non root users can run containers, this is not
> capabilities drop) multi host management with a REST api so you can query
> the LXD daemon for container orchestration across hosts and live migration.
> These are big steps forward and they really do need the support of the
> community. They have been doing this for 7 years and is thanks to then
> containers exist.

I'm always surprised when people omit to point out that "the LXC team" is
basically Canonical, the corporate sponsor behind Ubuntu (including the kernel
bits).

People love to bash on the company, it'd be nice to acknowledge the
achievements as well :)

Full disclaimer: I'm a Canonical employee. I hope that doesn't come out as a
corporate shill, I genuinely love LXD.

~~~
contingencies
_I 'm always surprised when people omit to point out that "the LXC team" is
basically Canonical, the corporate sponsor behind Ubuntu (including the kernel
bits)._

Perhaps now, but historically you are very much incorrect. IBM funded it
originally, and it was conceived and implemented (ie. as in they made it reach
the "actually working and in-kernel" state) with the goal of segregating
concurrently executing workloads on fat IBM-supplied mainframes.

------
stephen-mw
Someone here on HN encouraged others to check out LXD in a previous thread a
week ago. I did it and was really blown away. It really did feel like I was
running virtual machines from an extremely fast hypervisor.

What mattered to me most was getting away from "1 process per container"
mentality. Phusion realized right away that this was an unnecessary constraint
and built their base image[0] to help others.

With LXD you really get the best of both worlds. You can containerize your
applications without having to re-write your entire stack because it also
requires cron or a few other processes. Ain't nobody got time for that.

0: [https://github.com/phusion/baseimage-
docker](https://github.com/phusion/baseimage-docker)

~~~
notsony
So should I use LXD or Docker? I just want to package up an app with
dependencies and make it easy for others to use/test.

~~~
rdtsc
Use LXD, it is more flexible.

Can have application structured as multiple processes so can map VM patterns
to it easier, without creating unnecessary containers.

Believe you also get better security between containers

Also LXC has been in the kernel longer and seems more mature (since
2.6.20-something).

~~~
vezzy-fnord
_Also LXC has been in the kernel longer and seems more mature (since
2.6.20-something)._

LXC in the kernel? It's a userspace toolkit that makes use of kernel
technologies (namespaces, pivot_root, cgroups...), but I don't recall it being
bundled as a part of it.

~~~
rdtsc
> LXC in the kernel?

Sorry, I meant LXC support. Yeah it is comprised of a set of a features
supported by regular Linux kernels + userspace tools. The feature set has been
there for a quite a while.

> but I don't recall it being bundled as a part of it.

But it is in contrast to say OpenVZ which required patching the kernel to
work.

------
grumblestumble
Look, man, you just can't have a technology called LXD and ask people to refer
to it as "lex-dee". That's just not right.

~~~
contingencies
Seconded: Steve Jobs just rolled over in his grave.

------
andmalc
I'm surprised no one's mentioned systemd-nspawn which is also for os-
virtualization so more like LXC than Docker.

[https://www.youtube.com/watch?v=d4SwL2t5Yh4](https://www.youtube.com/watch?v=d4SwL2t5Yh4)

Poettering discusses LXC/LXD later in this video.

------
worklogin
>Image based (no more distribution templates, only good, trusted images) - the
LXD website

So instead of "lxc create -t ubuntu -n container1", I'll load a container from
an image (just a monolithic template of sorts)?

~~~
lukaslalinsky
You can use pre-built images even with plain LXC:

lxc-create -t download -n container1 -- -d ubuntu -r trusty -a amd64

LXD just takes it a little further, so on the UI level you are dealing just
with images through the whole life-span of the container, not just when you
are creating it. That makes it possible to wrap it all in a nice API and
automatize the environment.

