Swarm mode is easily my favorite feature in docker. It’s also the subject of heated debate, yet well-loved by some devoted proponents. Here’s my take on swarm and why I like it for smallish teams with a few projects. Stick around for a mini how-to after the rant.
Just three words are required to wrangle a group of freshly minted Ubuntu servers into a functional, production-ready cluster:
docker swarm init
I love this user experience. Particularly considering the value you’re getting for your time. After running this command, you get:
- a bootstrapped cluster that can consume a docker-compose file (ya know, the one that you already have anyways) and deploy your services,
- behind a load balancer that automatically distributes client connections,
- which is managed through an automatically encrypted control plane,
- and supports replicas, health checking, update strategies, volumes, hardware pass-through, overlay networking, and more!
That’s bang for your buck! This is why I like…
Swarm for Small(ish) Teams.
It’s easy to get in your own way when taking a fledgling service to launch. Ask many consultants or experts in the software delivery space what you should do to get your software out there, and you’ll hear, almost universally, kubernetes.
The problem I have with this has nothing to do with kubernetes. It has everything to do with the strategy startups and small teams use to get ahead; be fast, nimble, and valuable. Kubernetes is a naval fleet of freighters and swarm is a small charter yacht.
You can pilot the yacht yourself, with your scrappy team, and avoid hiring captains, crew, chefs, engineers, security, etc. The small yacht has everything you need to get started and you can change course instantly. It’s also pretty easy to sell a yacht.. good luck getting your value back out of that freighter.
In short, the freighters are built and operated by economies of scale, which a startup can’t typically leverage in the beginning.
By the way, I write one of these every few weeks or so. Sign-up with your email here to receive the latest, as soon as it’s posted!
How to Start Using Swarm.
Want to know the easiest way? Open up your terminal and run:
docker swarm init
There’s that beautiful command again! Running a swarm manager on your local docker engine is a great way to play with this. Now, add a local container registry:
docker service create --name registry --publish published=5000,target=5000 registry:2
Here’s a simple little project:
I have a python api in flask, a dockerfile, and a docker compose file. The api:
from flask import Flask app = Flask(__name__) @app.route("/", methods=["GET"]) def hello(): return "Hello World!"
The docker file is based on python slim, and copies the src, installs dependencies, and runs gunicorn to host the api.
# pull official base image FROM python:3.11.3-slim # set environment variables # prevents Python from writing pyc files to disc ENV PYTHONDONTWRITEBYTECODE 1 # prevents Python from buffering stdout and stderr ENV PYTHONUNBUFFERED 1 RUN mkdir /app WORKDIR /app # copy src code COPY src /app/ # install dependencies RUN pip3 install -r requirements.txt CMD ["gunicorn", "-w 1", "-b", ":9000", "main:app"]
The docker compose file includes everything our little service needs to run on swarm.
version: '3.7' services: api: image: 127.0.0.1:5000/hello-world ports: - "9000:9000" build: .
With a docker compose build, push, and docker stack deploy, we have an api saying hello:
user@computer src % docker compose build [+] Building 0.9s (11/11) FINISHED user@computer src % docker compose push [+] Running 0/9 user@compuer src % docker stack deploy -c docker-compose.yml hello-world Creating network hello-world_default Creating service hello-world_api user@computer src % curl http://localhost:9000 Hello World!
This same compose file can be used in a non swarm configuration, with docker-compose up, which makes local development -> production deployment a breeze. Here’s how to build a quick, production-ready swarm deployment.
If you need help with product development and software delivery, reach out.