A Quick Introduction to LXD

http://blog.scottlowe.org/2015/05/06/quick-intro-lxd/

by tych0 • 11 years ago

142 37 11 years ago

blog.scottlowe.org

worklogin• 11 years ago

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)?

otoburb• 11 years ago

Isn't that the same approach that Docker originally took with the Docker Hub Registry, where you can pull down pre-packaged monolithic images (albeit small ones if needed) via "docker pull ..."?[1]

I think this was important quote from the article: "LXD is more like an “OS container” while Docker and rkt are more like “application containers.”"

[1] https://docs.docker.com/userguide/dockerimages/

lukaslalinsky3• 11 years ago

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.

stephen-mw4• 11 years ago

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

notsony3• 11 years ago

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.

stephen-mw4• 11 years ago

Without a doubt use Docker. It has the ecosystem, which is extremely important. It also has the support and community.

For devops engineers looking to build an entire enterprise around containers, LXD will be a great option when it reaches maturity and its ecosystem matures. It's not there yet, and probably won't be for a few years.

Another great company that's doing extremely cool things with LXC minus Docker is Flockport[0]

[0] http://www.flockport.com/

jaytaylor2• 11 years ago

You could also write an Ansible role for your app which automates the setup and installation. Then installing your app becomes as simple as a single Ansible command without additional dependencies.

jcastro• 11 years ago

If you just want to package an app use docker.

The general rule of thumb I use is "Will I need to ssh into this?" If so, LXD. "Am I just running one application?" Docker.

rdtsc4• 11 years ago

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).

altcognito4• 11 years ago

What mattered to me most was getting away from "1 process per container" mentality. Phusion realized right away that this was an unnecessary constraint

It's a necessary constraint because otherwise developers continue to utilize a monolithic application development process. The goal should be isolated, interchangeable processes, not an entire virtual environment. It's just delaying the inevitable. Makes scaling a lot more straightforward as well etc...

rdtsc4• 11 years ago

But since they can have only one process they will cram everything in that process. Possibly spawning hundreds of threads with mutexes.

Multiple processes on the other hand can encourages fault tollerance and modularization.

To put it another way, having just one process doesn't mean it is simpler. I have seen single processes applications built from millions of lines of C++ code.

GrinningFool• 11 years ago

If you want to have a single process that you care about, there is this thing called a process that fits the bill admirably. You can start them up very quickly, and kill them when you don't need them.

I think Docker is a great tool, but I also think the perceived benefits it brings get discussed a lot more often than the complexities it introduces.

Pushing your complexity to different parts of your stack does not reduce it - it just moves it. In many cases, that's perfectly fine and works better - but it's no panacea.

jacques_chester• 11 years ago

What mattered to me most was getting away from "1 process per container" mentality.

As I understand, when Garden used to be called Warden, the team looked at the very early versions of Docker. They talked to the Docker team and didn't decide to use Docker as the substrate of Cloud Foundry because of the single-process model. Makes it hard to sideload agents.

That said, the next-gen Cloud Foundry guts (Diego) can take Docker images as native currency, so YMMV.

tobbyb• 11 years ago

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

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

stephen-mw4• 11 years ago

I think Flockport is doing some amazing things. When I read the pagerduty bug-hunt post and saw that they were using ipsec between "hosts", I wondered if perhaps they used LXD with some of your services.

tribaal• 11 years ago

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.

contingencies4• 11 years ago

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.

icebraining2• 11 years ago

They have been doing this for 7 years and is thanks to then containers exist.

Well, no, Linux containers have existed for longer, in the form of OpenVZ. I find it pretty funny that they are now considered "new" :)

Besides unprivileged containers, which I suppose can be useful for some use cases, what's the great advantage of LXD vis-a-viz OpenVZ, which is a more mature and well-understood technology?

contingencies4• 11 years ago

Linux containers have existed for longer, in the form of OpenVZ.

Also Linux-vServer, yadda-yadda. Not only OpenVZ.

what's the great advantage of LXD vis-a-viz OpenVZ, which is a more mature and well-understood technology?

OpenVZ took approaches that meant it would never be accepted in to the Linux kernel. This means, frankly, that it is dying as people move to LXC, whose components are in the kernel. Claiming something is 'mature and well-understood' that is essentially destined to become a footnote in history may be correct, but it's also rather short-sighted and increasingly irrelevant.

grumblestumble• 11 years ago

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.

contingencies4• 11 years ago

Seconded: Steve Jobs just rolled over in his grave.

andmalc• 11 years ago

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

Poettering discusses LXC/LXD later in this video.

A Quick Introduction to LXD

Related Stories