Docker 0.9: introducing execution drivers and libcontainer

Mar 10 2014

Ship it!

Fellow Dockers,

Today we are happy to introduce Docker 0.9. With this release we are continuing our focus on quality over features, shrinking and stabilizing the core, and providing first-class support for all major operating systems.

In addition to dozen of bug fixes, Docker 0.9 includes 2 major improvements: execution drivers and libcontainer.

As usual, for a complete list of improvements, you can check out the Changelog.


Execution drivers

First, we are introducing an execution driver API which can be used to customize the execution environment surrounding each container. This allows Docker to take advantage of the numerous isolation tools available, each with their particular tradeoffs and install base: OpenVZ, systemd-nspawn, libvirt-lxc, libvirt-sandbox, qemu/kvm, BSD Jails, Solaris Zones, and even good old chroot. This is in addition to LXC, which will continue to be available as a driver of its own.

There are already several projects underway to develop more drivers. Want to join the fun? Come say hi on #docker-dev on Freenode, and we’ll help you get started.


New default driver: libcontainer


Second, we are introducing a new built-in execution driver which is shipping alongside the LXC driver. This driver is based on libcontainer, a pure Go library which we developed to access the kernel’s container APIs directly, without any other dependencies.

Thanks to libcontainer, 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. To switch back to the LXC driver, simply restart the Docker daemon with docker -d -e lxc. Of course we will continue to support the LXC driver going forward.


Using libcontainer for your Go projects

We have developed libcontainer in the hope that other projects will reuse it. If you’re interested in playing with the native container features of Linux – namespaces, cgroups, capabilities etc – then we encourage you to start hacking! To get started go get the Go package and check out the API docs:


go get

Objective 1.0

This release is a major step towards a stable, production-ready 1.0 release. We plan on making our next release, 0.10, the first release candidate for 1.0.

 As discussed previously, the goals for Docker 1.0 are:

  • production quality

  • first class support of all major operating systems

  • a shrunken core and a stable plug in architecture

  • well documented

  • able to be commercially supported by Docker and our partners

  • Docker able to offer long term support

We are already hard at work preparing 0.10, with several exciting improvements that we think you will like. If you would like a sneak peek, or if you feel like contributing – come say hi! We are on #docker on Freenode. We welcome enthusiasts of all levels and can help you get started with your first contribution. As always, thanks go out to our community of contributors, now 352 strong!

Thanks and happy hacking!


The Docker team




22 thoughts on “Docker 0.9: introducing execution drivers and libcontainer

  1. Avatar for Solomon Hykes

    Jérôme Schneider

    Wow, the work you’re achieving for each revision is impressive, and this time even more than before 🙂

    Thanks a lot docker team !

  2. Congrats guys!! Looks like a very interesting release.

  3. This is awesome. Can’t wait to try it out. Since you’re already looking towards 1.0 and focusing on stability, one thing I don’t see a lot of mention of is the issues with pushing and pulling images. In Australia at least, this is very problematic and the download/upload regularly either fails (unexpected EOF), or just stalls completely. I think that is an important one to focus on, as it is causing real pain and means automated deployments are not really feasible. It probably “just works” in the US. Either an issue with the CDN, something in the middle (firewall dropping connections?) or the client’s error tolerance to network blips.

    • Chris: I totally agree, here in Australia some of the larger images i need to pull i have to simply build from source because it just fails to often.

      It would be awesome to be able to setup a docker registry cache, as i have to use docker on many different machines or new installs, i need to re-download the same images again and again. A caching docker registry server that i can set my machines to use by default would be amazing.

  4. Excellent news, looking forward to trying it out. Thanks to all for the hard work towards bring this forward to v1.0 🙂

  5. I think you may have forgotten to tag this release with the ‘docker releases’ tag, nearly missed it 🙂

  6. Sounds like fantastic progress — congrats! I was curious why you guys chose Go for the execution driver?

Leave a Reply