What’s New in Docker 1.13


Docker just released version 1.13 of Docker Engine, which is full of new features to make deploying highly available services even easier. It also introduces some commands and workflows to improve the developer experience for Docker users. You can see the full release notes on GitHub, but here’s a summary of a handful of interesting updates.

Orchestration updates

Docker 1.13 includes a handful of improvements and updates for running your services in Swarm Mode. You can now pin images by digest for rolling updates (which is more specific than tags), and your services have better logging during image pulls to reduce the amount of noise and logspam in the logs. Experimental support for docker service logs was also added in 1.13, so now there’s an easier way to view logs for services running on your cluster.

You’ll also see more visibility into errors for tasks scheduled on your Swarm cluster, including better error messages. The scheduling algorithms have been updated to distribute the same types of tasks a bit more evenly.

Let’s say you have two containers running service A and three containers running service B. The most undesirable situation is that in a two-node cluster, all containers running service A are scheduled on one node and all Service B containers are on the other. If one node goes down, one of the services is completely unavailable. Tweaks to the scheduler ensure that type of workload distribution is avoided.

A new prune command to keep your system healthy

If you’re like me, docker ps -a | grep 'Exited' | awk '{print $1}' | xargs docker rm (or the more extreme docker rm -f $(docker ps -aq)) and `docker rmi -f $(docker images -q) are commands you fire off multiple times a day to keep your workspace clean.

Docker 1.13 introduces the prune command, which helps you keep your system healthy and reduce the footprint of Docker by easily deleting unused resources. Running docker system prune will remove all stopped containers, unused images, and unused networks volumes in one fell swoop.

If you find the long rm commands more enjoyable, don’t worry, they still work, but prune makes it easier. I’ll get in the habit of using prune and keep those long commands in the same place in my brain where I store Doom cheat codes.

!New Call-to-action

Restructured CLI

Docker has grown a lot over the last few years, and each release adds something new and exciting to the CLI. Unfortunately, a side effect of this rapid development was a sometimes unwieldy CLI that was hard to understand for people new to Docker. In Docker 1.13, the CLI has been restructured to focus all commands on top-level resources. The biggest change is that you’ll find docker container as a management command for your containers. The old syntax will still work for now, but Docker encourages every user to start interacting with the CLI using the new management commands.

Build and caching improvements

Cache poisoning is a real threat, and beginning in version 1.10, Docker introduced features to protect your images from cache poisoning when using images pulled from remote registries. Before 1.10, the image layers pulled from a remote registry were not used when new images were built on the same host. However, this also applied to images you pull from a trusted source.

In Docker 1.13, you can use the new runtime flag --cache-from to specify that you want your image to be rebuilt using the image cache associated with an image pulled down from a remote registry. It’s up to you to decide whether the image cache is trustworthy and protect yourself against cache poisoning.

Additionally, docker build has two new flags: --compress and --squash. Compress will compress your build context when it’s sent to the daemon, which can speed up your image builds. The --squash flag is still experimental, and it will squash the image into one layer. This can simplify the build process a bit, but might make it harder to work with your images if you heavily rely on caching.

Docker Compose V3 syntax

Docker 1.13 includes something brand new — an updated and extended version of Docker Compose syntax. Labeled as V3, this syntax is a bit unique because it’s intended to be used to deploy Docker services to a Swarm cluster. It has a lot in common with V2 but should be treated as a separate domain language.

Using a V3 file, you can easily deploy to a Swarm cluster via docker stack deploy --compose-file=docker-compose.yml. V3 syntax can help unify your Docker Compose files and make it easier to switch between development and production environments. If you’re interested in the specifics of the V3 schema, the configuration is available in the docker/compose GitHub repo.

Want to tinker with 1.13? If you’re using Docker for Mac and Windows, you’ll be notified of an update. Otherwise, you can install Docker on any flavor of OS via the installation instructions in the documentation.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • Pingback: สวัสดี Docker 1.13.0 กันเล็กน้อย()

  • Chesley Brown

    Does the new –cache-from help Codeship with caching? Will we see any improvements on build times?

    • Short answer: probably. We got into a bit of trouble with our first caching implementation because we relied so heavily on Docker for caching, which is a core component of our build system. We’re still evaluating whether switching back to a registry-based caching system is the right and most stable choice. If we do it, you’ll get private beta access!

  • Thiago Felipe Peçanha

    Awesome post. Could you tell what is your thoughts about ‘docker secret’ command? Specifically using it with SSH-keys.


  • Pingback: 敲黑板,划重点:Docker 1.13更新有哪些看点?【zoues.com】 | zoues()