For truly highly-available services with Docker containers, we need an orchestration system. Docker Swarm (as defined at 1.13) is the simplest way to achieve redundancy, such that a single docker host could be turned off, and none of our services will be interrupted.
Ingredients
Summary
Existing
3 x nodes (bare-metal or VMs), each with:
A mainstream Linux OS (tested on either CentOS 7+ or Ubuntu 16.04+)
At least 2GB RAM
At least 20GB disk space (but it'll be tight)
Connectivity to each other within the same subnet, and on a low-latency link (i.e., no WAN links)
Preparation
Bash auto-completion
Add some handy bash auto-completion for docker. Without this, you'll get annoyed that you can't autocomplete docker stack deploy <blah> -c <blah.yml> commands.
Run docker node ls to confirm that you have a 1-node swarm:
[root@ds1~]# docker node ls
IDHOSTNAMESTATUSAVAILABILITYMANAGERSTATUS
b54vls3wf8xztwfz79nlkivt8*ds1.funkypenguin.co.nzReadyActiveLeader
[root@ds1~]#
Note that when you run docker swarm init above, the CLI output gives youe a command to run to join further nodes to my swarm. This command would join the nodes as workers (as opposed to managers). Workers can easily be promoted to managers (and demoted again), but since we know that we want our other two nodes to be managers too, it's simpler just to add them to the swarm as managers immediately.
On the first swarm node, generate the necessary token to join another manager by running docker swarm join-token manager:
Run the command provided on your other nodes to join them to the swarm as managers. After addition of a node, the output of docker node ls (on either host) should reflect all the nodes:
[root@ds2davidy]# docker node ls
IDHOSTNAMESTATUSAVAILABILITYMANAGERSTATUS
b54vls3wf8xztwfz79nlkivt8ds1.funkypenguin.co.nzReadyActiveLeader
xmw49jt5a1j87a6ihul76gbgy*ds2.funkypenguin.co.nzReadyActiveReachable
[root@ds2davidy]#
Setup automated cleanup
Docker swarm doesn't do any cleanup of old images, so as you experiment with various stacks, and as updated containers are released upstream, you'll soon find yourself loosing gigabytes of disk space to old, unused images.
To address this, we'll run the "meltwater/docker-cleanup" container on all of our nodes. The container will clean up unused images after 30 minutes.
First, create docker-cleanup.env (mine is under /var/data/config/docker-cleanup), and exclude container images we know we want to keep:
Setup unique static subnets for every stack you deploy. This avoids IP/gateway conflicts which can otherwise occur when you're creating/removing stacks a lot. See my list here.
Launch the cleanup stack by running docker stack deploy docker-cleanup -c <path-to-docker-compose.yml>
Setup automatic updates
If your swarm runs for a long time, you might find yourself running older container images, after newer versions have been released. If you're the sort of geek who wants to live on the edge, configure shepherd to auto-update your container images regularly.
Create /var/data/config/shepherd/shepherd.env as per the following example:
# Don't auto-update Plex or Emby (or Jellyfin), I might be watching a movie! (Customize this for the containers you _don't_ want to auto-update)BLACKLIST_SERVICES="plex_plex emby_emby jellyfin_jellyfin"# Run every 24 hours. Note that SLEEP_TIME appears to be in seconds.SLEEP_TIME=86400
Then create /var/data/config/shepherd/shepherd.yml as per the following example:
Launch shepherd by running docker stack deploy shepherd -c /var/data/config/shepherd/shepherd.yml, and then just forget about it, comfortable in the knowledge that every day, Shepherd will check that your images are the latest available, and if not, will destroy and recreate the container on the latest available image.
Summary
The easy, 5-minute install
I share (with sponsors and patrons) a private "premix" GitHub repository, which includes an ansible playbook for deploying the entire Geek's Cookbook stack, automatically. This means that members can create the entire environment with just a git pull and an ansible-playbook deploy.yml 👍
Did you receive excellent service? Want to compliment the chef? (..and support development of current and future recipes!) Sponsor me on Github / Ko-Fi / Patreon, or see the contribute page for more (free or paid) ways to say thank you! 👏
Employ your chef (engage) 🤝
Is this too much of a geeky PITA? Do you just want results, stat? I do this for a living - I'm a full-time Kubernetes contractor, providing consulting and engineering expertise to businesses needing short-term, short-notice support in the cloud-native space, including AWS/Azure/GKE, Kubernetes, CI/CD and automation.
Want to know now when this recipe gets updated, or when future recipes are added? Subscribe to the RSS feed, or leave your email address below, and we'll keep you updated.