We are happy to announce updates to Docker Engine, Registry, Compose, Swarm, and Machine. We are releasing them all at the same time so you can test and roll them out together, and so that we can ship features that span multiple tools. The features in this release are designed to improve the dev experience with faster image pulls, a preview of Docker client for Windows, and support for apps beyond the dev environment in Compose.

Docker Engine 1.6

The Docker Engine has been greatly improved since 1.5, with some highly requested features in addition to Windows Client support. We could not have created such an amazing release without the help from awesome contributors. You can get started by downloading Docker Engine 1.6 and checking out the changelog here.

Now let’s check out what’s new in Docker Engine 1.6.

Container and Image Labels

Labels allow you to attach user-defined metadata to containers and images that can be used by your tools. This feature has been proposed time and again. The community has now reached consensus on a design to handle the majority of use cases, so it is being released as part of Engine 1.6.

Thanks to Darren Shepherd, who contributed the patch. If you are interested in more on this feature, you can view the pull request here or read Darren’s blog post to see how labels are used in Rancher.

Windows Client Preview

We have been very fortunate to have the collective effort of a few awesome Microsoft engineers to help us get the Docker Windows Client ready for an official release. It’s interesting to realize how much of your software is programmed for a certain operating system, so we are thankful to have the Windows expertise available to help guide us through the process.

The Windows Client can be used just like the Mac Client is today with a remote host. We even scaled out our testing infrastructure to accommodate Windows Client testing on every PR to the Engine.

Logging Drivers

There have been a growing number of proposals for a logging driver API that would allow you to send container logs to other systems such as Syslog or a third-party. This new logging driver follows the exec driver and storage driver concepts already available in Engine today.

There is a new option to docker run, --log-driver, which has three options:json-file (the default, and same as the old functionality), syslog, and none. The syslog driver patch was only 70 lines long — hopefully that is a testament to how easy it will be to add others to the mix in the future. Be sure not to overlook none; in the case of certain heavily verbose apps where you do not care about logs (ex. irssi), none is perfect.

Thanks to Alexander Morozov for this patch. To get more information, read the original pull request for logging drivers here and the syslog patch here.

Content Addressable Image Identifiers

When you pull, build or run images, you specify them in the form namespace/repository:tag, or even just repository. With the addition of a patch by Andy Goldstein, you are now able to pull, run, build and refer to images by a new content addressable identifier called a “digest” with the syntax namespace/repo@digest. Digests are an immutable reference to the content that is inside the image.

A great use case for the digest is around applying patches and updates. If you want to roll out a security update, you can now specify the exact digest of the image with the security update in it, guaranteeing that the server is running the security update.

This feature is only supported by the v2 registry. To read more about this patch, refer to the pull request here. You can read the documentation here.

‒‒cgroup-parent

Containers are made from a combination of namespaces, capabilities, and cgroups. Docker already supports custom namespaces and capabilities. Additionally, in this release we’ve added support for custom cgroups. Using the --cgroup-parent flag, you can pass a specific cgroup to run a container in. This allows you to create and manage cgroups on their own. You can define custom resources for those cgroups and put containers under a common parent group.

Thanks to Vish Kannan for the patch. If you want to know more, read the pull request here.

Ulimits

Up until now, containers inherit the ulimit settings from the docker daemon. This tends to be extremely high to account for production workloads, but is not ideal inside the container. Ulimits allow you to limit the resources of a given process (you may be familiar with the command line tool ulimit). With this new feature, you can now specify the default ulimit settings for all containers, when configuring the daemon. For example:

docker -d --default-ulimit nproc=1024:2048

This will set a soft limit of 1,024 and a hard limit of 2,048 child processes for all containers. You can set this option multiple times for different ulimit values: --default-ulimit nproc=1024:2408 --default-ulimit nofile=100:200

These settings can be overwritten when creating a container as such:

docker run -d --ulimit nproc=2048:4096 httpd

This will overwrite the default nproc value passed into the daemon.

Thanks to Brian Goff for this patch. If you are interested in the original pull request you can view it here.

Dockerfile instructions can now be used when committing and importing

Last but not least in our awesome list of features for Docker Engine 1.6 is the ability to make changes to images on the fly without having to re-build the entire image. The feature commit --change and import --change allows you to specify standard changes to be applied to the new image. These are expressed in the Dockerfile syntax and used to modify the image. The supported Dockerfile instructions are listed in the docker commit and docker import docs here.

Thanks to Dan Walsh for the patch. If you want more info, check out the pull request here.

Registry 2.0 + Engine 1.6 = Faster image pulls

Thanks to a completely rearchitected Registry and a new Registry API supported by Engine 1.6, image pulls performance and reliability have been enhanced. This is supported by the Docker Hub today, and we’re also releasing Registry 2.0 if you want to run a self-hosted version. Read more on this blog post.

Compose 1.2

Compose is a tool for defining and running complex applications with Docker. Today we’re also releasing Compose 1.2. It includes a cool new feature that allows you to extend services in other Compose files so you can define different environments without repeating yourself. And – of course – there are loads of other new things too. Check out the blog post to read more.

Swarm 0.2

Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual host. Swarm 0.2 is building on top of the 0.1 release made back in February. It includes a bunch of new things:

Spread strategy:A new strategy for scheduling containers on your cluster which evenly spreads them over available nodes.

More Docker commands supported: More progress has been made towards supporting the complete Docker API, such as pulling and inspecting images.

Clustering drivers: There are not any third-party drivers yet, but the first steps have been made towards making a pluggable driver interface that will make it possible to use Swarm with clustering systems such as Mesos.

Machine 0.2

Machine makes it really easy to create Docker hosts on your computer, on cloud providers and inside your own data center. Machine 0.2 is one more step towards a stable version of Machine. The main focus has been on improving stability and extensibility, including:

Cleaner driver interface: It is now much easier to write drivers for providers.

More reliable and consistent provisioning: Provisioning servers is now handled centrally by Machine instead of letting each driver individually do it.

Regenerate TLS certificates: A new command has been added to regenerate a host’s TLS certificates for good security practice and for if a host’s IP address changes.

Conclusion

We are super excited about this platform release and are looking forward to the future. Thanks to all the contributors to all projects — we could not have done this without you. And of course, we would like to thank everyone for testing the release candidates and finding and filing issues. We really hope you enjoy this release. Contributors and maintainers: we will see you all on IRC. Thanks again to all those involved!