Administration - Notre lab

Docker Compose et Infrastructure as Code¶

Jusqu’ici, chaque conteneur était lancé manuellement avec docker run. Cette approche fonctionne pour tester ou découvrir, mais elle pose problème en production : les commandes ne sont pas sauvegardées, l’ordre de démarrage doit être respecté manuellement, et reproduire l’environnement sur une autre machine demande de retaper chaque commande en espérant n’en oublier aucune.

Docker Compose résout ces problèmes en décrivant toute une pile applicative dans un fichier texte docker-compose.yml : services, réseaux, volumes, variables d’environnement, ordre de démarrage. Une seule commande (docker-compose up) suffit ensuite pour déployer l’ensemble, quelle que soit la machine.

Ce principe — décrire une infrastructure dans des fichiers texte plutôt que de l’assembler à la main — s’appelle l’Infrastructure as Code (IaC). Il est au cœur des pratiques modernes d’administration système et DevOps.

Les bénéfices concrets de l’IaC :

Reproductibilité : le même fichier produit le même résultat sur n’importe quel poste ou serveur
Versionnement : le fichier docker-compose.yml est versionné dans Git comme n’importe quel code source — on voit qui a modifié quoi, quand, et pourquoi
Automatisation : un pipeline CI/CD peut déployer ou mettre à jour la pile sans intervention humaine
Documentation implicite : le fichier est une description lisible de l’architecture, plus fiable qu’un wiki qui se désynchronise
Réversibilité : revenir à une version précédente consiste à rétablir un fichier dans Git et relancer docker-compose up

Docker Compose est une première étape vers des outils d’IaC plus avancés comme Ansible (configuration de machines), Terraform (provisionnement d’infrastructure cloud) ou Kubernetes (orchestration à grande échelle). Le principe reste le même : l’infrastructure se décrit, ne se clique pas.

Structure d’un fichier docker-compose.yml¶

Un fichier docker-compose.yml est organisé en quatre sections principales, toutes au même niveau de la hiérarchie YAML.

docker-compose.yaml

services:    # les conteneurs de la pile
volumes:     # les volumes nommés persistants
networks:    # les réseaux virtuels
configs:     # fichiers de configuration injectés (Swarm uniquement)

Balises pouvant être présentes dans docker-compose.yaml

Le format YAML est sensible à l’indentation : utiliser exclusivement des espaces (jamais de tabulations), et respecter scrupuleusement l’alignement.

La section services est la seule obligatoire. Chaque service décrit un conteneur :

docker-compose.yaml

services:

  nom-du-service:            # nom utilisé comme nom DNS sur le réseau
    image: nginx:alpine      # image Docker à utiliser
    container_name: web      # nom du conteneur (optionnel)
    ports:
      - "8080:80"            # port-hote:port-conteneur
    volumes:
      - ./html:/usr/share/nginx/html:ro   # bind mount
      - data-app:/var/lib/mysql           # volume nommé
    networks:
      - reseau-frontend      # réseaux auxquels se connecter
    environment:
      MYSQL_DATABASE: wordpress           # variable d environnement inline
    env_file:
      - .env                 # variables chargées depuis un fichier
    depends_on:
      - db                   # attend que db soit démarré avant
    restart: unless-stopped  # politique de redémarrage

Exemple de docker-compose.yaml

La section volumes déclare les volumes nommés. Un volume déclaré ici est géré par Docker et persiste entre redémarrages :

volumes:
  data-app:     # créé automatiquement au premier docker-compose up
  logs-apache:  # peut être préfixé du nom du projet

Configuration des volumes

La section networks déclare les réseaux. Sans déclaration, Compose crée un réseau par défaut. Avec des réseaux explicites, on contrôle l’isolation :

networks:
  reseau-frontend:
    driver: bridge   # driver par défaut, peut être omis
  reseau-backend:
    driver: bridge

Configuration des réseaux

Commandes essentielles :

Commande	Action
`docker-compose up -d`	Démarrer la pile en mode détaché
`docker-compose down`	Arrêter et supprimer les conteneurs et réseaux
`docker-compose down -v`	Idem + supprimer les volumes
`docker-compose ps`	État des services
`docker-compose logs -f NOM`	Logs en temps réel d’un service
`docker-compose exec NOM CMD`	Exécuter une commande dans un service actif
`docker-compose pull`	Mettre à jour les images
`docker-compose restart NOM`	Redémarrer un service sans toucher aux autres

Limiter les ressources CPU et mémoire

Par défaut, un conteneur peut consommer l’intégralité des ressources de l’hôte. En production, il est indispensable de poser des limites pour éviter qu’un service défaillant ne pénalise les autres. C’est le rôle des Cgroups (Control Groups) du noyau Linux, que Docker expose via la clé deploy.resources.

services:

  wordpress:
    image: wordpress:latest
    deploy:
      resources:
        limits:
          cpus: "0.50"       # au maximum 50 % d un coeur CPU
          memory: 512M       # au maximum 512 Mo de RAM
        reservations:
          cpus: "0.25"       # garantis : 25 % d un coeur reserve
          memory: 256M       # garantis : 256 Mo de RAM reserve

  db:
    image: mariadb:10.11
    deploy:
      resources:
        limits:
          cpus: "1.00"       # au maximum 1 coeur complet
          memory: 1G         # au maximum 1 Go de RAM
        reservations:
          memory: 512M

Paramétrage des ressources

Clé	Valeur	Effet
`limits.cpus`	`"0.50"`	Le conteneur ne peut pas dépasser 50 % d’un cœur
`limits.memory`	`512M`, `1G`	Le conteneur est tué (OOMKill) s’il dépasse cette limite
`reservations.cpus`	`"0.25"`	Docker garantit cette capacité même sous charge
`reservations.memory`	`256M`	Mémoire réservée sur l’hôte au démarrage

Note

La clé deploy est pleinement supportée en Swarm. En mode Compose standard (sans Swarm), elle est ignorée pour les contraintes de placement mais les limites CPU/mémoire sont bien appliquées depuis Compose v2 avec le moteur Docker Desktop ou Docker Engine récent. Pour forcer les limites sans Swarm, on peut aussi utiliser directement les clés mem_limit et cpus au niveau du service (syntaxe Compose v2) :

services:
  wordpress:
    image: wordpress:latest
    mem_limit: 512m
    cpus: 0.50

Paramétrage des ressources pour Wordpress

Docker Compose progressif¶

Ces exercices reprennent les architectures construites dans les pages précédentes et les traduisent en fichiers docker-compose.yml. L’objectif est de passer du pilotage manuel par docker run à un pilotage déclaratif reproductible.

01. Compose — WordPress + MariaDB sur un réseau personnalisé¶

Exercise

Durée estimée : 20 min

Objectif : traduire en docker-compose.yml l’architecture de l’exercice autonomie 02 de la page Volumes & Réseaux : WordPress et MariaDB sur un réseau personnalisé, sans volumes persistants.

Étape 1 — Créer un répertoire compose-step1 et y placer un fichier .env avec les variables MariaDB et WordPress utilisées dans les exercices précédents.

Étape 2 — Rédiger un fichier docker-compose.yml qui déclare les services db (MariaDB 10.11) et wordpress (wordpress:latest), les connecte sur un réseau wp-net, et expose WordPress sur le port 8080. Utiliser env_file pour charger les variables. Ajouter depends_on pour que WordPress ne démarre qu’après MariaDB.

Étape 3 — Démarrer la pile, vérifier que la page d’installation WordPress s’affiche sur http://localhost:8080, et confirmer que db est joignable depuis wordpress par son nom de service.

Étape 4 — Arrêter et supprimer la pile, puis nettoyer le répertoire.

Critères de validation

docker-compose ps montre les deux services actifs
La page d’installation WordPress s’affiche sur http://localhost:8080
docker-compose down supprime les conteneurs et le réseau

Solution to Exercise #

Structure du répertoire :

compose-step1/
  .env
  docker-compose.yml

Les paramètres de configuration de la base de données sont dans un fichier .env.

.env

MYSQL_ROOT_PASSWORD=rootpass
MYSQL_DATABASE=wordpress
MYSQL_USER=wp
MYSQL_PASSWORD=wppass
WORDPRESS_DB_HOST=db
WORDPRESS_DB_USER=wp
WORDPRESS_DB_PASSWORD=wppass
WORDPRESS_DB_NAME=wordpress

Configuration des volumes

Fichier docker-compose.yml :

docker-compose.yaml

services:

  db:
    image: mariadb:10.11
    env_file:
      - .env
    networks:
      - wp-net
    restart: unless-stopped

  wordpress:
    image: wordpress:latest
    env_file:
      - .env
    ports:
      - "8080:80"
    networks:
      - wp-net
    depends_on:
      - db
    restart: unless-stopped

networks:
  wp-net:
    driver: bridge

Paramétrage des services

Commandes :

mkdir compose-step1 && cd compose-step1
# Creer .env et docker-compose.yml
docker-compose up -d
docker-compose ps
curl http://localhost:8080 | head -5
docker-compose exec wordpress ping -c 2 db
docker-compose down
cd .. && rm -rf compose-step1

Avantage par rapport à docker run :

`docker run`	`docker-compose`
2 commandes séparées	`docker-compose up -d`
Ordre manuel	`depends_on`
Réseau créé manuellement	Déclaré dans le fichier
Nettoyage en 4 commandes	`docker-compose down`

02. Compose — WordPress + MariaDB avec volumes séparés et deux réseaux¶

Exercise

Durée estimée : 25 min

Objectif : traduire en docker-compose.yml l’architecture de l’exercice autonomie 04 (volumes) de la page Volumes & Réseaux : WordPress et MariaDB avec wp-data, wp-logs, et deux réseaux séparés (wp-frontend, wp-backend).

Étape 1 — Créer un répertoire compose-step2 et y placer le même fichier .env que l’étape précédente.

Étape 2 — Rédiger un docker-compose.yml avec deux réseaux (wp-frontend, wp-backend), deux volumes nommés (wp-data, wp-logs), le service db (sur wp-backend uniquement, avec wp-data), et le service wordpress (sur les deux réseaux, avec wp-logs).

Étape 3 — Démarrer la pile, générer du trafic sur http://localhost:8080, puis lire les logs Apache depuis le volume wp-logs via un conteneur Alpine temporaire.

Étape 4 — Arrêter la pile sans supprimer les volumes (docker-compose down sans -v), puis la redémarrer. Vérifier que les données MariaDB sont toujours présentes.

Étape 5 — Arrêter et tout supprimer (avec -v), puis nettoyer le répertoire.

Critères de validation

db n’est pas accessible depuis wp-frontend
Le volume wp-logs contient un access.log peuplé
Après redémarrage sans -v, les données MariaDB sont intactes

Solution to Exercise #

Fichier docker-compose.yml :

services:

  db:
    image: mariadb:10.11
    env_file:
      - .env
    volumes:
      - wp-data:/var/lib/mysql    # donnees persistantes
    networks:
      - wp-backend                # backend uniquement : db non accessible depuis frontend
    restart: unless-stopped

  wordpress:
    image: wordpress:latest
    env_file:
      - .env
    volumes:
      - wp-logs:/var/log/apache2  # logs Apache
    ports:
      - "8080:80"
    networks:
      - wp-frontend               # reseau web
      - wp-backend                # reseau base de donnees
    depends_on:
      - db
    restart: unless-stopped

volumes:
  wp-data:    # donnees MariaDB
  wp-logs:    # logs Apache

networks:
  wp-frontend:
    driver: bridge
  wp-backend:
    driver: bridge

Vérifier l’isolation réseau :

# db inaccessible depuis wp-frontend
docker-compose exec wordpress ping -c 2 db     # succes : wordpress est sur les deux reseaux
docker run --rm \
  --network compose-step2_wp-frontend \
  alpine ping -c 2 db                          # echec : pas de route vers db

Lire les logs depuis le volume :

docker run --rm \
  -v compose-step2_wp-logs:/logs \
  alpine tail -5 /logs/access.log

Redémarrage sans perte de données :

docker-compose down           # stoppe et supprime les conteneurs, conserve les volumes
docker-compose up -d          # les donnees MariaDB sont intactes
docker-compose down -v        # supprime aussi les volumes

03. Compose — Architecture complète avec Nginx en load balancer¶

Exercise

Durée estimée : 30 min

Objectif : traduire en docker-compose.yml l’exercice final de la page Volumes & Réseaux : Nginx devant un ou plusieurs WordPress, avec réseaux et volumes séparés.

Étape 1 — Créer un répertoire compose-final avec le fichier .env et le fichier nginx.conf utilisé dans l’exercice final.

Étape 2 — Rédiger un docker-compose.yml avec trois services (db, wordpress, nginx), deux réseaux (wp-frontend, wp-backend), deux volumes (wp-data, wp-logs). Nginx est le seul service à exposer un port sur l’hôte. Le service wordpress n’est pas directement accessible.

Étape 3 — Démarrer la pile, vérifier que http://localhost:8080 affiche WordPress au travers de Nginx.

Étape 4 (avancé) — Ajouter un second service wordpress2 identique au premier. Mettre à jour nginx.conf. Recharger Nginx (docker-compose exec nginx nginx -s reload). Vérifier la distribution du trafic.

Étape 5 — Arrêter et supprimer la pile.

Critères de validation

http://localhost:8080 affiche WordPress via Nginx
Nginx est le seul conteneur avec un port exposé
db n’est accessible que depuis wp-backend

Solution to Exercise #

Structure du répertoire :

compose-final/
  .env
  nginx.conf
  docker-compose.yml

Fichier nginx.conf : (identique à l’exercice final de la page précédente)

Fichier docker-compose.yml :

services:

  db:
    image: mariadb:10.11
    env_file:
      - .env
    volumes:
      - wp-data:/var/lib/mysql
    networks:
      - wp-backend
    restart: unless-stopped

  wordpress:
    image: wordpress:latest
    env_file:
      - .env
    volumes:
      - wp-logs:/var/log/apache2
    networks:
      - wp-frontend
      - wp-backend
    depends_on:
      - db
    # pas de ports : seul nginx est expose
    restart: unless-stopped

  # wordpress2:            # decommenter pour le load balancing
  #   image: wordpress:latest
  #   env_file:
  #     - .env
  #   volumes:
  #     - wp-logs:/var/log/apache2
  #   networks:
  #     - wp-frontend
  #     - wp-backend
  #   depends_on:
  #     - db
  #   restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "8080:80"                          # seul point d entree
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro  # configuration en bind mount
    networks:
      - wp-frontend
    depends_on:
      - wordpress
    restart: unless-stopped

volumes:
  wp-data:
  wp-logs:

networks:
  wp-frontend:
    driver: bridge
  wp-backend:
    driver: bridge

Commandes :

mkdir compose-final && cd compose-final
# Creer .env, nginx.conf et docker-compose.yml
docker-compose up -d
docker-compose ps
curl http://localhost:8080 | head -5
docker logs compose-final-nginx-1   # logs Nginx
docker-compose down -v
cd .. && rm -rf compose-final

Pour le load balancing (step 4) :

# Decommenter wordpress2 dans docker-compose.yml
# Mettre a jour nginx.conf : ajouter server wordpress2:80
docker-compose up -d --scale wordpress=1   # wordpress2 demarre
docker-compose exec nginx nginx -s reload  # recharger sans interruption

Comparaison des étapes du fil directeur :

Étape	Architecture	Nouveauté
EX-01 Compose	WordPress + MariaDB, 1 réseau	Translate `docker run` → Compose
EX-02 Compose	+ volumes séparés, 2 réseaux	Persistance et isolation
EX-03 Compose	+ Nginx LB, N WordPress	Reverse proxy, load balancing
EX-12 (suivant)	Compose complet avec variables	Administration et cycle de vie

04. Docker Compose : application multi-conteneurs¶

Exercise (Orchestrer une application web + base de données)

Durée estimée : 1 h

Objectif : écrire un fichier docker-compose.yml pour déployer une application composée d’un service web Nginx et d’une base de données MariaDB, avec réseau et volumes partagés.

Étape 1 — Créer le répertoire du projet

mkdir projet-compose && cd projet-compose

Étape 2 — Créer le contenu web

html/index.html

<!DOCTYPE html>
<html>
<head><title>Application multi-conteneurs</title></head>
<body>
  <h1>Application multi-conteneurs</h1>
  <p>Web : Nginx | BDD : MariaDB</p>
</body>
</html>

Contenu de la page web

Étape 3 — Créer le fichier de variables

.env

MYSQL_ROOT_PASSWORD=rootpass123
MYSQL_DATABASE=appdb
MYSQL_USER=appuser
MYSQL_PASSWORD=apppass123
EOF

Variables d’environnement

Étape 4 — Rédiger le docker-compose.yml

docker-compose.yaml

services:

  web:
    image: nginx:alpine
    container_name: compose-web
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    networks:
      - reseau-app
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mariadb:10.11
    container_name: compose-db
    env_file:
      - .env
    volumes:
      - données-db:/var/lib/mysql
    networks:
      - reseau-app
    restart: unless-stopped

volumes:
  données-db:

networks:
  reseau-app:
    driver: bridge

Fichier docker-compose.yaml

Étape 5 — Démarrer et vérifier

docker-compose up -d
docker-compose ps
curl http://localhost:8080
docker-compose exec db mariadb -u root -prootpass123 -e "SHOW DATABASES;"

Étape 6 — Observer le cycle de vie

docker-compose stop
docker-compose ps
docker-compose start

Étape 7 — Mettre à jour un service sans toucher aux autres

echo "<h1>Mise à jour à chaud</h1>" > html/index.html
curl http://localhost:8080

Étape 8 — Nettoyer

docker-compose down -v
cd .. && rm -rf projet-compose

Solution to Exercise #

Résultat attendu de docker-compose ps :

NAME           IMAGE           SERVICE   STATUS         PORTS
compose-db     mariadb:10.11   db        Up 1 minute    3306/tcp
compose-web    nginx:alpine    web       Up 1 minute    0.0.0.0:8080->80/tcp

Résultat attendu de SHOW DATABASES; :

+--------------------+
| Database           |
+--------------------+
| appdb              |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

Section	Rôle
`services`	Définit chaque conteneur
`volumes`	Volumes nommés partagés
`networks`	Réseaux partagés entre services
`depends_on`	Ordonne le démarrage
`env_file`	Charge les variables depuis `.env`
`restart`	Politique de redémarrage

05. Administration en production¶

Exercise (Superviser, mettre à jour et maintenir des conteneurs)

Durée estimée : 45 min

Objectif : appliquer les méthodes d’administration en production — logs, mise à jour d’image, politique de redémarrage, nettoyage.

Prérequis : répertoire projet-compose de l’exercice précédent recréé et actif.

Étape 1 — Suivre les logs en production

docker-compose logs --follow web &
curl http://localhost:8080
curl http://localhost:8080/absent
kill %1

Étape 2 — Politique de redémarrage

docker run -d \
  --name svc-critique \
  --restart unless-stopped \
  nginx:alpine

docker stop svc-critique
docker ps -a
docker start svc-critique
docker inspect svc-critique | grep RestartPolicy -A 3

Étape 3 — Mettre à jour une image en production

# Tirer la nouvelle version
docker pull nginx:alpine

# Recréer uniquement le service web sans toucher à la base
docker-compose up -d --no-deps --build web
docker-compose ps

Étape 4 — Nettoyage

# Conteneurs arrêtés
docker container prune

# Images inutilisées
docker image prune

# Tout (conteneurs, images, réseaux inutilisés)
docker system prune

# Vérifier l'espace récupéré
docker system df

Étape 5 — Nettoyer l’environnement

docker stop svc-critique && docker rm svc-critique
docker-compose down -v
cd .. && rm -rf projet-compose

Solution to Exercise #

Résultat attendu de docker inspect sur la politique de redémarrage :

"RestartPolicy": {
    "Name": "unless-stopped",
    "MaximumRetryCount": 0
}

Politiques de redémarrage disponibles :

Politique	Comportement
`no` (défaut)	Pas de redémarrage automatique
`always`	Redémarre toujours, y compris au boot de l’hôte
`unless-stopped`	Redémarre sauf si arrêté manuellement
`on-failure[:N]`	Redémarre sur erreur, jusqu’à N fois

Résultat attendu de docker system df :

TYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLE
Images          5       2        312MB     180MB (57%)
Containers      1       1        0B        0B
Local Volumes   1       1        45MB      0B
Build Cache     0       0        0B        0B

06. Swarm : clustering et orchestration¶

Exercise (Initialiser un cluster Swarm et déployer une stack)

Durée estimée : 1 h

Objectif : initialiser un cluster Docker Swarm, déployer un service multi-réplica, observer la haute disponibilité et déployer une stack complète.

Étape 1 — Initialiser le Swarm et créer le manager

La commande docker swarm init transforme le noeud courant en manager du cluster. C’est lui qui prend les décisions d’orchestration : placement des conteneurs, détection des pannes, gestion des tokens d’invitation.

docker swarm init

Résultat attendu :

Swarm initialized: current node (abc123def456) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
      --token SWMTKN-1-xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx \
      192.168.1.10:2377

To add a manager to this swarm, run 'docker swarm join-token manager'
and follow the instructions.

Docker affiche immédiatement le token d’invitation pour les workers et indique comment en générer un pour un second manager.

Vérifier l’état du cluster :

docker node ls               # liste les noeuds du cluster
docker info | grep -A 5 "Swarm"   # informations globales du Swarm

Résultat attendu de docker node ls :

ID                            HOSTNAME    STATUS    AVAILABILITY   MANAGER STATUS
abc123def456 *                manager-1   Ready     Active         Leader

L’astérisque (*) indique le noeud courant. Leader signifie que ce manager est le noeud principal du cluster.

Note

Mode single-node : sur un seul poste, le cluster ne contient qu’un manager, sans worker. Swarm est pleinement fonctionnel — les services se déploient et la récupération automatique fonctionne — mais sans haute disponibilité réelle puisque tout tourne sur la même machine.

Les tokens d’invitation peuvent être récupérés à tout moment sur le manager, même en single-node, pour préparer l’ajout futur de noeuds :

docker swarm join-token worker    # token pour ajouter un worker
docker swarm join-token manager   # token pour ajouter un second manager

Les deux commandes affichent la commande complète à exécuter sur le noeud à joindre, incluant le token et l’adresse IP du manager.

Étape 2 — Ajouter un noeud worker

Un cluster Swarm est composé de managers (qui orchestrent) et de workers (qui exécutent les conteneurs). Lorsqu’on initialise un Swarm, la machine courante devient manager. Pour ajouter un autre noeud, deux étapes sont nécessaires : récupérer le token d’invitation sur le manager, puis l’exécuter sur la machine à joindre.

Sur le manager, récupérer le token d’invitation worker :

docker swarm join-token worker

Résultat attendu :

To add a worker to this swarm, run the following command:

    docker swarm join \
      --token SWMTKN-1-xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx \
      192.168.1.10:2377

Sur la machine à joindre (second serveur ou VM avec Docker installé), exécuter la commande affichée :

docker swarm join \
  --token SWMTKN-1-xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx \
  192.168.1.10:2377    # IP du manager : port Swarm (2377 par defaut)

Revenir sur le manager et vérifier que le noeud apparaît :

docker node ls

Résultat attendu :

ID                            HOSTNAME    STATUS    AVAILABILITY   MANAGER STATUS
abc123def456 *                manager-1   Ready     Active         Leader
def456abc789                  worker-1    Ready     Active

Note

Ports à ouvrir entre les noeuds pour que Swarm fonctionne :

Port	Protocole	Rôle
2377	TCP	Communication de gestion du cluster
7946	TCP + UDP	Communication inter-noeuds (gossip)
4789	UDP	Trafic réseau overlay (VXLAN)

Pour promouvoir un worker en manager (haute disponibilité) :

docker node promote worker-1

Pour retirer proprement un noeud du cluster :

# Sur le noeud à retirer
docker swarm leave

# Sur le manager, supprimer le noeud de la liste
docker node rm worker-1

Étape 3 — Déployer un service multi-réplica

docker service create \
  --name svc-web \
  --replicas 3 \
  --publish published=8080,target=80 \
  nginx:alpine

docker service ls
docker service ps svc-web

Étape 4 — Mettre à l’échelle

docker service scale svc-web=5
docker service ps svc-web

Étape 5 — Simuler une panne et observer la récupération automatique

CONTAINER_ID=$(docker ps --filter "name=svc-web" --format "{{.ID}}" | head -1)
docker rm -f $CONTAINER_ID

watch docker service ps svc-web

Arrêter le watch avec Ctrl+C. Observer la recréation automatique du réplica.

Étape 6 — Déployer une stack complète

mkdir stack-swarm && cd stack-swarm

cat > docker-compose.yml << 'EOF'
version: '3.8'

services:
  web:
    image: nginx:alpine
    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure
      update_config:
        parallelism: 1
        delay: 10s
    ports:
      - "9090:80"

  viz:
    image: dockersamples/visualizer:stable
    ports:
      - "8888:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      placement:
        constraints:
          - node.role == manager
EOF

docker stack deploy -c docker-compose.yml ma-stack
docker stack ls
docker stack services ma-stack
docker stack ps ma-stack

Visualiser le cluster sur http://localhost:8888

Étape 7 — Configuration réseau Swarm

# Les réseaux overlay sont créés automatiquement par la stack
docker network ls | grep overlay
docker network inspect ma-stack_default

Étape 8 — Nettoyer

docker stack rm ma-stack
docker service rm svc-web
docker swarm leave --force
cd .. && rm -rf stack-swarm

Solution to Exercise #

Résultat attendu de docker node ls :

ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS
abc123def456 *                monhote    Ready     Active         Leader

Résultat attendu après simulation de panne (étape 4) :

ID    NAME        IMAGE          NODE     DESIRED STATE   CURRENT STATE
aaaa  svc-web.1   nginx:alpine   monhote  Running         Running 2 min ago
bbbb  svc-web.2   nginx:alpine   monhote  Running         Running 2 min ago
cccc  svc-web.3   nginx:alpine   monhote  Shutdown        Failed 10 sec ago
dddd  svc-web.3   nginx:alpine   monhote  Running         Running 5 sec ago

Swarm a détecté la disparition du réplica et en a automatiquement créé un nouveau.

Section deploy dans le Compose pour Swarm :

Clé	Rôle
`replicas`	Nombre d’instances du service
`restart_policy`	Comportement en cas d’échec
`update_config`	Stratégie de mise à jour rolling
`placement.constraints`	Contraintes de placement sur les nœuds

	Compose	Swarm
Périmètre	1 hôte	Multi-hôtes
Réplication	Non	Oui
Load balancing	Non	Intégré
Haute disponibilité	Non	Oui
Réseau inter-nœuds	bridge	overlay chiffré