32 - Au-dela de Compose

Ce que tu vas apprendre

• Les limites reelles de Docker Compose en production
• Docker Swarm pour l'orchestration simple
• Kubernetes : les concepts de base sans le jargon
• Les services Kubernetes manages (GKE, EKS, AKS)
• Coolify et Dokku comme alternative du milieu
• Comment décider si tu as vraiment besoin d'un orchestrateur

Prerequisites

• Bien connaître Docker Compose et ses fonctionnalités avancees
• Avoir lu l'article sur la CI/CD pour comprendre le contexte de déploiement

Pendant deux ans, j'ai déployé tous mes projets avec Docker Compose et un script SSH. Ca marchait. Un serveur, cinq conteneurs, un docker compose pull && up -d dans la CI. Simple, comprehensible, fiable.

Et puis un client m'a demande de la haute disponibilité. Deux serveurs minimum, failover automatique, zero downtime. Compose ne sait pas faire ca. Il gere un seul hote. Quand le serveur tombe, tout tombe avec.

C'est la qu'on entre dans le monde des orchestrateurs.

Les limites de Compose

Compose fait beaucoup de choses bien. Mais il a des limites structurelles :

• Un seul hote : Compose deploie sur la machine ou tu lances la commande. Pas de distribution sur plusieurs serveurs.
• Pas d'auto-scaling : tu ne peux pas dire "lance entre 2 et 10 instances de mon API selon la charge".
• Pas de self-healing : si un conteneur unhealthy ne crashe pas, Compose ne fait rien. Il ne relance pas automatiquement les conteneurs defaillants (on en a parle dans l'article sur les healthchecks).
• Pas de rolling updates natifs : le redemarrage d'un service cause une interruption, meme brève.
• Pas de load balancing : distribuer le trafic entre plusieurs instances d'un meme service nécessité un reverse proxy configure manuellement.

Pour un projet perso, une startup en phase de validation, ou un service interne avec peu de trafic, ces limites sont acceptables. Pour du SaaS avec des SLA, elles deviennent problématiques.

Docker Swarm : l'orchestration intégrée

Swarm est le mode orchestration natif de Docker. Tu prends tes serveurs, tu les relies en cluster, et tu deploies tes services dessus.

bash# Sur le premier serveur (manager)
docker swarm init

# Sur les autres serveurs (workers)
docker swarm join --token SWMTKN-xxx manager-ip:2377

Tu deploies avec un fichier Compose standard en utilisant docker stack :

bashdocker stack deploy -c compose.yml mon-app

Swarm apporte ce qui manque a Compose :

• Distribution sur plusieurs noeuds
• Replicas et load balancing intégré
• Rolling updates automatiques
• Self-healing (redemarrage des conteneurs qui tombent)

yamlservices:
  api:
    image: ghcr.io/monorg/mon-app:1.2.3
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

Trois replicas, mis à jour un par un avec 10 secondes entre chaque. Si un conteneur crashe, Swarm le relance.

Le problème de Swarm : Docker l'a mis en maintenance passive. Pas déprécié officiellement, mais plus de nouvelles fonctionnalités. La communauté et l'ecosysteme se sont concentres sur Kubernetes. Tu peux l'utiliser, mais tu investis dans une technologie qui stagne.

Kubernetes : les concepts

Kubernetes (K8s) est l'orchestrateur dominant. Il est complexe, c'est indeniable. Mais les concepts de base sont comprehensibles.

Pod : l'unité de base. Un pod contient un ou plusieurs conteneurs qui partagent le meme réseau et le meme stockage. Dans la pratique, un pod = un conteneur dans 90% des cas.

Deployment : definit combien de replicas d'un pod tu veux. Kubernetes s'assure que ce nombre est respecte. Si un pod meurt, il en créé un nouveau.

yamlapiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/monorg/mon-app:1.2.3
          ports:
            - containerPort: 3000
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"

Service : expose un Deployment en interne ou en externe. C'est le load balancer de Kubernetes.

Ingress : route le trafic HTTP externe vers les Services. C'est l'équivalent du reverse proxy.

Si tu viens de Compose, la correspondance est :

Kubernetes manage

Personne ne devrait gerer son propre cluster Kubernetes. C'est un métier a plein temps. Les offres managees font le travail :

• GKE (Google) : le plus mature, l'Autopilot mode gere meme les noeuds
• EKS (AWS) : le plus utilise, intégration profonde avec l'ecosysteme AWS
• AKS (Azure) : bon choix si tu es deja sur Azure

Le coût commence autour de 70-100 euros par mois pour un petit cluster. Plus les machines. Plus le stockage. Ca monte vite.

Quand tu n'as PAS besoin de Kubernetes

La question que je pose toujours : est-ce que tu as un problème que Kubernetes resout ?

Tu n'as probablement pas besoin de K8s si :

• Tu as un seul serveur
• Tu as moins de 10 services
• Ton équipe fait moins de 5 personnes
• Tu n'as pas besoin d'auto-scaling
• Un redemarrage de 30 secondes est acceptable

La complexité de Kubernetes est réelle. Les fichiers YAML s'empilent. Le debugging est plus difficile. Le coût operationnel est significatif. Si tu n'as pas le problème, n'achete pas la solution.

J'ai vu des startups de trois personnes déployer sur Kubernetes parce que "ca fait pro". Six mois plus tard, ils passaient plus de temps a maintenir le cluster qu'a développer leur produit.

Le milieu : Coolify et Dokku

Entre Compose et Kubernetes, il y a des solutions qui apportent du confort sans la complexité.

Coolify : une plateforme de déploiement self-hosted. Tu l'installes sur un serveur, tu connectes ton repo Git, et il s'occupe du build, du deploy, des certificats SSL. Interface web, rollbacks en un clic, support natif de Docker Compose.

Dokku : le "mini Heroku" open source. Tu push ton code avec git push dokku main, il build et deploie. Simple, robuste, maintenu activement depuis 2013.

Les deux tournent sur un seul serveur. Pas de haute disponibilité, pas d'auto-scaling. Mais ils gerent les certificats Let's Encrypt, les reverse proxies, les zero-downtime deploys, et les rollbacks. C'est 80% de la valeur de Kubernetes pour 10% de la complexité.

Sur paltemps.fr, j'utilise Coolify pour les projets qui n'ont pas besoin de multi-serveur. Ca couvre la grande majorite de mes cas.

Comment choisir

Commence simple. Migre quand tu as le problème. Pas avant.

Résumé

• Compose est limite a un seul hote, sans auto-scaling ni self-healing
• Docker Swarm ajoute l'orchestration mais stagne en termes de développement
• Kubernetes est puissant mais complexe : ne l'adopte que si tu as le problème qu'il resout
• Coolify et Dokku offrent un excellent compromis pour les petits et moyens projets
• La regle : commence avec Compose, monte en complexité seulement quand c'est nécessaire

Precedent : 31 - CI/CD | Suivant : 33 - Glossaire

Sources

• Docker Swarm documentation
• Kubernetes documentation
• Coolify - Self-hosted deployment platform