General
After getting the [overlay networking to work with Docker experimental and docker-machine locally using boot2docker]({% post_url 2015-07-14-docker-multihost-networking-using-overlay-driver-with-docker-machine-and-boot2docker %}), I wanted to get Docker Swarm to work with overlay network as described in Docker’s blog.
There were some differences in setting the system up when compared to running it on Digital Ocean like in their example, but with some tweaking the example works.
The idea is that first you create a node for running Consul and then a swarm master and one or multiple swarm nodes that run the containers. As all the nodes are configured to use overlay networking by default, the created containers can directly talk to each other without any extra tweaking.
In this article I follow the steps that are described in Docker’s blog and note the differences when running the example locally. I won’t be detailing the use of Docker Compose here as it is exactly the same as in the original article.
Note! At the time of writing this (15th July 2015) VirtualBox 5.0 doesn’t play along with the current docker-machine version (0.3.0). If you have upgraded to VirtualBox 5.0, you need to downgrade to 4.3.30, which (on Mac with brew using the caskroom/versions tap) can be done with
| |
Set up the swarm with multi-host networking
Create the Consul node and start Consul
| |
The boot2docker.iso image that [supports Docker experimental]({% post_url 2015-07-02-using-docker-18-experimental-with-docker-machine-and-virtualbox-driver-boot2docker %}) is downloaded as needed and Consul server is started.
Create a swarm token
| |
Create swarm master
| |
The difference here (apart from running on boot2docker instead of Digital Ocean) is that the bind interface is eth1 instead of eth0. Reason for this is explained [here]({% post_url 2015-07-14-docker-multihost-networking-using-overlay-driver-with-docker-machine-and-boot2docker %}).
Start swarm manually
As Docker Machine doesn’t yet support multi-host networks, Swarm needs to be started manually
| |
Another difference is that the certificates are exposed directly from the host. If the location for the certificates is different in the set-up the volume share needs to be changed appropriately.
Create a Swarm node
| |
Here the difference is again the eth1 binding for the overlay network interface. Multiple Swarm nodes can be created the same way, just change the name for the instance.
Point Docker at the Swarm
| |
Testing connectivity
Now you can proceed with the steps in the original blog or if you just want to quickly test that communication between swarm members really works, start a few containers and because of the spread strategy they should be located to different nodes. Run for example
| |
and in a second terminal run (remember to set the environment variables)
| |
now you should with the command docker ps -a (after setting the environment
variables correctly) in a third console see something like
| |
as you can see the ’test’ and ‘second’ containers are on different hosts (swarm-1 and swarm-0 respectively).
Now the different containers should be able to ping each other. In ’test’ container:
| |
and in ‘second’ container
| |
Next steps
Now building and testing a multi-node set-up is possible also locally without needing to use a cloud provider. It might be a good idea to wait for the tooling to mature a bit so that docker-machine can catch up with the changes to the networking model and support building a swarm also with overlay network. Also as Docker 1.8 is released quite a lot of the tweaks should become unnecessary.
Next I’ll probably see if I can get Cassandra to run on multiple nodes without the actual instances being aware of the infrastructure set-up.