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
- Deploy stacks from a docker-compose file
- Secrets Management
- New ‘–attachable’ flag for swarm networks
- Plugins are out of experimental
- Docker daemon –experimental flag to enable experimental features
- service update –force
- New –port flag in docker service create
- Cache Layers When Building
- Other Noteworthy Improvements
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
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
file from the
docker-compose.yml file. In docker 1.13
however, the intermediate step of generating the
.dab file from
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
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
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
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
--attachable flag for
docker network create
will allow containers started
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
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
$ 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.
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
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.
--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-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
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
--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”.
--port flag follows the “csv” format, similar to the
--mount flag. This allows multiple settings to be given in
--port argument, as opposed to supplying many different
individual flags. For example, now we can use the
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:
MAINTAINERcommand in Dockerfiles has been deprecated, if you need to record the maintainer use labels instead.
- A new
docker service logscommand for viewing logs from a service (experimental)
docker service updateto roll back to the previous version.
- A new
docker inspectcommand which can be used to inspect all kinds of resources.
- Ability to squash image
docker build --squash
- Easy way to cleanup old
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
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
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,
The full official changelog for the 1.13 release is here.