PARIS — Sometimes it seems that Canonical, Ubuntu's parent company, can't win for losing. Often accused of trying to force other open-source groups to follow their lead by keeping projects internal until they feel it's ready to be shared with others, when Ubuntu announced its intention to build , at the OpenStack Summit, the company was immediately accused of announcing vaporware (!); of shoving LXD down other programmers' throats; and of trying to replace Docker.
I spoke with Mark Shuttleworth, Canonical and Ubuntu's founder, and Dustin Kirkland, Canonical's product manager, at the conference, and here's really what's going on with LXD.
First, on the technical side, LXD, pronounced Lex-Dee, is an expansion of LXC, the Linux container tecnology behind Docker. Specifically, according to Stéphane Graber, an Ubuntu project engineer, LXD is a "daemon exporting an authenticated representational state transfer application programming interface (REST API) both locally over a unix socket and over the network using https. There are then two clients for this daemon, one is an OpenStack plugin, the other a standalone command line tool."
Its main features are to include:
- Secure by default (unprivileged containers, apparmor, seccomp, etc.)
- Image based workflow (no more locally built rootfs)
- Support for online snapshotting, including running state with Checkpoint/Restore in User (CRIU)
- Live migration support
- Shell command control
The goal, according to Ubuntu, is a new hypervisor system in which LXC will be the client, LXD the server. In addition:
We’re working with silicon companies to ensure hardware-assisted security and isolation for these containers, just like virtual machines today. We’re working to ensure that the kernel security cross-section for individual containers can be tightened up for each specific workload. We’ll make sure you can live-migrate these containers from machine to machine. And we’re adding the ability to bind storage and network interfaces to the containers, just like virtual machines.
It's not all peaches and cream, Ubuntu continued:
LXD is only for Linux on Linux. You’ll be able to run LXD on Ubuntu and spin up instances of RHEL, CentOS, SUSE, Debian, Ubuntu and just about any other Linux too, instantly, but if you want to run Windows, then you’ll need a traditional hypervisor like KVM or ESX.
In particular, LXD is being design first to work for OpenStack. Canonical claims it will give OpenStack administrators "All the agility of OpenStack, all the performance of your metal with no virt overhead."
Oh, and Docker?
Docker is an amazing application delivery mechanism, which we think is changing the world of devops forever. For the most efficient way to deliver your binaries to a platform for execution, docker is the dance for us. LXD and docker share some underlying kernel capabilities, we hope to bring much of the awesome security and isolation of LXD to docker as well.
As a validation point, we’re delighted to share the cunningly codenamed nova-compute-flex driver in Ubuntu OpenStack for Juno, and commit to steering this into upstream OpenStack for Kilo or M. The driver allows OpenStack instances to be scheduled as Linux Containers. Images are booted from OpenStack’s image service, Glance, and instances communicate over Neutron’s networking functionality. The next step is to utilise storage from Cinder and Ceph.
To try it, you must get the Ubuntu spin on OpenStack Juno by downloading and installing Ubuntu Server 14.04 LTS or 14.10. Then, run the following commands from a shell terminal:
sudo add-apt-repository cloud-archive:juno
sudo apt-get update
sudo apt-get install nova-compute-flex
And then you'll ready to give it a try. While playing around with it, I was able to switch a running instance of a game of Doom from one container to another with about a second and a half of lag.
Enterprise ready? No. Promising? Yes.
In our conversation Shuttleworth spelled out that, "Docker and LXD are not at odds with each other. You can run Docker inside LXD technology. We've had friendly conversations with Docker and they're happy focusing on apps while we focus on infrastructure. We see LXD as being complementary with Docker, not a replacement."
The difference between LXD and a traditional virtual machine (VM) hypervisor, said Kirkland, is that "With Xen or KVM you create a space in memory where you emulate a PC and then you install the kernel and the operating system. There's only one kernel, the host kernel. instead of running another kernel in memory space, you just run say a CentOS file system."
So while LXD will take up more resources than a pure container, it won't take up as much memory room as a VM approach. In addition, an LXD container will have access to the resources and speed of the hardware without a VM's need to emulate hardware.
The processes within LXD will be tightly coupled together so that they won't be exposed to those of a neighboring LXD container on the same server. To help make this happen, Canonical is working in conjunction with silicon vendors to implement hardware security hooks for the LXD API to work in concert with.
Shuttleworth wouldn't say who the vendors were. He did note, however, that AMD and Intel long ago added technologies to their chips to make them work better with hypervisors. For AMD this is AMD-V and for Intel it's Intel Virtual Technology (VT). He added that LXD would still provide improved container security even if a particular chipset didn't natively support it.
As for other vendors and developers, Kirkland said that LXD is an open project that anyone and everyone is welcome to work on.
Are there other possible solutions for hardening containers? Certainly. Is LXD a worthwhile approach that also deserves consideration? Yes, yes it is.