5.2Swarm express : cluster, stack et réplicas
L'essentiel en 30 secondes
- Initier en une commande : la machine locale devient manager, les autres la rejoignent en workers — même en mono-nœud, Swarm apporte réplicas et mises à jour sans coupure.
- Déployer le stack : le fichier Compose augmenté (deploy : replicas, update_config, restart_policy) se déploie sur le cluster — les réplicas se répartissent, la mise à jour passe un par un.
- Voir et scaler : lister services et réplicas, ajuster le nombre, laisser Swarm remplacer les réplicas d'un nœud mort — avec un healthcheck obligatoire pour une mise à jour propre.
Mini-cas filé — Idir monte son premier cluster
Idir, devops junior à Alger, passe à la pratique : son appli devra bientôt tourner sur deux machines. Il s'entraîne d'abord en mono-nœud : il initie Swarm sur sa machine, ajoute deploy (3 réplicas, mise à jour un par un) à son service web, déploie le stack et liste les réplicas. Puis il scale à 5 puis à 2 et observe la répartition. Suite du cas 5.1 — Idir passe de l'audit du besoin au premier cluster répliqué.
Suite du cas 5.1 — Idir s'entraîne en mono-nœud avant tout multi-machine.
1. Initier en une commande
docker swarm init fait de la machine locale un manager (le pilote) ; docker swarm join y rattache des workers (les exécutants) avec le jeton fourni. Idir commence seul : même sur une seule machine, Swarm apporte déjà réplicas et rolling updates — le terrain d'entraînement idéal avant le multi-machine.
En développement mono-nœud, on pense à quitter proprement (docker swarm leave) pour retrouver un Docker simple. La règle d'Idir : maîtriser le mono-nœud avant d'ajouter des machines.
2. Déployer le stack : le Compose augmenté
docker stack deploy -c compose.yml monapp déploie le Compose sur le cluster, avec la section deploy : replicas: 3, update_config (mise à jour un par un avec délai), restart_policy. Les réplicas se répartissent sur les nœuds, la mise à jour remplace les réplicas un par un : zéro coupure si le healthcheck est bon. Idir ajoute ces trois clés à son service web.
Le healthcheck est la condition de la mise à jour propre : Swarm ne promeut un nouveau réplica que s'il est prouvé prêt. Sans healthcheck, on scale et on met à jour à l'aveugle — coupures garanties.
3. Voir et scaler
docker service ls liste les services, docker service ps montre l'état de chaque réplica (où, quoi, depuis quand), docker service scale ajuste le nombre. Idir scale à 5 puis à 2 et observe la répartition. En cas de nœud mort, Swarm replace les réplicas ailleurs : c'est l'auto-réparation promise.
Piège n°1 du multi-nœud : les volumes locaux ne voyagent pas — un volume local reste sur son nœud. Il faut du stockage partagé ou des bases externes, sinon les données manquent selon le nœud qui répond.
🔎 Exemple concret — Le web d'Idir en 3 réplicas sans coupure
Initier, déployer, observer, scaler.
docker swarm init
docker stack deploy -c compose.yml monapp
docker service ls
docker service ps monapp_web
docker service scale monapp_web=5Lecture : 3 réplicas au départ, mise à jour un par un, puis passage à 5.
Leçon : pendant l'update, le service répond toujours grâce aux réplicas.
Vocabulaire de la section
- Manager / worker
- Le manager pilote le cluster, les workers exécutent les réplicas.
Exemple simple : Idir initie sa machine en manager avant d'y rattacher des workers.
Ce que ce n'est pas : des machines isolées sans pilote commun.
Réflexe : qui pilote, qui exécute dans mon cluster ?
- Stack
- Le fichier Compose déployé sur le cluster avec sa section deploy.
Exemple simple : Idir déploie monapp avec replicas et update_config.
Ce que ce n'est pas : un simple compose sans deploy lancé sur une machine.
Réflexe : ma section deploy est-elle écrite ?
- Réplica
- Un exemplaire d'un service, réparti sur les nœuds.
Exemple simple : Idir fait tourner 3 réplicas de son web.
Ce que ce n'est pas : un conteneur unique sans doublure.
Réflexe : combien d'exemplaires tournent en ce moment ?
- Scale
- Ajuster le nombre de réplicas d'un service à la demande.
Exemple simple : Idir passe de 3 à 5 réplicas puis redescend à 2.
Ce que ce n'est pas : relancer toute l'appli pour changer de capacité.
Réflexe : puis-je ajuster la voilure sans coupure ?
- Healthcheck
- La sonde qui prouve qu'un réplica est prêt avant de le promouvoir.
Exemple simple : Idir n'autorise la mise à jour que sur réplica prouvé prêt.
Ce que ce n'est pas : une mise à jour à l'aveugle sans sonde.
Réflexe : chaque service durable a-t-il sa sonde ?
En pratique — Votre premier cluster
- Initiez Swarm sur votre machine (init).
- Ajoutez deploy (3 réplicas + mise à jour un par un) à votre service web.
- Déployez le stack et listez services et réplicas.
- Scalez à 5 puis à 2 : observez la répartition.
Script prêt à dire — annoncer le premier cluster à l'équipe
« Je monte notre premier cluster Swarm à Alger : d'abord en mono-nœud pour s'entraîner — 3 réplicas, mise à jour un par un, healthcheck obligatoire — puis on ajoutera les machines. Je vous montrerai la répartition des réplicas et la mise à jour sans coupure avant tout multi-nœud réel. »
À dire à l'équipe pour cadrer l'entraînement mono-nœud avant le multi-machine.
Modèle copier-coller — stack Swarm générique
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 / petit budget
Idir seul : un cluster mono-nœud suffit pour apprendre réplicas et mises à jour.
TPE / équipe réduite
Démo à deux : l'un déploie, l'autre observe les réplicas pendant la mise à jour.
PME à Alger
Idir cale à Alger un créneau bac à sable : init, deploy et scale sans toucher à la prod.
Équipe qui démarre
Binôme : l'un écrit la section deploy, l'autre vérifie healthcheck et répartition.
✓ Bonnes pratiques
- Testez en mono-nœud avant tout multi-machine.
- Healthcheck obligatoire sur chaque service durable.
- Mises à jour un par un (parallélisme à 1).
✗ Pièges fréquents
- Volumes locaux non partagés entre nœuds (données manquantes).
- Scaler sans healthcheck (coupures pendant l'update).
- Oublier de quitter Swarm en dev après l'entraînement.
Points clés à retenir
- Init = manager, join = workers — même en mono-nœud pour s'entraîner.
- Deploy ajoute réplicas, mise à jour un par un et politique de redémarrage.
- Scale ajuste le nombre, Swarm remplace les réplicas d'un nœud mort.
- Healthcheck = mise à jour sans coupure ; volumes locaux = piège n°1.
Défi 48h — appliquez demain
Déployez en mono-nœud un stack avec 3 réplicas + healthcheck : listez les réplicas, scalez à 5 puis 2, et notez la répartition observée.
- Je peux initier Swarm et déployer un stack répliqué.
- Mes services ont deploy + healthcheck.
- Je sais pourquoi les volumes locaux bloquent le multi-nœud.
Questions fréquentes
Les volumes suivent-ils en Swarm ?
Non par défaut : un volume local reste sur son nœud, il ne voyage pas avec les réplicas. En multi-nœud, prévoyez du stockage partagé ou des bases externes — c'est le piège n°1 du passage au cluster. Testez toujours où vos données vivent avant de scaler.
Comment quitter Swarm après l'entraînement ?
Avec la commande de sortie sur le nœud (quitter, en force si besoin sur un manager). En dev mono-nœud, pensez à quitter pour retrouver un Docker simple une fois l'exercice terminé.
Pour une mise à jour Swarm sans coupure, que faut-il ?