Disclaimer: all code snippets bellow are working only with Docker 1.13+
Docker 1.13 simplifies deployment of composed application to a swarm (mode) cluster. And you can do it without creating a new
dab (Distribution Application Bundle) file, but just using familiar and well-known
docker-compose.yml syntax (with some additions) and
Docker Engine 1.12 introduced a new swarm mode for natively managing a cluster of Docker Engines called a swarm. Docker swarm mode implements Raft Consensus Algorithm and does not require using external key value store anymore, such as Consul or etcd.
If you want to run a swarm cluster on a developer’s machine, there are several options.
The first option and most widely known, is to use a
docker-machine tool with some virtual driver (Virtualbox, Parallels or other).
But, in this post I will use another approach: using docker-in-docker Docker image with Docker for Mac, see more details in my Docker Swarm cluster with docker-in-docker on MacOS post.
Docker Registry mirror
When you deploy a new service on local swarm cluster, I recommend to setup local Docker registry mirror and run all swarm nodes with
--registry-mirror option, pointing to local Docker registry. By running a local Docker registry mirror, you can keep most of the redundant image fetch traffic on your local network and speedup service deployment.
Docker Swarm cluster bootstrap script
I’ve prepared a shell script to bootstrap 4 nodes swarm cluster with Docker registry mirror and very nice swarm visualizer application.
The script initialize docker engine as a swarm master, then starts 3 new docker-in-docker containers and join them to the swarm cluster as worker nodes. All worker nodes run with
Deploy multi-container application - the “old” way
compose is a tool (and deployment specification format) for defining and running composed multi-container Docker applications. Before Docker 1.12, you could use
docker-compose tool to deploy such applications to a swarm cluster. With 1.12 release, it’s not possible anymore:
docker-compose can deploy your application only on single Docker host.
In order to deploy it to a swarm cluster, you need to create a special deployment specification file (also knows as Distribution Application Bundle) in
dab format (see more here).
The way to create this file, is to run the
docker-compose bundle command. The output of this command is a JSON file, that describes multi-container composed application with Docker images referenced by
@sha256 instead of tags. Currently
dab file format does not support multiple settings from
docker-compose.yml and does not allow to use supported options from
docker service create command.
Such a pity story: the
dab bundle format looks promising, but currently is totally useless (at least in Docker 1.12).
Deploy multi-container application - the “new” way
With Docker 1.13, the “new” way to deploy a multi-container composed application is to use
docker-compose.yml again (hurrah!). Kudos to Docker team!
*Note: And you do not need the
docker-compose tool, only
yaml file in docker-compose format (
$ docker deploy --compose-file docker-compose.yml myapp
Docker compose v3 (
So, what’s new in docker compose version 3?
First, I suggest you take a deeper look at docker-compose schema. It is an extension of well-known
docker-compose tool (
ver. 1.9.0) does not support
docker-compose.yaml version: "3" yet.
The most visible change is around swarm ***service deployment.
Now you can specify all options supported by
docker service create/update commands:
- number of service replicas (or global service)
- service labels
- hard and soft limits for service (container) CPU and memory
- service restart policy
- service rolling update policy
- deployment placement constraints link
Docker compose v3 example
I’ve created a “new” compose file (v3) for classic “Cats vs. Dogs” example. This example application contains 5 services with following deployment configurations:
voting-app- a Python webapp which lets you vote between two options; requires
redis- Redis queue which collects new votes; deployed on
worker.NET worker which consumes votes and stores them in
- # of replicas: 2 replicas
- hard limit: max 25% CPU and 512MB memory
- soft limit: max 25% CPU and 256MB memory
- placement: on
swarm workernodes only
- restart policy: restart on-failure, with 5 seconds delay, up to 3 attempts
- update policy: one by one, with 10 seconds delay and 0.3 failure rate to tolerate during the update
db- Postgres database backed by a Docker volume; deployed on
result-appNode.js webapp which shows the results of the voting in real time; 2 replicas, deployed on
docker deploy --compose-file docker-compose.yml command to deploy my version of “Cats vs. Dogs” application on a swarm cluster.
Hope you find this post useful. I look forward to your comments and any questions you have.
This is a working draft version. The final post version is published at Codefresh Blog on December 25, 2016.