infra / docker
Orchestrateurs : Swarm, Kubernetes et au-delà
Explication
Ce que vous allez apprendre
- Comprendre les limites de Docker Compose et pourquoi un orchestrateur devient nécessaire à plusieurs machines
- Initialiser un cluster Docker Swarm et y déployer un service répliqué
- Réaliser un rolling update et un rollback immédiat avec Swarm
- Comparer objectivement Swarm et Kubernetes selon la complexité, l'écosystème et l'adoption industrielle
- Choisir l'orchestrateur adapté au contexte plutôt que de suivre un effet de mode
Dans quel contexte ?
Une startup a fait grandir son application sur un seul serveur avec Docker Compose depuis un an. Le trafic a triplé, et une panne matérielle récente a mis le service hors ligne pendant deux heures — un seul point de défaillance devenu inacceptable. Plutôt que de se lancer directement dans Kubernetes, jugé disproportionné pour son équipe de trois développeurs, elle migre vers un petit cluster Docker Swarm de trois machines, en réutilisant presque tel quel son fichier docker-compose.yml existant via docker stack deploy.
Les limites de Docker Compose, une bonne machine
Docker Compose, vu plus tôt dans le cours, gère parfaitement une pile de conteneurs sur UNE SEULE machine. Mais dès qu'une application doit résister à la panne d'un serveur entier, ou répartir sa charge sur plusieurs machines physiques, il faut un système capable de gérer un ensemble de machines comme s'il s'agissait d'une seule ressource unifiée — c'est exactement la définition d'un orchestrateur.
| Critère | Swarm | Kubernetes |
|---|---|---|
| Courbe d'apprentissage | Faible | Élevée |
| Écosystème | Limité | Immense (Helm, operators...) |
| Adoption industrie | En net déclin | Standard de facto |
Astuce
docker stack deploy -c docker-compose.yml ma-stack réutilise directement un fichier Compose existant sur un cluster Swarm : c'est souvent le chemin le plus rapide et le moins risqué pour passer d'une seule machine à un cluster résilient, avant d'envisager, si le besoin le justifie vraiment, une migration vers Kubernetes.
Ce que fait concrètement un orchestrateur
Un orchestrateur prend en charge des responsabilités qu'un simple docker run ne gère jamais tout seul : décider sur quelle machine placer chaque conteneur, relancer automatiquement un conteneur tombé en panne (auto-guérison), répartir le trafic entre plusieurs instances, et faciliter les mises à jour progressives sans interruption de service.
Swarm : le prolongement naturel de Compose
Docker Swarm a l'avantage d'être directement intégré à Docker, avec une syntaxe très proche de celle déjà connue de Compose (le fichier docker-compose.yml peut d'ailleurs être réutilisé presque tel quel via docker stack deploy). C'est le chemin le plus court pour passer d'un seul serveur à un petit cluster résilient, sans devoir apprendre un tout nouvel écosystème.
Kubernetes : plus complexe, mais devenu le standard
Kubernetes répond au même besoin général mais avec beaucoup plus de concepts distincts (Pod, Deployment, Service...) et une courbe d'apprentissage nettement plus raide. Malgré cette complexité, il s'est imposé comme le standard de facto de l'industrie pour la production à grande échelle, porté par un écosystème considérable (Helm pour packager des applications, les opérateurs pour automatiser des tâches complexes, etc.).
Comment choisir en pratique
Il ne s'agit pas de choisir "le meilleur" dans l'absolu, mais le bon outil pour le contexte : Swarm convient très bien à une petite équipe ou un cluster simple ; Kubernetes se justifie surtout à partir d'une échelle et d'une complexité organisationnelle qui rendent son investissement rentable. Il existe aussi des alternatives à connaître de nom (Nomad, ECS, ou des solutions "sans orchestrateur visible" comme Cloud Run) selon le contexte cloud utilisé.
Commandes & code
Orchestrateurs : Swarm, Kubernetes et au-delà
# Un orchestrateur gère un CLUSTER de machines : placement des conteneurs, scaling,
# auto-guérison (redémarrage), rolling updates, découverte de service, secrets.
# Docker seul (sans Compose ni Swarm) ne gère qu'UNE machine à la fois.# --- Docker Swarm : orchestrateur intégré à Docker, le plus simple à démarrer ---
docker swarm init --advertise-addr 10.0.1.10 # transforme le nœud courant en manager
docker swarm join-token worker # affiche la commande à lancer sur chaque worker
docker node ls # liste tous les nœuds du cluster (managers + workers)
docker node update --availability drain node-2 # vide un nœud avant maintenance (drain)
docker service create --name api --replicas 3 -p 8000:8000 mon-api:1.0
docker service scale api=6 # change le nombre de réplicas à chaud
docker service update --image mon-api:1.1 --update-parallelism 1 --update-delay 10s api
docker service ps api # état de chaque réplica, sur quel nœud
docker service rollback api # retour immédiat à la version précédente| Critère | Docker Swarm | Kubernetes |
|---|---|---|
| Courbe d'apprentissage | faible, syntaxe proche de Compose | élevée, nombreux concepts (Pod, Deployment, Service...) |
| Mise en place | intégrée à Docker, quelques commandes | cluster à provisionner (kubeadm, managé cloud...) |
| Écosystème | limité | immense (Helm, operators, service mesh, CRDs) |
| Auto-scaling avancé | basique | HPA/VPA natifs, très configurable |
| Adoption industrie | en net déclin | standard de facto en production |
| Cas d'usage typique | petite équipe, cluster simple, prototypage rapide | production à grande échelle, multi-équipe |
# --- Un service Swarm et son équivalent conceptuel Kubernetes, côte à côte ---
# Swarm (docker-compose.yml en mode "deploy")
services:
api:
image: mon-api:1.0
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
restart_policy:
condition: on-failure
ports:
- "8000:8000"
# Kubernetes : le MÊME besoin nécessite deux ressources distinctes (Deployment + Service)
# apiVersion: apps/v1
# kind: Deployment
# spec:
# replicas: 3
# strategy: { type: RollingUpdate, rollingUpdate: { maxUnavailable: 1 } }
# ---
# apiVersion: v1
# kind: Service
# spec:
# ports: [{ port: 8000 }]# Déployer une stack complète sur Swarm depuis un fichier compose existant
docker stack deploy -c docker-compose.yml ma-stack
docker stack services ma-stack
docker stack rm ma-stack
# --- Autres orchestrateurs à connaître de nom ---
# Nomad (HashiCorp) -> plus généraliste (pas que des conteneurs), plus simple que K8s
# ECS (AWS) -> orchestrateur managé propriétaire, intégré à l'écosystème AWS
# Cloud Run / ACI -> "sans orchestrateur visible", scaling de conteneurs à la requêteRésumé
- Swarm reste le chemin le plus rapide pour passer de
docker composeà un vrai cluster multi-machines avec rolling updates. - Kubernetes a gagné l'adoption industrie grâce à son écosystème (Helm, operators) malgré une complexité bien supérieure à Swarm.
docker stack deployréutilise directement un fichierdocker-compose.ymlexistant — le point d'entrée naturel avant d'envisager Kubernetes.
Exercices pratiques
Mission : sortir du single point of failure après une panne de deux heures
Objectif : Migrer une stack Compose vers un cluster Swarm résilient et exécuter un déploiement sans interruption.
Contexte
Une application tourne depuis un an sur un seul serveur avec Docker Compose. Une panne matérielle récente a coupé le service pendant deux heures. L'équipe de trois développeurs juge Kubernetes disproportionné et choisit de migrer vers un petit cluster Swarm de trois machines.