5.2Swarm express: cluster, stack and replicas
The essentials in 30 seconds
- Init in one command: the local machine becomes manager, the others join as workers — even single-node, Swarm brings replicas and zero-downtime updates.
- Deploy the stack: the augmented Compose file (deploy: replicas, update_config, restart_policy) deploys on the cluster — replicas spread out, the update goes one by one.
- See and scale: list services and replicas, adjust the count, let Swarm replace the replicas of a dead node — with a mandatory healthcheck for a clean update.
Running mini-case — Idir sets up his first cluster
Idir, junior DevOps in Algiers, moves to practice: his app will soon have to run on two machines. He first trains single-node: he inits Swarm on his machine, adds deploy (3 replicas, one-by-one update) to his web service, deploys the stack and lists the replicas. Then he scales to 5 then to 2 and watches the scheduling. Continued from case 5.1 — Idir moves from auditing the need to the first replicated cluster.
Continued from case 5.1 — Idir trains single-node before any multi-machine.
1. Init in one command
docker swarm init makes the local machine a manager (the pilot); docker swarm join attaches workers (the executors) to it with the provided token. Idir starts alone: even on a single machine, Swarm already brings replicas and rolling updates — the ideal training ground before multi-machine.
In single-node development, remember to leave cleanly (docker swarm leave) to get back to a simple Docker. Idir's rule: master single-node before adding machines.
2. Deploy the stack: the augmented Compose
docker stack deploy -c compose.yml monapp deploys the Compose on the cluster, with the deploy section: replicas: 3, update_config (one-by-one update with delay), restart_policy. The replicas spread across nodes, the update replaces replicas one by one: zero downtime if the healthcheck is good. Idir adds these three keys to his web service.
The healthcheck is the condition for a clean update: Swarm only promotes a new replica once it is proven ready. Without a healthcheck, you scale and update blind — guaranteed downtime.
3. See and scale
docker service ls lists services, docker service ps shows the state of each replica (where, what, since when), docker service scale adjusts the count. Idir scales to 5 then to 2 and watches the scheduling. If a node dies, Swarm replaces the replicas elsewhere: that is the promised self-healing.
Multi-node pitfall #1: local volumes do not travel — a local volume stays on its node. You need shared storage or external databases, otherwise data goes missing depending on which node answers.
🔎 Concrete example — Idir's web in 3 replicas without downtime
Init, deploy, observe, scale.
docker swarm init
docker stack deploy -c compose.yml monapp
docker service ls
docker service ps monapp_web
docker service scale monapp_web=5Reading: 3 replicas at the start, one-by-one update, then moving to 5.
Lesson: during the update, the service keeps answering thanks to replicas.
Section vocabulary
- Manager / worker
- The manager pilots the cluster, workers run the replicas.
Simple example: Idir inits his machine as manager before attaching workers to it.
What it is not: isolated machines with no common pilot.
Reflex: who pilots, who runs in my cluster?
- Stack
- The Compose file deployed on the cluster with its deploy section.
Simple example: Idir deploys monapp with replicas and update_config.
What it is not: a plain compose with no deploy run on one machine.
Reflex: is my deploy section written?
- Replica
- One copy of a service, spread across nodes.
Simple example: Idir runs 3 replicas of his web.
What it is not: a single container with no backup.
Reflex: how many copies are running right now?
- Scale
- Adjust the number of replicas of a service on demand.
Simple example: Idir goes from 3 to 5 replicas then back down to 2.
What it is not: relaunching the whole app to change capacity.
Reflex: can I adjust capacity without downtime?
- Healthcheck
- The probe proving a replica is ready before promoting it.
Simple example: Idir only allows the update on a replica proven ready.
What it is not: a blind update with no probe.
Reflex: does each long-lived service have its probe?
In practice — Your first cluster
- Init Swarm on your machine (init).
- Add deploy (3 replicas + one-by-one update) to your web service.
- Deploy the stack and list services and replicas.
- Scale to 5 then to 2: watch the scheduling.
Ready-to-say script — announcing the first cluster to the team
“I am setting up our first Swarm cluster in Algiers: first single-node to train — 3 replicas, one-by-one update, mandatory healthcheck — then we will add the machines. I will show you the replica scheduling and the zero-downtime update before any real multi-node.”
Say to the team to frame single-node training before multi-machine.
Copy-paste template — generic Swarm stack
STACK SWARM GENERIQUE — fichier compose.yml
services:
web:
image: mon-registre/mon-app:stable
ports:
- "8080:80"
healthcheck:
test: ["CMD", "wget", "--spider", "-q", "http://localhost/"]
interval: 30s
timeout: 5s
retries: 3
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: on-failure
COMMANDES : docker swarm init · docker stack deploy -c compose.yml monapp · docker service ls · docker service ps monapp_web · docker service scale monapp_web=5Solo / small budget
Idir alone: a single-node cluster is enough to learn replicas and updates.
Small company / small team
Demo in pairs: one deploys, the other watches replicas during the update.
SME in Algiers
Idir books a sandbox slot in Algiers: init, deploy and scale without touching prod.
Starting team
Pair: one writes the deploy section, the other checks healthcheck and scheduling.
✓ Best practices
- Test single-node before any multi-machine.
- Mandatory healthcheck on each long-lived service.
- One-by-one updates (parallelism at 1).
✗ Common pitfalls
- Local volumes not shared between nodes (missing data).
- Scaling without a healthcheck (downtime during update).
- Forgetting to leave Swarm in dev after training.
Key takeaways
- Init = manager, join = workers — even single-node to train.
- Deploy adds replicas, one-by-one update and restart policy.
- Scale adjusts the count, Swarm replaces replicas of a dead node.
- Healthcheck = zero-downtime update; local volumes = pitfall #1.
48h challenge — apply tomorrow
Deploy single-node a stack with 3 replicas + healthcheck: list the replicas, scale to 5 then 2, and note the observed scheduling.
- I can init Swarm and deploy a replicated stack.
- My services have deploy + healthcheck.
- I know why local volumes block multi-node.
Frequently asked questions
Do volumes follow in Swarm?
No by default: a local volume stays on its node, it does not travel with replicas. In multi-node, plan shared storage or external databases — it is the #1 pitfall when moving to a cluster. Always test where your data lives before scaling.
How to leave Swarm after training?
With the leave command on the node (leave, with force if needed on a manager). In single-node dev, remember to leave to get back to a simple Docker once the exercise is done.
For a zero-downtime Swarm update, what is needed?