Today we are happy to introduce Docker 0.8, with a focus on Quality and 3 notable features: new builder instructions, a new BTRFS storage driver, and official support for Mac OSX. You can see the full Changelog on the repository, and read below for details on each feature.
This release is special in several ways:
First, this is the first Docker release where features take the backseat to quality: dozens and dozens of bugfixes, performance boosts, stability improvements, code cleanups, extra documentation and improved code coverage – that’s the primary feature in Docker 0.8. We still have ways to go, and there are still many open bugs! But we are making progress and will continue to focus on Quality until it becomes a defining characteristic of Docker.
Second, this release marks the beginning of a new release cadence, which we hope you will find simpler and clearer. It’s a very simple cycle:
One release per month. Every first week of the month, we release a new version of Docker. For example, in the first week of March we will release 0.9.
Master always works. We only merge patches which we consider ready to be released. And we only release what is in master. This makes it very easy to test upcoming features or distribute a “bleeding edge” version of docker. Simply build from master and you will get the current release candidate.
Not feature-based. Release dates are not linked to any specific features. If a feature is merged before the release date, it gets released. Otherwise, the next merge window is only a month away.
Simple numbering. We follow the Linux convention for numbering versions. The first digit indicates a major change in the project’s lifecycle. For example, 1.0 indicates that the project is considered ready for production use. The second digit indicates regularly scheduled releases. The third digit is reserved for hotfixes, stability backports etc.
Lastly, this release marks the beginning of our support for platforms other than Linux on 64bit x86. With Docker 0.8 we are focusing on Mac support – but expect us to start supporting more and more platforms over the next few releases. As many of you have pointed out, “run anywhere” is only useful if you can actually, you know… run anywhere
Thank you to the entire Docker community, and happy hacking!
The Docker team
A special thank you to the 128 people who participated in this release, including but not limited to: Paul Tagliamonte, Lokesh Mandvekar, Josh Poimboeuf, Steeve Morin, Brandon Philips, Thatcher Peskens, Paul Nasrat, Roberto Hashioka, Johan Euphrosine, Danny Yates, Brian Goff, John Feminella, Jonathan Rudenberg, Josh Hawn, Joffrey Fuhrer, Maxime Petazzoni, Alex Larsson, Charles Lindsay, Bartłomiej Piotrowski, Gabriel Monroy, Sam Alba, Johannes Ziemke, Graydon Hoare, Andrews Medina, Peter Waller, Tzu-Jung Lee, Silas Sewell, Marek Goldmann.
We would also like to welcome several new maintainers on board: Sven Dowideit, Cristian Staretu and James Turnbull. Thank you for investing so much of your time and energy in the sometimes unglamorous work of maintaining such a young and active project, warts and all. And a special thank you to Andrew “Tianon” Page who has been a de facto maintainer since the 0.6 releases and has been essential to making Docker what it is.
And lastly, a big thank you to the maintainers of the Docker hosted infrastructure: without them keeping the public registry, website, authentication and other essential services running 24/7, Docker would be much less useful and not nearly as fun to use. So thanks Sam, Ken, Jerome, Johannes, Dustin, Josh, Thatcher, Daniel, John and Joffrey!
Docker 0.8 is the first release to be defined primarily by quality improvements. Sure, it packs cool features – but the majority of the work happened under the hood, one small incremental improvement at a time. With the precious help of many contributors who volunteered countless hours of debugging, support, patching and refactoring, we are inching our way towards our goal: making Quality one of the defining qualities of Docker – something that is not just “good enough”, but one of the reasons people use Docker.
We still have a lot of work to do to reach that goal – but we are making progress! Here are some of the quality improvements in Docker 0.8:
Images and containers can be removed much faster
Building an image from source with docker build is now much faster
The Docker daemon starts and stops much faster.
The memory footprint of many common operations has been reduced, by streaming files instead of buffering them in memory, fixing memory leaks, and fixing various suboptimal memory allocations.
Several race conditions were fixed, making Docker more stable under very high concurrency load. This makes Docker more stable and less likely to crash and reduces the memory footprint of many common operations.
All packaging operations are now built on the Go language’s standard tar implementation, which is bundled with Docker itself. This makes packaging more portable across host distributions, and solves several issues caused by quirks and incompatibilities between different distributions of tar.
Docker can now create, remove and modify larger numbers of containers and images graciously thanks to more aggressive releasing of system resources. For example the storage driver API now allows Docker to do reference counting on mounts created by the drivers.
Many components have been separated into smaller sub-packages, each with a dedicated test suite. As a result the code is better-tested, more readable and easier to change.
New builder features
Docker 0.8 improves the docker build command in several cool ways:
This is by far the most requested builder feature. The ADD instruction now supports caching, which avoids unnecessarily re-uploading the same source content again and again when it hasn’t changed. This, in turn, can speed up builds considerably, especially in a development cycle where the same container is built very often.
In practice, if your Dockerfiles use the ADD instruction (and they probably should), Docker 0.8 may reduce your average re-build time by up to several minutes, depending on the amount of processing involved in your build.
The new ONBUILD instruction adds to your image a “trigger” instruction to be executed at a later time, when the image is used as the base for another build. The trigger will be executed in the context of the downstream build, as if it had been inserted immediately after the FROM instruction in the downstream Dockerfile.
Any build instruction can be registered as a trigger.
This is useful if you are building an image which will be used as a base to build other images, for example an application build environment (sometimes known as “buildpacks”) or a daemon which may be customized with user-specific configuration.
You can find more details on the ONBUILD instruction in the official documentation.
BTRFS storage driver
Docker 0.8 now ships with an experimental storage driver which uses the BTRFS filesystem for copy-on-write. BTRFS is a relatively recent filesystem which has been gaining traction in the Linux community – it is usually presented as an alternative to the ZFS filesystem. Although it is still considered experimental, it has a loyal and growing following in the Linux sysadmin community.
This driver is experimental and disabled by default. If you want to try it, you can start the docker daemon with docker -d -s btrfs
Note that the BTRFS driver will only work if Docker is running on a BTRFS partition already prepared by the host system. Unlike the devicemapper driver, it will not automatically create a new dedicated partition.
Mac OSX support
Starting with version 0.8, Docker is officially supported on Mac OSX. This allows sysadmins and developers to build and run Linux applications as Docker containers, directly on their Mac machine.
Installing Docker on a Mac is a 2-step process:
First, install the Docker binary which will forward all commands to a remote docker daemon
Second, install Boot2Docker, which is a super-lightweight Linux VM capable of running a docker daemon on your Mac with the smallest possible overhead. Currently it occupies 24MB on disk and boots in less than 10 seconds.
The combination of a native Docker client and a super-lightweight VM gives us the best of both worlds: you can run Docker completely offline, without depending on an outside machine – and you can still run the exact same containers that will later be deployed in production to your Linux servers.
For the full instructions on how to install Docker on a Mac, see the official docs.