Solomon Hykes

Docker 0.10: quality and ops tooling

Solomon Hykes

Today we are happy to introduce Docker 0.10. We hope you will like it!

We’d like to thank all the awesome community folks who contributed to this release: Tianon Gravi, Alexander Larsson, Vincent Batts, Dan Walsh, Andy Kipp, Ken Ichikawa, Alexandr Morozov, Kato Kazuyoshi, Timothy Hobbs, Brian Goff, Daniel Norberg, Brandon Philips, Scott Collier, Fabio Falci Rodrigues, Liang-Chi Hsieh, Sridhar Ratnakumar, Johan Euphrosine, Paul Nasrat and all the awesome folks at Docker.

This release is the next step on the road to Docker 1.0. The changelog is particularly large, with a dominant focus on quality and improving ops tooling.


Firstly, we’ve continued our focus on quality as we near 1.0. This release includes the results of a week-long sprint where we fixed bugs, improved testing and documentation, cleaned up UI glitches, and so on. In that week alone we closed 48 tickets and merged 68 pull requests. Here is a small sample:

  • A new integration test harness will help us limit any regressions on the command line interface.

  • Output issues during ‘docker build’ have been fixed

  • Various performance and stability issues when running thousands of containers on the same machine have been fixed.

  • Symlink handling during ‘docker build’ has been fixed

  • The ‘docker build’ command can use client credentials when pulling private Git repositories

  • Multiple reliability and performance improvements to devicemapper storage

  • Caching issues during ‘docker build’ have been fixed

  • `df`, `mount` and similar tools can now be used inside a container

  • ‘docker build’ can now call commands which require MKNOD capabilities

  • Dozens of minor documentation improvements

  • Better test coverage across the board

  • Shell completion has been fixed

  • tmux and other console tools can now be used inside a container

  • Content detection in ‘docker cp’ has been fixed

  • The lxc execution driver works with lxc 1.0

  • Issues with high-throughput allocation of network ports have been fixed

  • ‘docker push’ now supports pushing a single image to the Docker index instead of all tags

  • The content and volume of error messages has been made more readable

  • Issues with ‘docker run –volumes-from’ have been fixed

  • Apparmor issues on certain versions of Ubuntu have been fixed

  • Race conditions, slow memory leaks and thread leaks have been fixed

  • The output of some commands is sorted to be more predictable

As you can see, some of these issues are individually quite small. But in aggregate, they make a big difference! We plan on continuing to fix issues, large and small, over the next releases. If there’s an issue you would like us to address faster, please bring it to our attention! You can always open an issue or comment on an existing issue to express your interest. And of course you are looking to contribute, we will be happy to point you to issues which need attention, and help you get started. Come say hi on the #docker IRC channel on Freenode!

Ops tooling

With this release we are starting a new phase in our march to 1.0: ops-readiness. To be used in production, it’s not enough for Docker to not crash. It needs to integrate well with the tools sysadmins use today: logging, system initialization, monitoring, remote administration, backups, etc.

Obviously we won’t reach this sysadmin-friendly nirvana in just one release, but with 0.10 we are taking several important steps in that direction:

  • Stop behavior: The default behavior of ‘docker stop’ has been changed to err on the side of “application safety”. Specifically, if an application fails to respond to the SIGTERM signal, docker will return an error instead of force-killing it with SIGKILL. This means ‘docker stop’ can safely be used on the most critical or brittle applications without the risk of data corruption or other side effects. (Note that you should still design your application to be resilient to abrupt termination – Docker cannot prevent power cords from being pulled!)

  • Signal handling: The Docker daemon itself now handles signals in the same way. When receiving SIGTERM, Docker will forward it to all running containers, wait for them to gracefully exit, then exit. If containers fail to exit gracefully, Docker will transparently expose that behavior and wait forever. It is then up to the external tool to choose between 1) waiting further, 2) giving up, or 3) force termination with SIGKILL. Note that because of how SIGKILL works, Docker cannot forward it to the application: instead it detects “orphaned” containers the next time it starts, and sends the SIGKILL now. In short: Docker never, ever sends SIGKILL to a container unless it receives SIGKILL itself.

  • TLS auth: One feature which has been requested many times is the ability to expose the Docker remote API over the network in a secure way. That is now possible with Docker 0.10, with built-in support for TLS/SSL certificate security. You can now use SSL certificates to retrict access to the API to only those hosts or users with the appopriate certificate. This is only the first step in securing the Remote API and we have plans in the future to provide more granular role-based access control as well as other forms of authentication.

  • Systemd slices: Docker now ships with a systemd plugin, which automatically detects when the underlying host has been initialized by systemd. If systemd is detected, Docker will automatically use the low-level systemd APIs to manage control groups, instead of the default behavior of accessing /proc directly. For sysadmins currently using the systemd tools to manage resource allocation, this means that individual Docker containers will show up automatically in those tools.

  • Release hashes: Every release of Docker now includes SHA256 and MD5 hashes of all build artifacts. These will be published on the documentation site and download page, allowing you to verify that your installation has not been tampered with. For example you can verify the SHA256 of the official Linux and Darwin binary builds with the following command:



Finally, with the release of Docker 1.0 in the near future, we would ask that you aggressively test Docker 0.10. Please log tickets and let us know your feedback!

Thank you everyone for your support and help, and happy hacking!

The Docker maintainers

Continue reading...


7 thoughts on “Docker 0.10: quality and ops tooling

  1. Erlend Sogge Heggen

    Very impressed with your steady pace. Maybe some of these details can be added to

  2. Awesome! Looking forward to a kick-ass Docker 1.0! Keep up the great work!

  3. Don’t mean to be a nit-picker, but did you mean to tag this under the “Docker releases” category as well? 🙂

Leave a Reply