DOCKER
SWARM
La boutique de Cornucopia répliquée sur un essaim de cinq noeuds : trois gestionnaires, deux travailleurs, un proxy inverse, deux piles.
L'essaim en une diapo docs.docker.com/engine/swarm
Déclarer un état désiré, et laisser l'essaim le maintenir. Un essaim (swarm) est un groupe de machines Docker qui agissent comme une seule : on lui soumet une pile, il place les conteneurs, les surveille et les recrée s'ils tombent.
- Les noeuds : des gestionnaires qui décident (et élisent un chef) et des travailleurs qui exécutent. Deux jetons différents pour joindre l'un ou l'autre.
- Les services et les tâches : un service déclare une image et un nombre de répliques; chaque réplique est une tâche, un conteneur placé sur un noeud. Si le noeud tombe, la tâche renaît ailleurs : c'est la réconciliation.
- La pile (stack) : une partition Compose enrichie d'une section deploy (répliques, contraintes de placement, politique de redémarrage), levée par docker stack deploy.
- Le réseau overlay : les services se parlent d'un noeud à l'autre et se trouvent par leur nom, grâce au DNS interne de l'essaim.
- Le maillage de routage : un port publié répond sur tous les noeuds, que la tâche y tourne ou non. L'essaim achemine la demande.
Les notions de la semaine sont détaillées dans le diaporama Notions - Docker Swarm.
La mission et ce qu'on vous fournit
MISSION : Le site de Cornucopia, décrit en partition la semaine dernière, renaît sur un essaim de cinq noeuds : trois répliques WordPress derrière un proxy inverse Traefik, une base de données ancrée, et une tâche qui renaît ailleurs quand un noeud tombe. Flora ouvre son école d'horticulture, la ferme grandit : l'agence lui donne une infrastructure qui survit à une panne.
| Sauvegarde | sauvegarde-cornucopia-formation.zip (39 Mo) : fichiers-wordpress/ (le site, avec abonnement/ et la nouveauté de la semaine, l'école formation/), base-de-donnees.sql et README.md. Le site original : cornucopia.projet.autos. |
|---|---|
| Images | traefik:1.7, wordpress:7.1, mysql:8.0 et dockersamples/visualizer. Rien à construire : les deux piles complètes sont dans le guide. |
| Comptes | Tableau de bord : agence, flora, hazel, mot de passe cornucopia-2026. Base cornucopia, compte flora / potager-2026, root racine-potager-2026. |
| Noeuds | swarm-node01 192.168.56.10 (gestionnaire, chef), 02 .20 et 03 .30 (gestionnaires), 04 .40 (travailleur, porte la base) et 05 .50 (travailleur). |
| Vous écrivez | traefik.yml et wordpress-sticky.yml (les deux piles) et votre README.md avec le journal des commandes. |
Pré-requis : le laboratoire Compose complété, une machine virtuelle Ubuntu Server clonable avec Docker et le plugin Compose. Le matériel dans le GUIDE
Le plan du laboratoire
Cinq noeuds, deux piles, un service, en six étapes. Le guide pas-à-pas déroule chacune en détail :
Cinq clones avec Docker, nommés swarm-node01 à 05, adressés .10 à .50.
Résultat : les noeuds se trouvent par leur nom.
Guide · 01Le chef initialise, deux gestionnaires et deux travailleurs rejoignent, chacun avec son jeton.
Résultat : cinq noeuds Ready au node ls.
Guide · 02Le réseau overlay, puis la première pile : Traefik, ancré sur un gestionnaire.
Résultat : le tableau de bord répond sur 9090.
Guide · 03Le site de Cornucopia déballé sur les deux travailleurs, DB_HOST, repointage sur swarm-node04.
Résultat : le terrain est prêt, rien n'est déployé.
Guide · 04La pile Cornucopia : base ancrée, WordPress en trois répliques, la boutique, la panne volontaire.
Résultat : 3/3 et 1/1, la boutique répond, une tâche renaît.
Guide · 05Un service de plus, créé d'une commande, qui dessine les noeuds et leurs tâches.
Résultat : l'essaim en direct sur le port 5000.
Guide · 06Le dessin du laboratoire : WordPress sur un Docker Swarm
L'architecture cible : ce que vous aurez monté
Étape 01 · Machines : ce qu'il faut faire
MISSION : Préparer cinq machines virtuelles avec Docker, qui se connaissent par leur nom.
Tâches :
- Cloner la machine de base (Docker et le plugin Compose installés) en cinq noeuds swarm-node01 à swarm-node05.
- Sur chacun : le nom dans /etc/hostname, le carnet des cinq noeuds dans /etc/hosts, sans ligne 127.0.0.1 pour le noeud lui-même.
- L'adresse par netplan : .10, .20, .30, .40, .50 sur 192.168.56.0/24, cloud-init désactivé, puis redémarrage.
Résultat attendu : depuis swarm-node01, ping swarm-node05 répond, et docker compose version répond sur chaque noeud. Respectez l'adressage à la lettre : tout le reste du laboratoire en dépend. Suivre le GUIDE
Étape 02 · Essaim : ce qu'il faut faire
MISSION : Monter l'essaim : trois gestionnaires qui peuvent tous devenir chef, deux travailleurs.
Tâches :
- Sur swarm-node01 : docker swarm init --advertise-addr 192.168.56.10, puis docker swarm join-token manager pour obtenir le second jeton.
- swarm-node02 et 03 rejoignent avec le jeton de gestionnaire; swarm-node04 et 05 avec le jeton de travailleur, celui du init.
- Depuis un gestionnaire : docker node ls.
Résultat attendu : cinq noeuds Ready, un Leader, deux Reachable, deux travailleurs. Un essaim opérationnel, géré comme une seule machine Docker. Suivre le GUIDE
Étape 03 · Proxy : ce qu'il faut faire
MISSION : Créer le réseau overlay et déployer la première pile, Traefik, le proxy inverse qui routera le trafic vers WordPress.
Tâches :
- Depuis swarm-node01 : docker network create -d overlay net.
- Écrire traefik.yml dans /home/docker/swarm/ : l'image traefik:1.7, les ports 80 et 9090, la socket Docker, une réplique ancrée sur un gestionnaire, le réseau net.
- docker stack deploy --compose-file=/home/docker/swarm/traefik.yml traefik.
Résultat attendu : après deux ou trois minutes, le tableau de bord Traefik répond sur http://192.168.56.10:9090, encore vide, et docker service ls montre traefik_loadbalancer en 1/1. Suivre le GUIDE
Étape 04 · Sauvegarde : ce qu'il faut faire
MISSION : Déposer le site existant de Cornucopia sur les deux travailleurs, prêt à être transplanté. L'essaim ne copie jamais un fichier d'un noeud à l'autre.
Tâches :
- Sur swarm-node04 ET swarm-node05 : déballer la sauvegarde dans /home/docker/swarm/sauvegarde, donner fichiers-wordpress à www-data.
- Sur les deux : une ligne de wp-config.php, DB_HOST devient db:3306.
- Sur swarm-node04 seulement : le repointage de l'adresse vers http://192.168.56.10, ajouté à la fin de l'export, avant le premier déploiement.
Résultat attendu : sur les deux travailleurs, ls montre les trois éléments de la sauvegarde et grep DB_HOST répond db:3306; sur swarm-node04, tail sur l'export montre les requêtes de repointage. Rien n'est encore déployé. Suivre le GUIDE
Étape 05 · Services : ce qu'il faut faire
MISSION : Déployer la pile Cornucopia : la base ancrée sur swarm-node04, WordPress en trois répliques derrière Traefik, puis prouver la réconciliation.
Tâches :
- Écrire wordpress-sticky.yml : db en une réplique, ancrée par node.hostname, avec l'export dans initdb; wordpress:7.1 en 3 répliques sur les travailleurs, étiquettes Traefik avec sessions persistantes, fichiers montés; pas de variables WORDPRESS_*.
- docker stack deploy, puis service ls, service ps avec le filtre desired-state=Running, service logs de la base. Le premier déploiement est long.
- Visiter la boutique sur le port 80, entrer au tableau de bord avec flora, publier un article avec une image; voir les trois serveurs dans Traefik.
- La panne volontaire : drainer ou éteindre un travailleur qui porte une réplique, jamais swarm-node04.
Résultat attendu : WordPress 3/3 et db 1/1, la boutique de Flora et son article illustré répondent par n'importe quel noeud, et une tâche renaît sur l'autre travailleur quand son noeud tombe. Suivre le GUIDE
Étape 06 · Visualiseur : ce qu'il faut faire
MISSION : Déployer le visualiseur de Docker, un service créé d'une seule commande, pour voir l'essaim en direct.
Tâches :
- Depuis swarm-node01 : docker service create avec le nom viz, le port 5000 publié vers 8080, la contrainte node.role==manager, la socket Docker montée, l'image dockersamples/visualizer.
- docker service ps viz avec le filtre desired-state=Running.
- Rejouer la panne volontaire de l'étape 05 en regardant le visualiseur.
Résultat attendu : http://192.168.56.10:5000 montre les cinq noeuds et leurs tâches : Traefik et viz sur des gestionnaires, la base sur swarm-node04, les trois WordPress sur les travailleurs. Les cinq conteneurs du barème sont en place. Suivre le GUIDE
Livrables et barème
Ce que vous remettez, dans le dossier swarm/ de votre dépôt Git :
- traefik.yml et wordpress-sticky.yml : les deux piles telles que déployées.
- README.md : votre infrastructure (VirtualBox, DinD ou VPS) et son plan d'adressage, le journal des commandes, les comptes de démonstration, ce que vous avez observé à la panne volontaire.
- Jamais la sauvegarde, ni le répertoire database.
Ce que vous démontrez : le node ls à cinq noeuds, le tableau de bord Traefik avec ses trois serveurs, la boutique et son article illustré par n'importe quel noeud, le visualiseur, et une tâche qui renaît après la panne d'un noeud.
Le détail : Laboratoires Application conteneurisée.
Laboratoire 3 · Semaine 4 · 10 points
| 1 conteneur Traefik au visualiseur | 2 |
| 3 conteneurs WordPress | 2 |
| 1 conteneur MySQL | 2 |
| 1 conteneur Visualiseur | 2 |
| Article avec image affiché dans le navigateur | 2 |
| Total | 10 |
Cinq noeuds selon votre infrastructure, référence 192.168.56.10 à .50. Respectez le guide à la lettre, surtout l'adressage. Premier déploiement long : les images se téléchargent sur chaque noeud.
Rappels importants, et la première pile
À gauche, traefik.yml, la première pile : une partition Compose plus une section deploy. La seconde, wordpress-sticky.yml, est dans le guide. Pour vérifier votre travail, les deux se téléchargent : traefik.yml et wordpress-sticky.yml.
- L'essaim ne copie pas les fichiers : la sauvegarde se déballe sur les deux travailleurs, au même chemin.
- Le repointage avant le premier déploiement : l'export n'est importé qu'une fois, quand database est vide sur swarm-node04.
- Deux jetons, deux rôles, et les commandes de gestion ne fonctionnent que sur un gestionnaire.
- Ne drainez jamais swarm-node04 : la base y est ancrée avec ses données. L'état s'ancre, le sans-état se réplique.
- Le premier déploiement est long, et les tâches en Shutdown Failed ne sont pas graves : filtre desired-state=Running.
- L'adresse du site est celle du chef : la seule valeur qui varie avec votre adressage.
- Sessions persistantes : chaque travailleur sert sa copie des fichiers, un téléversement ne traverse pas d'une réplique à l'autre.
Pour aller plus loin
Défis facultatifs, décrits dans le guide :
- Défi A · Passer à l'échelle : WordPress à 4 répliques avec docker service scale, observer le placement dans le visualiseur, puis redescendre à 2.
- Défi B · Sans le proxy : le port 30000 du maillage de routage répond sur un noeud sans réplique. Que deviennent les sessions persistantes ?
- Défi C · L'essaim minimal : 1 gestionnaire + 2 travailleurs sur l'infrastructure de votre choix, DinD, VirtualBox ou VPS.
- Défi D · L'école d'horticulture : formation/, une application Node.js autonome, mérite son propre service dans la pile.
Vos documents : Le GUIDE pas-à-pas traefik.yml wordpress-sticky.yml L'énoncé de l'évaluation
La base reste en une seule réplique, ancrée : sa haute disponibilité est l'affaire du module 2. Le chemin parcouru en trois semaines : un conteneur, une partition, un essaim.