Compose règle le graphe local. Un fichier déclare les services, leurs images, les réseaux, les volumes, les variables, parfois un healthcheck et un depends_on. docker compose up crée ce petit système sur un moteur Docker. C’est la bonne réponse à « comment mon collègue démarre API, worker, Postgres et Mailhog sans six onglets de documentation ».
Ce n’est pas un orchestrateur de production distribué. Compose ne place pas de réplicas sur plusieurs machines, ne fait pas de rolling update avec budget de surge, ne reschedule pas un conteneur sur un autre nœud, ne fournit pas d’ingress ni de secrets d’entreprise. Un restart: unless-stopped n’est pas un ReplicaSet.
services:
api:
image: monapp:1.4.2
ports: ["8080:8080"]
environment:
DATABASE_URL: postgres://app@db:5432/app
depends_on:
db:
condition: service_healthy
db:
image: postgres:16
volumes: [pgdata:/var/lib/postgresql/data]
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app"]Ça, Compose le fait très bien. « On a trois nœuds, on veut zéro downtime et un rollback » : vous êtes sorti du contrat.
Que vous ne dites ni « Compose c’est Kubernetes pour les nuls » ni « Compose ne sert à rien en prod ». Les deux sont faux.
Compose en production existe : une VM, deux services, un volume, un reverse-proxy. C’est un choix assumé, avec des limites d’exploitation. Ce qui coûte l’entretien, c’est de croire que depends_on attend que l’API soit prête. Sans condition service_healthy, il attend que le conteneur existe. L’API démarre, Postgres n’écoute pas encore, et vous « corrigez » par un sleep.
« Alors on met Compose dans le cluster ? »
Non. Dans un cluster, le graphe devient Deployment, Service, Probe, ConfigMap. Docker (ou un autre runtime) fabrique et tire l’image ; Kubernetes la fait tenir. C’est le découpage de Docker ou Kubernetes : qui fait quoi.
« Compose v2, Swarm, Compose sur Kubernetes ? »
Swarm n’est plus le pari d’un nouvel existant. Compose reste l’outil de poste et de CI d’intégration. Le nommer clairement évite vingt minutes de folklore.