Docker swarm

Fiche express
Type	Orchestrateur multi-hôtes natif à Docker
Rôles	Manager (contrôle) · Worker (exécution)
Objets pilotés	Service · Stack · Node
Alternative	Kubernetes (orchestration plus riche, plus complexe)
Voir aussi	Docker node · Docker service · Docker stack · Docker compose

Docker Swarm est le mode d'orchestration multi-hôtes intégré nativement au moteur Docker : il permet de fédérer plusieurs machines exécutant Docker en un cluster unique et d'y répartir des conteneurs sous forme de services et de stacks. Il ne nécessite aucun composant externe — Docker suffit — ce qui en fait une alternative plus légère à Kubernetes pour des besoins d'orchestration simples.

Cette page présente la vue d'ensemble du cluster (init, adhésion, sauvegarde, sécurisation, haute disponibilité). Le détail des objets manipulés au quotidien est traité sur des pages dédiées : gestion des nœuds sur Docker node, définition et cycle de vie des services sur Docker service, déploiement de piles multi-services sur Docker stack et Docker compose.

Architecture

Un cluster Swarm est composé de deux rôles de nœuds :

• Manager — maintient l'état du cluster (via un consensus Raft entre managers), planifie les services sur les workers et expose l'API de contrôle.
• Worker — exécute les tâches (conteneurs) qui lui sont assignées par les managers.

<mermaid> flowchart LR

   subgraph Managers
       M1[Manager 1
leader]
       M2[Manager 2]
       M3[Manager 3]
   end
   subgraph Workers
       W1[Worker 1]
       W2[Worker 2]
   end
   M1 <-->|Raft| M2
   M1 <-->|Raft| M3
   M1 -->|planification| W1
   M1 -->|planification| W2

</mermaid>

Un nœud manager peut aussi exécuter des tâches (comportement par défaut), mais en production on réserve généralement les managers au contrôle du cluster.

Initialisation du cluster

Prérequis : Docker doit être installé sur chaque machine appelée à rejoindre le cluster.

Sur le futur manager :

docker swarm init --advertise-addr <IP_PRIVEE_MANAGER>

docker info
docker node ls

Quitter le cluster (sur un nœud, manager ou worker) :

docker swarm leave --force

Faire rejoindre un worker

Sur le manager, récupérer le jeton d'adhésion :

docker swarm join-token worker

Sur le futur worker, avec le jeton et l'adresse du manager renvoyés par la commande précédente :

docker swarm join --token <TOKEN_JOIN> <IP_MANAGER>:2377

Sur le manager, vérifier l'adhésion :

docker node ls

Un jeton distinct existe pour joindre en tant que manager (docker swarm join-token manager) ; il est à réserver aux nœuds réellement destinés au rôle de contrôle.

Administration

• Gestion des nœuds (étiquetage, contraintes de placement) : voir Docker node.
• Création et cycle de vie des services (répliques, mode global, mise à jour) : voir Docker service.
• Déploiement d'une pile multi-services à partir d'un fichier compose : voir Docker stack et Docker compose.

Sauvegarde et restauration

L'état du cluster (Raft, certificats) est stocké dans /var/lib/docker/swarm. La sauvegarde se fait démon arrêté, sur un manager :

# Sauvegarde (sur un manager)
sudo systemctl stop docker
sudo tar -zcvf backup-swarm.tar.gz -C /var/lib/docker/swarm .
sudo systemctl start docker

# Restauration (sur un manager)
sudo systemctl stop docker
sudo rm -rf /var/lib/docker/swarm/*
sudo tar -zxvf backup-swarm.tar.gz -C /var/lib/docker/swarm/
sudo systemctl start docker
docker node ls

Si le cluster ne comptait qu'un seul manager, la restauration recrée ce même manager ; pour un cluster multi-managers, se référer à la procédure officielle de récupération de quorum (--force-new-cluster), plus nuancée qu'une simple restauration de fichiers (à vérifier selon version).

Sécurisation

Le chiffrement au repos des clés de communication inter-nœuds (autolock) peut être activé :

docker swarm update --autolock=true

La commande renvoie une clé de déverrouillage à conserver impérativement dans un gestionnaire de secrets : sans elle, un manager redémarré reste bloqué et ne rejoint plus le cluster.

sudo systemctl restart docker
docker node ls          # le manager reste verrouillé tant qu'il n'est pas déverrouillé
docker swarm unlock     # demande la clé

Gestion de la clé :

docker swarm unlock-key            # ré-afficher la clé actuelle
docker swarm unlock-key --rotate   # générer une nouvelle clé

Désactivation :

docker swarm update --autolock=false

Haute disponibilité

Le nombre de managers doit être impair : le consensus Raft tolère la perte de (N-1)/2 managers sans perte de quorum. Au-delà de 7, le surcoût de consensus dépasse généralement le gain de résilience (à vérifier selon la charge du cluster).

Managers	Tolérance de panne
3	1 manager perdu
5	2 managers perdus
7	3 managers perdus

Il est recommandé de répartir les managers sur des zones de disponibilité distinctes pour éviter qu'une panne de zone n'emporte la majorité du quorum.

Voir aussi

• Docker node — étiquetage et contraintes de placement
• Docker service — définition et cycle de vie des services
• Docker stack — déploiement de piles multi-services
• Docker compose — fichiers de définition multi-conteneurs
• Docker plugins — extensions du moteur (volumes, réseaux)