Earlier in the week I wrote about the new Docker Swarm functionality, as i didn’t have much time I was just using the Docker for Mac beta.

Launching a Swarm cluster

To test more of the new features we are going to need a few servers so rather than launching them locally I decided to write an Ansible playbook to launch x number of droplets in Digital Ocean. Once the droplets have launched the playbook goes on to perform the following tasks;

  • Installs a few prerequisites like python 2.7, git and UFW
  • Configures UFW, locking down the Docker services to just our Droplets
  • Installs Docker 1.12rc2 experimental build from https://experimental.docker.com/
  • Initializes the Swarm manager and then connects the worker nodes to the manager

The playbook is available on GitHub at https://github.com/russmckendrick/digitalocean-docker-swarm, the README has instructions on how to run the playbook so I won’t go into detail here, below is a what you should see when you run the playbook for the first time;


Once complete, you should have four droplets launched in Digital Ocean;


Load Balancing

One of the features I wanted to try for myself was the Load Balancing. The documentation describes this as;

The swarm manager uses ingress load balancing to expose the services you want to make available externally to the swarm. The swarm manager can automatically assign the service a PublishedPort or you can configure a PublishedPort for the service in the 30000–32767 range.

 External components, such as cloud load balancers, can access the service on the PublishedPort of any node in the cluster whether or not the node is currently running the task for the service. All nodes in the swarm cluster route ingress connections to a running task instance.

Now you have your Docker Swarm cluster up and running we can test the Load Balancing to do this connect to the Manager, the IP is at the end of the playbook output or you can get it from your Digital Ocean control panel.

Once connected you can check everything is OK with your cluster by running;

docker node ls

This will show all of the Droplets in the cluster and their current status. Now we have confirm our cluster is working as it should be we can launch some containers. In my previous post I created a service using my test container so I will do that again here.

docker network create -d overlay clusternetwork
docker service create — name cluster -p:80:80/tcp — network clusternetwork russmckendrick/cluster
docker service ls
docker service tasks cluster

As you can see, I have a single container running on the docker-swarm-manager node. Lets try connecting to our container via the IP address of one of the worker nodes;


and there we have our container !!!

Last time we tried scaling, so lets try again now. As we have four droplets we can get into double digits;

docker service scale cluster=15
docker service tasks cluster

Before looking at anything else lets remove the cluster service;

docker service rm cluster
docker service ls

Docker Distributed Application Bundles (DAB)

While we have our Swarm cluster up and running, lets look at building a distributed application using a Docker Compose file. Docker Distributed Application Bundles are described as;

Distributed Application Bundles is an experimental open file format for bundling up all the artifacts required to ship and deploy multi-container apps: a DAB contains a description of all the services required to run the application and details images to use, ports to expose, and the networks used to link services.

The Docker Compose file we will be using follows;

version: ‘2’
 container_name: my-wordpress-app
 image: wordpress
 — “80:80”
 — “WORDPRESS_DB_HOST=mysql:3306”
 container_name: my-wordpress-database
 image: mysql
 — “3306”

As you can see the docker-compose.yml file runs a WordPress and MySQL container as well configures networking. On your local machine, check that you are running Docker Compose 1.8rc1, this is included in the latest Docker for Mac beta, by running;

docker-compose — version

Now create a temporary folder and download the docker-compose.yml file;

mkdir ~/Desktop/test
cd ~/Desktop/test
curl -O https://gist.githubusercontent.com/russmckendrick/c6320315431afd19a0ee10132e086673/raw/e3a8019a68c2122141cae14bcb84b4c20ef18fe6/docker-compose.yml

Now we have our Docker Compose file, download the images by running;

docker-compose pull

and finally create the bundle by running;

docker-compose bundle -o wordpress.dsb

a copy of the bundle created above looks like;


Back on our Swarm manager, we can download the distributed app by running;

curl -O https://gist.githubusercontent.com/russmckendrick/c6320315431afd19a0ee10132e086673/raw/e3a8019a68c2122141cae14bcb84b4c20ef18fe6/wordpress.dsb
docker deploy wordpress

Now the application has been deployed you can check its status by running;

docker stack tasks wordpress

Finally, we need to know which port our WordPress container has been published on so that we can access it in our browser. To get this information run the following command;

docker service inspect wordpress_wordpress

and make a note of the PublishedPort in the Endpoint section.


Going to any of your hosts on port 30001 should present you with a WordPress installation screen.

It’s worth noting that this feature is not yet complete and it seems to be quite limiting, for example there doesn’t appear to be a way to mount volumes or define which port is exposed.

Tearing down the cluster

As none of us want servers hanging around, not being used but costing us money there is a playbook which terminates the Drops we originally launched, to run it follow the instructions in the README.