What’s New in Docker 1.13

Written by: Laura Frank Tacho
5 min read

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.

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.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.