This is what makes LXD so nice. It's the power and flexibility of a VM with the speed, api, and runability of containers.
I always hated that docker forced you to treat a container as a single process and spoke about it as if it's a virtue. Let me decide how many or little processes I want running in a container. Even google runs ssh server alongside their applications.
With LXD you can easily port entire services over to containers without completely rewriting the way they behave.
The security around the containers still isn't as good as a hardware VM, but I think hardware segregation is on the road map.
It's ideal for running container inside VMs, though, and offers nice management segregation on those larger VMs.
However, the development of Zones and Jails (on SunOS/Solaris/illumos and FreeBSD) was much more security focused, with the default being "that's not allowed in a (Jail|Zone) until we can make sure it's safe". I really wish Linux had just ported Jails or inspired their security model on them.
I do a lot of work with the internals of Docker and runC at SUSE. Trust me, it's not pretty how you have to set up "Linux containers" and there's 1001 gotchas.
You can have as many processes as you like running inside a Docker container, you just a need a single process to "boot" them, even if it's a simple shell script.
Docker can't currently do that, largely because running a distro in a container isn't an important goal for them.
docker run -dt --stop-signal=$(kill -l RTMIN+3) -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name centos7_systemd vlisivka/docker-centos7-systemd-unpriv
Mark Shuttleworth's normally responsive on Google+, and he helped point me in the right direction with initial issues that I encountered.
Stéphane and the team have also been helpful on Github with issues.
The first thing I struggled with in this containers business was "what's the difference between LXC/LXD and Docker et. al.?", and I am glad that he addressed it first in the post.
I've got north of 20 containers on our machines, and LXD allows me to create a container, play around with software config on it, and when I get it right; I just leave that container and update it regularly like the host it's on.
That said, my workflow for testing anything these days is inside a vagrant lxc box. it is well worth the lack of images for the improved workflow.
I build out major productions systems on top of LXC at Heroku, and to this day it is still working incredibly well.
So I am really looking forward to further iterations of the tools by Stéphane Graber and co at Canonical.
The main thing that jumps out at me is a REST API for this layer. A REST API with Golang bindings to run containers feels so much better than old-school systems programming with exec.
I'm currently all in on Docker in production for this very reason. Coordinating stuff with a golang client over HTTP is really really productive.
I can kinda understand their point of view, there's no simple solution that will please everyone. But most developers or IT folks aren't networking experts, and LXD won't be an intuitive tool for them without a simpler mode of operation.
I ended up choosing to use bridging to connect all the physical network adapters to the ones in the containers. This is nice because I set up each container with its own IP address, which travels with it when the container is moved to a new host.
Really, no expertise is required. Just basic understanding how the heck the
network works. If somebody can't grasp what bridge interface is or how NAT
operates, he apparently doesn't have the qualifications for writing software.
At its simplest, LXD is a daemon which provides a REST API
to drive LXC >containers.
If you don't know what LXC is maybe this isn't clear. But LXC stands for LinuX Containers, and is extremely fundamental technology in the containerization space.
> LXC stands for LinuX Containers, and is extremely fundamental technology in the containerization space.
LXC was amoung the first pieces of software to take advantage of namespaces when they were added to the kernel; but LXC is not often used. Most of the various containerisation software now available does not use LXC, and it not based on the same codebase.
But then, as I am about to run Linux software inside of an lx-branded zone on SmartOS, I realize that SmartOS has 15,000 packages, with most the of the software I would have run on Linux, available natively on SmartOS:
...so then, which operational advantages would LX containers on Linux offer me, that I already do not have on SmartOS with zones?
Also, Googling "linux rut" doesn't bring up anything useful, I'm assuming you mean rkt
I know how to manage machines. I don't have the same confidence for Docker-images.
LXD seems to be a construction on top of LXC to make managing it easier "at scale", so if all you want is to manually be able to construct "container VMs" on demand, I think LXC is closer to what you actually want: It let's you manage the containers directly, near the iron, without anything getting in your way.
Don't get me wrong: LXD seems to have a genuine value-proposal, but for this use-case it seems to be a slight step of indirection, and my guess is that this will cause you more troubles than it's worth.
I want to understand how Linux Container works, started to study the cgroup code in Linux kernel and LXD. Here are couple of notes on Tracing the code of CGroup in Linux kernel and LXD I took.
(Google gets it right, presumably because of all my code searches.)
"[...] a 2010–2011 web series about two groups of rival dancers: The Alliance of the Dark who are the villains and The Legion of Extraordinary Dancers, the heroes, who discover they have superpowers referred to as 'the Ra' through their dance abilities."
You can control remote instances of the LXD daemon, but there's no syncing back and forth from Host1-LXD1 to Host1-LXD2...they operate separately. You can migrate a container from one host to the other, but it's pushing everything (config/image/etc) when you ask it to migrate.
So, it's not clustered itself, and it keeps the important info somewhere that's hard to cluster.
It would be interesting if they would replace the local sqlite store with something similar to etcd. That still leaves the issue of the disk images though.
Proxmox does cluster LXC, so there's that option.
I would love to see an LXD container driver for Mesos.
Do any of you know if LXD is APPC-spec compliant?
LXC containers aren't app containers. It is intended to be used with regular installs, not with single applications.