Swarming Raspberry Pi – Part 1

Here’s the first in a series of building a robust docker swarm of raspberry pi hosts. This installment goes through installing the Pi(s), modifiying the Docker Daemon config, and starting up a test to verify that everyone can join the cluster.

The cluster which I am using consists of

• Raspberry Pi B+ x 5
• Raspberry Pi 2 B x 5

In order to verify that the cluster is working properly, there should be ten (10) members, five (5) of which have 4 cores.

Obtaining the OS and Setup

The wonderful folks at Hypriot have produced a raspberry image based on Raspbian, but with Docker 1.5.0. The image and instructions can be found at Heavily ARMed after major upgrade: Raspberry Pi with Docker 1.5.0 – Docker Pirates ARMed with explosive stuff.

Note: The image resizes itself to fit the card upon the first boot and then reboots. This takes a little bit (minutes at most). Just don’t be surprised when it reboots.

Hostnames

In order for this to work properly, the hosts need a unique name. It’s sometimes possible to configure DHCP to do this, but I went ahead and edited /etc/hostname myself since I wanted the most portability possible.

Like all good sysadmins, I am lazy. Doing the same thing over and over is boring. Besides, that’s what computers are for. So I wrote a script to make copies of the image and then edit the hostnames. Once that’s done I can then proceed to write the images to the SD cards.

The following script takes one argument, the location of the image you wish to modify — this should work for more than just Hypriot; it should work for just about any Rasberry Pi image. At present, it creates 10 instances and the NAME starts with apis-rpi- — you will likely want to change those. I may make the file a bit more generic at some point.

The Pi instances all need network connectivity which can be seen by the swarm manager; a switch works well. You can either physically assign IP addresses or use DHCP.

Updating Docker

In order for swarm instances to communicate, the docker daemon needs to be bound to a TCP port.

1. sudo service docker stop
2. Edit /etc/default/docker (vi is installed on the image) and replace DOCKER_OPTS="--storage-driver=overlay -D" with DOCKER_OPTS="--storage-driver=overlay -D -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"
3. sudo service docker restart

Docker should be running once again. I’ve left the unix socket enabled so that the “default” behaviour still works.

WARNING There are some security issues with this; a port is opened to anyone who can reach the host at which point they can start containers, etc.. Other than using this for play/testing on a private network, TLS needs to be configured.

To verify that the daemon is running with both the port and the socket, do docker info and docker -H 127.0.0.1:2375. You should see something like the following for both:

Obtaining Swarm

I’ve created a Raspberry Pi docker container for swarm. To install it, you can simply pull nimblestratus/rpi-swarm. With more than a couple Raspberry Pis, this can be a bit tedious. clusterssh makes this a lot easier — it allows you to type in the same commands to multiple servers at once.

Discovery Service

In future installments I’ll be getting a different discovery service running, but for this test the default works.

Starting the Nodes

On each node, execute the following: (this assumes that you’re using wired ethernet; for wireless you’ll need to change eth0 to most likely wlan0)

It can be helpful to verify that the agent has started with docker ps. If you don’t see it running, then there’s a problem somewhere.

Starting the Manager

I’m running the manager on my laptop; consequently I’m using the swarm container instead of nimblestratus/rpi-swarm:

Once this comes back, let’s check out the swarm:

Ok, let’s test…

You can find the url like this:

At this point there isn’t any service discovery; that’s for the next increment….

Pop the URL into a browser and you should see:

Next time… setting up a discovery service…