With the release of version 0.9 Docker.io have dropped LXC as the default execution environment, replacing it with their own libcontainer. At the same time Docker now supports a much broader range of isolation tools through the use of execution drivers, which include: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones, and chroot.
Libcontainer is a library written in Go that provides direct access for Docker to Linux container APIs:
Docker out of the box can now manipulate namespaces, control groups, capabilities, apparmor profiles, network interfaces and firewalling rules - all in a consistent and predictable way, and without depending on LXC or any other userland package. This drastically reduces the number of moving parts, and insulates Docker from the side-effects introduced across versions and distributions of LXC. In fact, libcontainer delivered such a boost to stability that we decided to make it the default. In other words, as of Docker 0.9, LXC is now optional.
LXC itself recently announced the release of version 1.0. Whilst Docker can still be used in combination with LXC it’s likely that most users will run with the new default that omits LXC.
The execution driver API opens the door to running Docker on non Linux systems such as FreeBSD, Solaris, OpenSolaris and illumos. Support for OpenVZ and qemu/kvm should also be of interest to hosting providers who have traditionally used those platforms to provide virtual private servers (VPS). Whilst chroot offers something of a lowest common denominator environment for all Unix operating systems, it’s likely to be the path of least resistance for a native OS X implementation that avoids the use of virtual machines running Linux. Docker on Windows also now looks much easier from a technical perspective, and hence likely to happen sooner.
The Docker.io announcement also provides more clarity on the release roadmap. The next release, 0.10, which is due in April, will be the first release candidate for 1.0.
Red Hat have announced a Container Certification programme for independent software vendors (ISVs) to take advantage of containers in the Docker format.
Docker containers can also now be run within Cloud Foundry environments with the aid of CloudCredo’s Decker tool. Decker provides a Cloud Foundry droplet execution agent (DEA) that is able to host Docker containers rather than the Warden containers generally used by Cloud Foundry.
