docker-swarm-demo
Short Version
This is an example of how to get a Docker Swarm up and running on multiple nodes. For a quick single node example you may use the make file as follows: Note: Edit the make file and change --advertise-addr 192.168.122.1 to your manager node IP address.
make install
That's it. You should have two services running and then you can locate your alpine-swarm-demo service with docker ps and start testing:
run the script from within your demo-alpine container/service
python test.py
1
2
3
...
Notice that I've referenced the redis service by its container/service name not by IP, as it could be anywhere on the cluster. You should start seeing the incremented values print to screen.
For extra fun, if it is working for you, scale the redis service and you can see it occur because the already running Python script will start hitting the new scaled service and print some requests against the new service (starting at 1 again).
docker service scale demo-redis=3
You should start seeing new increment values printing to the screen from the newly scaled redis service and the cluster should round-robin requests to each newly created redis service. Synching that data is another story - but that wasn't the point of the quick demo!
Long Version
This assumes you have several machines or VMs with Docker 1.12.x or greater installed. It is very important that each machines time is synchronized via NTP or manually. For a quick and dirty test you can sync them manually with the following command:
$ sudo date --set="$(ssh you@your-computer date)"
Initialize at least one Manager node
$ sudo docker swarm init
This command will return the command you need to use in order to join the cluster; the command to be executed on your worker nodes.
Note: It has been my experience that on some machines setting the --listen-addr your.ip.address:2377 is necessary.
Initialize one or more workers
$ docker swarm join \
> --token SOME----LONG-----TOKEN \
> manager.ip.address:2377
Create a network overlay from a manager node
This allows the services to reference one another by container/service name just like one would do in a Docker Compose file:
$ docker network create --driver overlay my-app-network
Create a service to run on the cluster (within the network overlay):
$ docker service create --replicas 1 --network my-app-network \
> --name demo-redis redis
Create a service to call Redis
I'm going to create a service that I can attach to, to run a simple Python script to interact with Redis.
docker service create --replicas 1 --network my-app-network \
--name alpine-swarm-demo ctownsend/alpine-swarm-demo /bin/sh -c "trap 'exit 0' INT TERM; while true; do echo Hello World; sleep 10; done"
Note: At this point we've created a container that doesn't really do anything but we'll be logging into it so we can explore interactively with the test.py Python script to see what is going on.
find the node the demo-alpine service is running on
docker service ps alpine-swarm-demo #this will report which node is running the container
SSH into the node that is running demo-alpine and attach to it's shell
docker ps #lists all the running containers on that node, find the container ID of alpine-swarm-demo
docker exec -i -t <container id> /bin/sh
run the test.py Pythong script from within your demo-alpine container
python test.py
1
2
3
...
Notice that I've referenced the redis service by its container/service name not by IP, as it could be anywhere on the cluster. You should start seeing the incremented values print to screen.
For extra fun, if it is working for you, scale the redis service and you can see it occur because the already running Python script will start hitting the new scaled service and print some requests against the new service (starting at 1 again).
ssh into the manager node from another terminal session so you don't stop your demo-alpine session
docker service scale demo-redis=3
You should start seeing new increment values printing to the screen from the newly scaled redis service and the cluster should round-robin requests to each newly created redis service. Synching that data is another story - but that wasn't the point of the quick demo!