The release of Docker 1.13 is coming up quickly, here are the top 10 things we can expect to see when it comes out:

Docker stacks is out of experimental

If you’ve been following the bleeding edge of docker development you’ve probably heard about “.dab” (distributed application bundle) files. These files can be generated from a docker-compose.yml file and they can be given to a docker swarm as the definition of one or more services. This is very handy for automated deployments because it replaces the need to run docker service create and docker service update commands to update the definition of the service.

For a better description on why docker stacks are great, read this.

With the release of docker 1.13 stacks are now out of experimental and can be used by everyone.

Deploy stacks from a docker-compose file

Up to now in order to be able to use the docker stack deploy commands the idea was that we first generate the .dab file from the docker-compose.yml file. In docker 1.13 however, the intermediate step of generating the .dab file from the docker-compose.yml file is no longer required, we can deploy from the docker-compose.yml file directly. Here’s how it works:

$ docker stack deploy \
    --compose-file ./docker-compose.yml \
    mystack

That would create or update the services on the swarm with the same specification as the docker-compose.yml file.

Secrets Management

This allows us to save secrets into the swarm itself and then choose to give services access to certain secrets.

Four new commands have been added to the engine:

  • docker secret create
  • docker secret inspect
  • docker secret ls
  • docker secret rm

Here’s an example, first let’s put a secret into the swarm:

$ echo "my-sensitive-password" | docker secret create login-password

And then start a service with this secret:

$ docker service create \
    --name myapp \
    --secret login-password \
    ubuntu

The secret will be mounted to a file at /run/secrets/login-password inside the service container:

$ docker exec -it myapp cat /run/secrets/login-password
my-sensitive-password

For now we can use this to provide secrets to services at run-time, but only using docker services. If we run a container using docker run we can’t take advantage of secrets yet, although it’s being worked on so expect it soon. In the same way, build-time secrets are not here yet but on the way.

For more info check out the PR which added this.

New ‘–attachable’ flag for swarm networks

The new --attachable flag for docker network create will allow containers started with docker run to attach to swarm networks, so they can communicate with the other services on the swarm network. Previously this was not possible, so this will be very handy for one-off jobs which need to communicate with swarm services, for example for backups or just manual debugging.

Here’s how it’s used:

$ docker network create \
    --driver overlay \
    --attachable \
    my-attachable-network

Then you can connect to this network with a container started with docker run:

$ docker run --rm -it \
    --net my-attachable-network \
    ping google.com

The original PR which introduced this is here.

Plugins are out of experimental

Docker plugins were experimental in previous versions, in docker 1.13 they’ve been promoted out of experimental and are available to everyone.

Plugins allow other applications to hook into docker and augment it. Examples of plugins that exist today are the flocker plugin and the weave plugin.

You can find more info on plugins here.

Docker daemon –experimental flag to enable experimental features

Now the experimental features ship in the same binary as the stable features. Before now we had to download a different binary to enable the experimental features, now we just need to add the --experimental flag to the docker daemon when it is started.

The PR which introduced this change is here.

service update –force

If you’ve tried to implement a docker 1.12 swarm in a non-dev environment you’ve probably come up against a few problems, for example there was no way to force a redistribution of services over a swarm after adding a new node.

The new --force flag will force the image to be pulled and the containers to be restarted. Rolling updates are respected, so if the service has --update-parallelism 1 and --update-delay 5s then each container will get restarted one by one, with a delay of 5 seconds between each one.

Note: There was also a bug in docker service update --image myimage:latest which caused the image not to be pulled, even if a newer version of the tag existed. This bug has been fixed, so you don’t need --force to update the image, every time you run service update you can expect the image to be updated to the latest version of the tag.

The PR which implemented this change is here.

New –port flag in docker service create

The new --port flag in docker service create is designed to replace the --publish flag. The --publish flag was used like this:

$ docker service create --publish 8080:80 my-service

This example makes it possible to access the container from port 8080 on every node in the swarm, also known as “mesh routing”.

The new --port flag follows the “csv” format, similar to the --mount flag. This allows multiple settings to be given in the same --port argument, as opposed to supplying many different individual flags. For example, now we can use the --port flag to specify the mode, for example:

$ docker service create \
    --name my-service \
    --port mode=ingress,target=80,published=8080,protocol=tcp

The new syntax allows for a more flexible and clean definition of the port configurations since all the options are in one single flag.

This release also allows specifying “host” as the port mode, although the documentation isn’t clear on what effect that has.

Cache Layers When Building

This is a big one for continuous integration setups where images are built often and sometimes on different servers. Up to now there was no easy way to share the build cache among all of the build servers, so each time an image was built all the layers needed to be built. A simple pull before building wasn’t enough to pull the cache in more recent versions of docker because of a security concern: we cannot trust that the images that we pulled is actually the result of the command that we want to run, it might have been tampered with.

With the new --cache-from argument to the build command we can tell docker to trust the layers in a certain image for use in the cache. This means that we can go back to the old days of “pulling before building” to populate the build cache and avoid having to build all layers again.

Here’s how it’s used:

docker pull myimage:v1.0
docker build --cache-from myimage:v1.0 -t myimage:v1.1 .

The orignal PR which introduced this is here.

Other Noteworthy Improvements

The 1.13 release has brought a huge amount of bugfixes and improvements, here are a few noteworthy mentions that didn’t make it into the list above:

Installing the Release Candidate

To install the release candidate of Docker 1.13 to play around with all of the things we mentioned, run this:

$ curl -fsSL https://test.docker.com/ | sh

Wrapping Up

All in all docker 1.13 brings a great set of new features and bugfixes. With the entry of stacks and a few small bugfixes in the service update commands swarm is getting easier and easier to use swarm in production, little by little the small problems are being removed. I’m very exited for the Docker 1.13 release, are you?

The full official changelog for the 1.13 release is here.