Orchestrez vos conteneurs avec Docker Swarm

Docker Swarm est le mode d’orchestration natif de Docker. En une seule commande (docker swarm init), vous transformez votre Docker Engine en un cluster capable de distribuer des conteneurs sur plusieurs machines, d’assurer la haute disponibilité et de gérer automatiquement les pannes. Contrairement à Kubernetes qui nécessite une installation séparée, Swarm est intégré à Docker et utilise les mêmes fichiers docker-compose.yml que vous connaissez déjà.

Swarm mode = Docker Engine

Swarm mode est une fonctionnalité intégrée à Docker Engine, pas un produit séparé. Il n’existe donc pas de “version Swarm” : quand vous mettez à jour Docker Engine, vous mettez à jour Swarm. Ne confondez pas avec “Docker Classic Swarm”, un projet abandonné.

Ce que vous allez apprendre

• Architecture Swarm : comprendre les nœuds managers et workers, l’algorithme Raft
• Services et tâches : déployer des applications avec état désiré et réplication
• Réseaux overlay : faire communiquer vos conteneurs à travers plusieurs hôtes
• Secrets et configs : gérer vos données sensibles de manière sécurisée
• Déploiement avancé : rolling updates, contraintes de placement, healthchecks
• Haute disponibilité : quorum, tolérance aux pannes, bonnes pratiques production

Prérequis

Avant de commencer, assurez-vous d’avoir :

• Docker installé (version 1.12+)
• Connaissances de base de Docker (images, conteneurs, volumes)
• Familiarité avec Docker Compose

Qu’est-ce que Docker Swarm ?

Docker Swarm est un outil d’orchestration de conteneurs intégré nativement à Docker. Il permet de regrouper plusieurs machines Docker (appelées nœuds) en un cluster unique, géré comme une seule entité.

Analogie : Imaginez un chef d’orchestre (le manager) qui dirige des musiciens (les workers). Le chef décide quelle partition jouer (quel service déployer), combien de musiciens par section (nombre de réplicas), et si un musicien s’absente, il redistribue sa partie aux autres.

Pourquoi choisir Swarm ?

Critère	Docker Swarm	Kubernetes
Installation	Intégré à Docker	Installation séparée complexe
Courbe d’apprentissage	Douce (commandes Docker)	Raide (nouveaux concepts)
Fichiers de config	docker-compose.yml	Manifests YAML spécifiques
Cas d’usage	Petits/moyens clusters	Grands clusters, multi-cloud
Fonctionnalités	Essentielles	Très complètes

Glissez pour voir

Quand choisir Swarm ?

Swarm est idéal pour les équipes qui connaissent déjà Docker et veulent une solution d’orchestration simple et rapide à mettre en place. Pour des besoins plus avancés (auto-scaling complexe, service mesh, multi-cluster), Kubernetes reste la référence.

Architecture de Docker Swarm

Un cluster Swarm est composé de deux types de nœuds avec des rôles distincts :

Nœuds managers et workers

Pour fonctionner, un cluster Swarm a besoin d’au moins un nœud manager. Ce manager est le cerveau de l’opération : il décide où placer les conteneurs, maintient l’état du cluster et expose l’API pour recevoir vos commandes. Les nœuds workers sont les exécutants : ils reçoivent les instructions du manager et font tourner les conteneurs.

Concrètement, quand vous tapez docker service create, votre commande arrive sur un manager qui décide sur quel(s) nœud(s) lancer les conteneurs, puis envoie les ordres aux workers concernés.

Type	Rôle	Responsabilités
Manager	Cerveau du cluster	Orchestration, planification, API, stockage de l’état (Raft)
Worker	Bras du cluster	Exécution des conteneurs

Glissez pour voir

Manager = Worker par défaut

Par défaut, un manager exécute aussi des conteneurs. Pour dédier un manager uniquement à l’orchestration, passez-le en mode drain : docker node update --availability drain <node>.

Services et tâches

Dans Swarm, vous ne déployez pas des conteneurs directement, mais des services :

• Service : Définition déclarative avec un état désiré (image, réplicas, ports, ressources). Swarm s’assure que l’état réel correspond toujours à cet état désiré.
• Tâche (Task) : Instance d’un service = 1 conteneur. Si vous demandez 3 réplicas, Swarm crée 3 tâches.

Exemple : Un service web avec 3 réplicas crée 3 tâches (web.1, web.2, web.3), chacune étant un conteneur nginx.

Algorithme Raft et haute disponibilité

Docker Swarm utilise l’algorithme de consensus Raft pour synchroniser l’état du cluster entre les managers :

1. Un leader est élu parmi les managers
2. Toutes les modifications passent par le leader
3. Le leader réplique les changements aux followers
4. Les décisions nécessitent un quorum (majorité)

Toujours un nombre impair de managers

Le quorum nécessite (N/2)+1 nœuds disponibles. Avec 3 managers, le quorum est 2 (tolère 1 panne). Avec 5, le quorum est 3 (tolère 2 pannes). Évitez les nombres pairs : 4 managers tolèrent autant de pannes que 3 !

Quorum et tolérance aux pannes

Le quorum est le nombre minimum de managers qui doivent être disponibles pour que le cluster puisse prendre des décisions. C’est une notion fondamentale pour comprendre la haute disponibilité de Swarm.

Prenons un exemple concret : avec 3 managers, le quorum est de 2. Si un manager tombe en panne, les 2 restants peuvent continuer à fonctionner. Mais si 2 managers tombent, le dernier ne peut plus rien décider seul et le cluster devient indisponible pour les opérations d’écriture (création de services, scaling…).

Le calcul est simple : quorum = (N/2) + 1 où N est le nombre de managers.

Managers	Quorum	Pannes tolérées
1	1	0
2	2	0 ⚠️
3	2	1
5	3	2
7	4	3

Glissez pour voir

Notez que 2 managers ne tolèrent aucune panne (quorum = 2, donc les 2 doivent être up). C’est pourquoi Docker recommande 3 managers minimum en production pour avoir une vraie tolérance aux pannes.

Combien de managers ?

Docker ne fixe pas de limite au nombre de managers. Cependant, plus il y en a, plus les écritures (changements d’état) sont lentes car davantage de nœuds doivent acquitter via Raft. En pratique, 3 ou 5 managers couvrent la plupart des besoins. Gardez toujours un nombre impair pour optimiser le quorum.

Initialisation d’un cluster Docker Swarm

1. Initialiser le cluster

   Transformez votre Docker Engine en nœud manager :

   docker swarm init

   Résultat attendu :

   Swarm initialized: current node (abc123) is now a manager.
   
   To add a worker to this swarm, run:
       docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377
   
   To add a manager to this swarm, run 'docker swarm join-token manager'

   Serveur multi-interfaces

   Si votre serveur a plusieurs IPs, spécifiez celle à utiliser : docker swarm init --advertise-addr 192.168.1.10

2. Vérifier l’état du cluster

   docker node ls

   Sortie :

   ID            HOSTNAME   STATUS   AVAILABILITY   MANAGER STATUS   ENGINE VERSION
   abc123 *      server1    Ready    Active         Leader           24.0.7

   • * indique le nœud courant
   • Leader indique le manager actif pour Raft
   • Active signifie que le nœud accepte des tâches

Ajout de nœuds

Pour ajouter des nœuds au cluster, récupérez d’abord les tokens :

# Token pour ajouter un worker
docker swarm join-token worker

# Token pour ajouter un manager
docker swarm join-token manager

Puis sur la nouvelle machine :

docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377

Sécurité des tokens

Ne partagez jamais le token manager publiquement. Il donne un accès complet au cluster. Pour régénérer un token (invalide l’ancien) : docker swarm join-token --rotate worker

Ports réseau requis

Si vos nœuds sont sur des machines différentes (ce qui est le cas en production), ils doivent pouvoir communiquer entre eux. Swarm utilise trois ports distincts, chacun avec un rôle précis :

• Le port 2377 est le plus important : c’est par là que les managers communiquent entre eux (algorithme Raft) et que vous envoyez vos commandes docker. C’est l’API de gestion du cluster.
• Le port 7946 sert aux échanges d’informations entre tous les nœuds (managers et workers). C’est le protocole “gossip” qui permet aux nœuds de se découvrir et de partager leur état.
• Le port 4789 transporte le trafic réseau entre vos conteneurs sur différents hôtes. C’est la technologie VXLAN qui crée un réseau virtuel au-dessus de votre réseau physique.

Port	Protocole	Usage
2377	TCP	Communication de gestion (API Swarm, Raft)
7946	TCP + UDP	Communication entre nœuds (gossip)
4789	UDP	Trafic overlay (VXLAN)

Glissez pour voir

Si vous utilisez un firewall comme ufw ou firewalld, pensez à ouvrir ces ports entre vos nœuds avant de créer votre cluster.

Sécurité du port 4789 (VXLAN)

Le port 4789 utilise VXLAN qui n’authentifie pas le trafic. Ne l’exposez jamais sur un réseau non fiable. En cas de conflit avec un autre service, vous pouvez changer ce port avec docker swarm init --data-path-port <port>.

Création et gestion des services

Créer un service

La commande docker service create crée un service avec l’état désiré :

docker service create \
  --name web \
  --replicas 3 \
  -p 80:80 \
  nginx

Cette commande :

• Crée un service nommé web
• Lance 3 conteneurs nginx (réplicas)
• Publie le port 80 sur tous les nœuds

Vérification :

docker service ls

ID            NAME   MODE         REPLICAS   IMAGE          PORTS
abc123        web    replicated   3/3        nginx:latest   *:80->80/tcp

Services globaux vs répliqués

Swarm propose deux modes de déploiement qui répondent à des besoins différents.

Le mode replicated (par défaut) est celui que vous utiliserez le plus souvent : vous demandez un nombre précis de conteneurs, et Swarm les répartit intelligemment sur les nœuds disponibles. Par exemple, “je veux 5 instances de mon API” — Swarm décide sur quels serveurs les placer.

Le mode global est plus spécifique : il lance exactement une instance par nœud du cluster. C’est idéal pour les agents de monitoring comme Prometheus Node Exporter, les collecteurs de logs comme Fluentd, ou tout service qui doit tourner sur chaque machine. Quand un nouveau nœud rejoint le cluster, il reçoit automatiquement sa propre instance.

Mode	Description	Cas d’usage
replicated (défaut)	Nombre fixe de réplicas	Applications web, APIs
global	1 tâche par nœud	Monitoring, log collectors

Glissez pour voir

# Service global (1 instance par nœud)
docker service create --name node_exporter --mode global prom/node-exporter

Avec le mode global, pas besoin de spécifier --replicas : le nombre de conteneurs correspond toujours au nombre de nœuds dans le cluster.

Mise à l’échelle des services

Deux syntaxes équivalentes pour scaler :

# Syntaxe courte (plusieurs services possibles)
docker service scale web=5 api=3

# Syntaxe longue (combinable avec d'autres options)
docker service update --replicas 5 web

Vérifier le scaling :

docker service ps web

ID       NAME    IMAGE   NODE      STATE     CURRENT STATE
abc1     web.1   nginx   server1   Running   Running 5 minutes ago
abc2     web.2   nginx   server2   Running   Running 2 minutes ago
abc3     web.3   nginx   server1   Running   Running 2 minutes ago
abc4     web.4   nginx   server3   Running   Running 30 seconds ago
abc5     web.5   nginx   server2   Running   Running 30 seconds ago

Fichiers stack.yml vs Docker Compose

Docker Swarm utilise le même format de fichier déclaratif que Docker Compose. Vous pouvez réutiliser vos fichiers docker-compose.yml avec quelques adaptations.

Différences clés

Bien que les fichiers soient au même format YAML, certaines directives fonctionnent différemment selon que vous utilisez docker compose up (environnement local) ou docker stack deploy (Swarm).

Format Compose legacy v3

docker stack deploy utilise un format Compose legacy v3 et n’implémente pas toutes les fonctionnalités de la spec Compose moderne. Certaines options récentes de docker compose ne fonctionneront pas avec les stacks Swarm.

La différence principale concerne le build : en local, Compose peut construire vos images à la volée depuis un Dockerfile. En Swarm, c’est impossible car les workers n’ont pas accès à votre code source — vous devez utiliser des images déjà construites et poussées dans un registry.

De même, depends_on qui garantit l’ordre de démarrage en local n’a pas de sens dans un cluster distribué où les conteneurs peuvent être sur des machines différentes. Swarm ignore cette directive.

En contrepartie, Swarm ajoute la section deploy qui permet de configurer le nombre de réplicas, les contraintes de placement sur certains nœuds, et les stratégies de mise à jour progressive.

Fonctionnalité	Docker Compose	Docker Swarm
build	✅ Supporté	❌ Ignoré (images pré-buildées)
depends_on	✅ Supporté	❌ Ignoré
deploy	❌ Ignoré	✅ Configuration Swarm
deploy.replicas	—	Nombre de réplicas
deploy.placement	—	Contraintes de placement
deploy.update_config	—	Stratégie de rolling update

Glissez pour voir

Exemple de stack complète

stack.yml

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        failure_action: rollback
      restart_policy:
        condition: on-failure
        max_attempts: 3
    networks:
      - frontend

  api:
    image: mon-api:latest
    deploy:
      replicas: 2
      placement:
        constraints:
          - node.role == worker
    secrets:
      - db_password
    networks:
      - frontend
      - backend

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    secrets:
      - db_password
    networks:
      - backend

networks:
  frontend:
  backend:

volumes:
  db_data:

secrets:
  db_password:
    external: true

Configuration des services

La section deploy offre de nombreuses options :

deploy:
  # Nombre de conteneurs
  replicas: 3

  # Limites de ressources
  resources:
    limits:
      cpus: '0.5'
      memory: 256M
    reservations:
      cpus: '0.25'
      memory: 128M

  # Stratégie de mise à jour
  update_config:
    parallelism: 2        # Conteneurs mis à jour simultanément
    delay: 10s            # Pause entre les lots
    failure_action: rollback  # rollback|pause|continue
    order: start-first    # start-first|stop-first

  # Politique de redémarrage
  restart_policy:
    condition: on-failure
    max_attempts: 3
    window: 120s

Déploiement de stacks

Déployer une stack

docker stack deploy -c stack.yml ma_stack

Sortie :

Creating network ma_stack_frontend
Creating network ma_stack_backend
Creating secret ma_stack_db_password
Creating service ma_stack_web
Creating service ma_stack_api
Creating service ma_stack_db

Les services sont automatiquement préfixés par le nom de la stack (ma_stack_).

Gérer les stacks

# Lister les stacks
docker stack ls

# Services d'une stack
docker stack services ma_stack

# Tâches d'une stack
docker stack ps ma_stack

# Supprimer une stack
docker stack rm ma_stack

Mettre à jour une stack

Pour appliquer des modifications, relancez simplement docker stack deploy :

docker stack deploy -c stack.yml ma_stack

Swarm détecte les changements et applique un rolling update automatiquement.

Réseaux overlay

Les réseaux overlay permettent aux conteneurs de communiquer à travers plusieurs hôtes comme s’ils étaient sur le même réseau local.

Fonctionnement

1. Swarm crée automatiquement le réseau ingress pour le routing mesh
2. Chaque stack obtient un réseau par défaut
3. Les réseaux overlay utilisent VXLAN pour l’encapsulation

Créer un réseau overlay

docker network create \
  --driver overlay \
  --subnet 10.0.1.0/24 \
  mon_reseau

Routing mesh et load balancing

Le routing mesh est un load balancer intégré à Swarm. Quand vous publiez un port (-p 80:80) :

1. Tous les nœuds écoutent sur ce port
2. Le trafic est automatiquement redirigé vers un conteneur du service
3. C’est transparent pour le client

Exemple : Avec 3 nœuds et un service web sur le nœud 2, vous pouvez accéder au service depuis n’importe quel nœud (1, 2 ou 3).

Modes de publication des ports

Swarm offre deux façons de publier les ports de vos services, avec des comportements très différents.

Le mode ingress (par défaut) active le routing mesh : le port est ouvert sur tous les nœuds du cluster, même ceux qui n’exécutent pas de conteneur pour ce service. C’est pratique car vous pouvez pointer votre load balancer externe vers n’importe quel nœud, et Swarm redirigera le trafic vers un conteneur actif.

Le mode host bind le port uniquement sur les nœuds où le conteneur tourne réellement. C’est utile dans deux cas : quand vous avez besoin de connaître l’IP réelle du client (le routing mesh fait du NAT qui masque l’IP source), ou pour des performances maximales en évitant la couche de routage supplémentaire.

Mode	Description	Cas d’usage
ingress (défaut)	Port publié sur tous les nœuds via routing mesh	Applications web standard
host	Port bindé uniquement sur les nœuds où la tâche tourne	Bypass du mesh, IP client réelle

Glissez pour voir

ports:
  - target: 80
    published: 80
    mode: host  # ou ingress (défaut)

Attention avec le mode host : si vous avez 3 réplicas mais seulement 2 nœuds, le 3ème conteneur ne pourra pas démarrer (conflit de port).

Services internes

Pour un service qui ne doit pas être exposé (ex: base de données) :

1. Ne publiez pas de port
2. Les autres services y accèdent via le DNS Swarm

services:
  db:
    image: postgres:15
    # Pas de section "ports"
    networks:
      - backend

  api:
    image: mon-api
    environment:
      DATABASE_URL: postgres://db:5432/app  # DNS interne
    networks:
      - backend

Le nom du service (db) devient un hostname résolvable par tous les services sur le même réseau.

Gestion des secrets

Les secrets Docker Swarm stockent des données sensibles de manière sécurisée :

• Chiffrés au repos dans le store Raft des managers
• Chiffrés en transit via TLS mutuel entre les nœuds
• Accessibles uniquement aux services Swarm autorisés (pas aux conteneurs standalone)
• Montés en tmpfs (mémoire) dans /run/secrets/

Créer un secret

# Depuis un fichier
docker secret create db_password password.txt

# Depuis stdin (plus sûr)
echo "mon_mot_de_passe" | docker secret create db_password -

# Ou avec un fichier
printf "mon_mot_de_passe" | docker secret create db_password -

Utiliser un secret dans un service

docker service create \
  --name api \
  --secret db_password \
  mon-api

Dans le conteneur, le secret est disponible dans /run/secrets/db_password.

Secrets dans une stack

services:
  api:
    image: mon-api
    secrets:
      - db_password
      - source: api_key
        target: /app/config/api.key
        mode: 0400

secrets:
  db_password:
    external: true  # Secret déjà créé
  api_key:
    file: ./secrets/api.key  # Créé au déploiement

Bonne pratique : _FILE

Beaucoup d’images officielles supportent les variables *_FILE :

environment:
  POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
  - db_password

Gestion des nœuds

Lister et inspecter

# Lister les nœuds
docker node ls

# Détails d'un nœud
docker node inspect server1 --pretty

États de disponibilité

Chaque nœud Swarm possède un état de disponibilité qui contrôle s’il peut recevoir des tâches. Comprendre ces trois états est essentiel pour gérer correctement la maintenance de votre cluster.

L’état active est le fonctionnement normal : le nœud accepte de nouvelles tâches et celles qu’il exécute continuent de tourner.

L’état pause est utile pour une maintenance légère : le nœud garde ses tâches existantes mais le scheduler ne lui en assignera plus de nouvelles. C’est pratique si vous voulez empêcher temporairement un nœud de recevoir du travail sans perturber ce qui tourne déjà.

L’état drain est le plus radical : Swarm évacue toutes les tâches du nœud vers d’autres nœuds disponibles. Utilisez-le avant un reboot, une mise à jour système, ou toute opération qui nécessite d’arrêter le nœud.

État	Description	Usage
active	Accepte de nouvelles tâches	Fonctionnement normal
pause	Pas de nouvelles tâches, tâches existantes continuent	Maintenance légère
drain	Évacue toutes les tâches vers d’autres nœuds	Maintenance lourde

Glissez pour voir

Maintenance des nœuds

1. Mettre le nœud en drain

   docker node update --availability drain server1

   Swarm replanifie automatiquement les tâches sur d’autres nœuds.

2. Effectuer la maintenance (reboot, mise à jour Docker, etc.)

3. Réactiver le nœud

   docker node update --availability active server1

Promotion et rétrogradation

# Promouvoir un worker en manager
docker node promote server2

# Rétrograder un manager en worker
docker node demote server3

Attention au quorum

Ne rétrogradez pas un manager si cela fait passer le nombre de managers sous le quorum !

Stratégies de mise à jour

Docker Swarm permet des rolling updates contrôlés :

Configuration via YAML

deploy:
  update_config:
    parallelism: 2      # Tâches mises à jour en parallèle
    delay: 10s          # Pause entre les lots
    failure_action: rollback  # En cas d'échec
    monitor: 30s        # Temps de surveillance après update
    max_failure_ratio: 0.1  # Ratio d'échecs toléré
    order: start-first  # Démarrer avant d'arrêter

Configuration via CLI

docker service update \
  --update-parallelism 2 \
  --update-delay 10s \
  --update-failure-action rollback \
  --image nginx:1.25 \
  web

Rollback automatique

Avec failure_action: rollback, Swarm annule automatiquement si trop de tâches échouent.

Rollback manuel :

docker service rollback web

Bonnes pratiques haute disponibilité

Pour qu’un cluster Swarm soit vraiment résilient en production, quelques règles simples font toute la différence.

La première concerne le nombre de managers : toujours impair (3 ou 5) pour optimiser le quorum. Trois managers tolèrent une panne, cinq en tolèrent deux. Docker ne fixe pas de limite, mais plus vous ajoutez de managers, plus les écritures Raft sont lentes.

Ensuite, répartissez vos managers géographiquement : sur différents racks, différentes zones de disponibilité, voire différents datacenters. Si tous vos managers sont sur le même rack et qu’il prend feu, vous perdez tout.

Côté services, les healthchecks sont indispensables : sans eux, Swarm ne sait pas si votre application fonctionne vraiment. Un conteneur peut tourner mais être planté — le healthcheck permet de le détecter et de le remplacer automatiquement.

Enfin, configurez toujours vos rolling updates avec rollback automatique. Si une nouvelle version de votre application plante, Swarm reviendra automatiquement à la version précédente au lieu de casser tout votre service.

En résumé :

1. Toujours un nombre impair de managers (3 ou 5 recommandés)
2. Distribuer les managers sur différentes zones/racks
3. Limiter le nombre de managers si les performances d’écriture comptent
4. Utiliser des healthchecks pour détecter les services défaillants
5. Configurer des rolling updates avec rollback automatique
6. Monitorer le leader Raft (docker node ls)
7. Rotater les tokens périodiquement (ex: tous les 6 mois)

Contraintes de placement

Les contraintes contrôlent où les tâches peuvent s’exécuter :

Contraintes disponibles

Les contraintes utilisent des attributs des nœuds pour filtrer où vos conteneurs peuvent s’exécuter. Vous pouvez utiliser des attributs intégrés (rôle, hostname, ID) ou créer vos propres labels.

Les labels personnalisés sont particulièrement puissants : vous pouvez par exemple labelliser vos nœuds par zone géographique (zone=europe), par type de stockage (storage=ssd), ou par environnement (env=production). Ensuite, vous contraignez vos services à ne tourner que sur les nœuds correspondants.

La syntaxe utilise les opérateurs == (égal) et != (différent). Vous pouvez combiner plusieurs contraintes — elles doivent toutes être satisfaites pour qu’un nœud soit éligible.

Contrainte	Description	Exemple
node.role	Rôle du nœud	node.role == worker
node.hostname	Nom d’hôte	node.hostname == server1
node.id	ID du nœud	node.id == abc123
node.labels.*	Labels personnalisés	node.labels.zone == europe
engine.labels.*	Labels Docker Engine	engine.labels.storage == ssd

Glissez pour voir

Exemple : workers uniquement

deploy:
  placement:
    constraints:
      - node.role == worker

Exemple : zone géographique

# Ajouter un label au nœud
docker node update --label-add zone=europe server1

# Contraindre le service
docker service create \
  --name api \
  --constraint 'node.labels.zone == europe' \
  mon-api

Préférences (soft placement)

Les préférences répartissent les tâches sans bloquer si impossible :

deploy:
  placement:
    preferences:
      - spread: node.labels.zone

Gestion des ressources

Limites et réservations

deploy:
  resources:
    limits:
      cpus: '0.5'      # 50% d'un CPU max
      memory: 256M     # 256 Mo max
    reservations:
      cpus: '0.25'     # Garantit 25% d'un CPU
      memory: 128M     # Garantit 128 Mo

Via CLI :

docker service create \
  --name api \
  --limit-cpu 0.5 \
  --limit-memory 256M \
  --reserve-cpu 0.25 \
  --reserve-memory 128M \
  mon-api

Comportement des limites

• Les réservations influencent le scheduling : une tâche n’est planifiée que si le nœud a assez de ressources réservées disponibles.
• Les limites sont des hard limits : si dépassées, l’OOM killer peut tuer le conteneur.

Healthchecks

Les healthchecks permettent à Swarm de vérifier la santé réelle des conteneurs :

Configuration dans l’image

HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
  CMD curl -f http://localhost/health || exit 1

Configuration dans le service

docker service create \
  --name web \
  --health-cmd "curl -f http://localhost/health || exit 1" \
  --health-interval 30s \
  --health-timeout 10s \
  --health-retries 3 \
  nginx

Configuration dans la stack

services:
  web:
    image: nginx
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Une tâche n’est considérée running que si le healthcheck passe. Les tâches unhealthy sont automatiquement remplacées.

Rotation des certificats

Docker Swarm utilise TLS pour sécuriser les communications. Les certificats doivent être renouvelés régulièrement.

Rotation manuelle

docker swarm ca --rotate

Cette commande :

1. Régénère le certificat CA
2. Met à jour les certificats de tous les nœuds
3. Les nœuds se reconnectent automatiquement

Configuration de l’expiration

# Certificats valides 90 jours
docker swarm update --cert-expiry 2160h

# Vérifier la configuration
docker swarm inspect --pretty

Bonne pratique sécurité

Effectuez une rotation des certificats tous les 90 jours maximum, ou immédiatement après une compromission suspectée.

Dépannage

Commandes de diagnostic

# État des nœuds
docker node ls

# Services et leur état
docker service ls

# Tâches d'un service (avec historique)
docker service ps web --no-trunc

# Logs d'un service
docker service logs -f web

# Logs avec timestamp
docker service logs --since 10m --timestamps web

# Détails d'un service
docker service inspect web --pretty

Problèmes courants et solutions

Voici les problèmes que vous rencontrerez le plus souvent avec Swarm, et comment les résoudre.

Quand un service affiche 0/3 réplicas, c’est généralement que l’image n’est pas accessible. Vérifiez d’abord le nom et le tag (nginx:latest vs nginx:1.25), puis assurez-vous que vos workers peuvent accéder au registry (authentification avec docker login si nécessaire).

Une tâche en Pending signifie que Swarm ne trouve pas de nœud capable de l’exécuter. La cause la plus fréquente : vous avez défini des réservations de ressources (--reserve-memory 4G) mais aucun nœud n’a autant de mémoire disponible. Réduisez les réservations ou ajoutez des nœuds plus puissants.

L’état Rejected indique qu’une contrainte de placement n’est pas satisfaite. Par exemple, vous demandez node.labels.zone == europe mais aucun nœud n’a ce label. Utilisez docker node inspect pour voir les labels existants.

Si vous avez perdu le quorum (majorité des managers down), votre cluster ne peut plus accepter de modifications. Essayez d’abord de remettre des managers en ligne. En dernier recours, utilisez --force-new-cluster sur un manager survivant.

Symptôme	Cause probable	Solution
Service 0/3 réplicas	Image non trouvée	Vérifier le nom/tag de l’image, login registry
Tâche en Pending	Ressources insuffisantes	Réduire réservations ou ajouter des nœuds
Tâche en Rejected	Contrainte non satisfaite	Vérifier --constraint, ajouter labels
Réseau non trouvé	Réseau pas encore créé	Le réseau se crée au 1er service, attendre
Perte du quorum	Majorité des managers down	Forcer un nouveau cluster si irrécupérable

Glissez pour voir

Forcer un nouveau cluster (urgence)

Si vous avez perdu le quorum et ne pouvez pas récupérer les managers :

# Sur un manager survivant
docker swarm init --force-new-cluster

Perte de données possible

Cette commande crée un nouveau cluster avec l’état du nœud courant uniquement. Les tâches sur les autres nœuds seront perdues.

À retenir

Docker Swarm est une solution d’orchestration qui brille par sa simplicité. Si vous savez utiliser Docker et Docker Compose, vous savez déjà utiliser Swarm à 80%.

Les concepts clés à retenir :

1. Docker Swarm est natif : intégré à Docker, utilise les mêmes fichiers Compose
2. Managers vs Workers : les managers orchestrent, les workers exécutent
3. Raft assure la cohérence : toujours un nombre impair de managers (3 ou 5)
4. Services = état désiré : Swarm maintient automatiquement le nombre de réplicas
5. Overlay = communication multi-hôtes : les conteneurs communiquent comme sur un même réseau
6. Routing mesh : tout nœud peut recevoir le trafic pour n’importe quel service
7. Secrets chiffrés : jamais en clair, uniquement en mémoire dans le conteneur
8. Rolling updates : déploiements progressifs avec rollback automatique

Swarm n’est pas aussi riche en fonctionnalités que Kubernetes, mais pour beaucoup de cas d’usage, sa simplicité est un avantage considérable. Commencez par Swarm pour comprendre les concepts d’orchestration, vous pourrez toujours migrer vers Kubernetes plus tard si vos besoins évoluent.

Contrôles de Connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

📝 10 questions

⏱️ 15 min.

🎯 70%

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

▶ Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Docker Compose Maîtrisez les fichiers Compose avant de passer à Swarm

Traefik Reverse proxy et load balancer pour vos services Swarm

Kubernetes L'étape suivante : orchestration avancée à grande échelle

Découverte de l'orchestration Comprendre les concepts fondamentaux de l'orchestration

×

📖 Voir la documentation →