What’s New in Docker 1.13

Docker-engine 1.13 is officially out. Let’s see what’s new.

Prune all the things!

Before we begin, let us first express our gratitude to Spotify with a moment of silence, as we bid farewell to docker-gc. It has served us well, to the point where it’s hard to imagine a Jenkins setup without it.

Its official replacement is prune, which has got to be one of the most awaited for features in recent Docker history. No longer will our build machines and long-running instances become clogged up with the dusty remnants of obsolete containers and images.

docker container prune will delete all stopped containers.

docker image prune will banish all dangling images to beyond the wall. Add -a to get rid of all unused images (ones with no containers running them).

docker volume prune will dispatch volumes to their eternal resting place at /dev/null.

docker network prune does the same for networks.

And, of course, one prune to rule them all: docker system prune is the thing we’re all going to be running as an hourly cron job instead of docker-gc.

$ docker system prune
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all dangling images

Yes, please!

Bonus: docker system df

Pruning is a lot more fun when you can see the impact it has on disk space.

$ docker system df
TYPE                TOTAL       ACTIVE      SIZE        RECLAIMABLE
Images              8           3           941.4 MB    -5.671e+07 B (-6%)
Containers          3           3           5 B         0 B (0%)
Local Volumes       7           3           507.4 MB    507.4 MB (99%)

Sub Commands

As you may have noticed, the Docker CLI has been growing and growing. With more than 40 commands, things were starting to get ouf of hand. This is why 1.13 puts a lot more focus on sub-commands.

You can still use the old commands for now, but it’s probably a good idea to switch to the new style for new code.

Old to New Style

docker attach      ->  docker container attach
docker commit      ->  docker container commit
docker cp          ->  docker container cp
docker create      ->  docker container create
docker diff        ->  docker container diff
docker exec        ->  docker container exec
docker export      ->  docker container export
docker kill        ->  docker container kill
docker logs        ->  docker container logs
docker pause       ->  docker container pause
docker port        ->  docker container port
docker inspect     ->  docker {container,image} inspect
docker ps          ->  docker container ls
docker rename      ->  docker container rename
docker restart     ->  docker container restart
docker rm          ->  docker container rm
docker run         ->  docker container run
docker start       ->  docker container start
docker stats       ->  docker container stats
docker stop        ->  docker container stop
docker top         ->  docker container top
docker unpause     ->  docker container unpause
docker update      ->  docker {container,node,swarm} update
docker wait        ->  docker container wait

docker build       ->  docker image build
docker history     ->  docker image history
docker images      ->  docker image ls
docker import      ->  docker image import
docker load        ->  docker image load
docker pull        ->  docker image pull
docker push        ->  docker image push
docker rmi         ->  docker image rm
docker save        ->  docker image save
docker tag         ->  docker image tag

docker deploy      ->  docker stack deploy
docker events      ->  docker system events

Bonus: shell auto-completion

This brave new world of sub-commands is a bit more verbose. But worry not! The kind folks at Docker have updated the shell auto-completion scripts to reflect the new syntax changes.

You are using shell auto-completion, right?


The ability to pause and unpause containers has been around for a while. Checkpoints, which are an experimental feature, let you do a lot more. They allow you to freeze running containers, saving their state to the disk. This can persist across host reboots, so in a sense you could reboot a host without actually “stopping” the containers. It’s going to be great for debugging.

Unfortunately, it does require a 3rd part tool to work: CRIU. So this does not work out of the box just yet. You can find out more about checkpoints here.


Let’s say you need to pass some sensitive credentials to your containers. Baking them into the image is not a great idea, since anyone with access to the image will have access to this secret data. Passing them as command line arguments to docker run is not much better. Anyone with the ability to ps will be able to read them. Environment variables are marginally less terrible. You’ll need PTRACE_MODE_READ_FSCREDS permissions to read another process’s envars.

The new secret feature (meant to be used only in Swarm mode, for now) works by exposing secrets to containers at runtime through a tmpfs mount.

Here’s how it works.

First, you create a secret using docker secret create, passing the secret data through stdin (or a file).

When you run a container as part of a service (i.e. docker service create) you can select which secrets to expose to the containers at runtime, and they will be accessible as files under /run/secrets/.

In future release, support for passing secrets during the build process is planned. But right now it’s strictly a swarm thing. And it doesn’t work with docker stack deploy yet, either. Nor does it work with docker-compose. It’s a work in progress, really.

Compose v3 & Stacks

Speaking of Docker-Compose, it seems it is being absorbed into the docker-engine CLI. The new version (3) is designed to be compatible with both Compose and Swarm Mode. So now you can deploy a stack with docker stack deploy -c docker-compose.yml. You can think of stacks as “compose for swarm” – a way to define how multiple, scaled services are deployed together in Swarm Mode.

If you want to upgrade to v3, there’s an upgrading guide.

Aside from the familiar Compose syntax, there is also support for the experimental Bundle format, which is JSON based. The DAB (Distributed Application Bundle) standard is meant to be a more open, docker-agnostic alternative to the Compose format, and you can use the Compose CLI to convert Compose files to it. It remains to be seen if any other vendor actually adopts this format, so, for now, its benefits are unclear to yours truly.

Try it out

We’ve updated our Docker-ready VM templates here at CloudShare with version 1.13, so it’ll work out of the box if you want to try it out.

CloudShare Docker VM Templates

We’ll be releasing a few more Docker-related features soon: a docker-machine driver for CloudShare, an Environment Blueprint for Docker Swarm, and more. So, stay tuned.

docker machine logo