Déploiement Blue-Green sur Docker Compose sans interruption

# Déploiement bleu-vert sans Kubernetes : Implémentation sur Docker Compose avec zéro temps d'arrêt

Mettre en œuvre un déploiement bleu-vert est possible même sans orchestrateurs comme Kubernetes — Docker Compose, nginx et une logique d'arrêt gracieux bien pensée suffisent. Cette approche est particulièrement pertinente pour les équipes travaillant sur des serveurs dédiés ou des machines virtuelles, où l'utilisation d'un cluster complet est impraticable pour des raisons économiques ou architecturales. L'article couvre l'implémentation technique du déploiement continu pour les services web et les workers en arrière-plan, en tenant compte des spécificités du traitement des messages et de la gestion de l'état.

Architecture bleu-vert sur Docker Compose

Dans la configuration de base, chaque application est dupliquée : il existe deux instances indépendantes — bleue et verte. Les deux sont lancées comme services séparés dans docker-compose.prod.yml, mais une seule reçoit le trafic à un moment donné. Le routage est géré par un reverse proxy (nginx dans l'exemple), qui bascule l'adresse upstream lors du déploiement. Principe clé : la nouvelle instance est entièrement démarrée et passe les health checks avant que l'ancienne ne soit arrêtée.

La configuration nécessite de spécifier explicitement les ports pour chaque instance :

web-blue:
  ports:
    - "127.0.0.1:8002:8000"

web-green:
  ports:
    - "127.0.0.1:8003:8000"

Cela permet à nginx d'accéder à l'instance requise via localhost et un port spécifique. Cette configuration évite les conflits et simplifie la gestion du cycle de vie.

Gestion des workers en arrière-plan

Les processus en arrière-plan (workers) qui consomment des messages d'une file d'attente (p. ex., RabbitMQ) nécessitent une approche spéciale. Arrêter simplement le conteneur entraînerait une perte de messages ou un retraitement en cas d'opérations non idempotentes. La solution consiste à implémenter un arrêt gracieux au niveau de l'application.

Cela est implémenté via une classe singleton avec un drapeau is_accepting. Avant de traiter chaque tâche, le worker vérifie ce drapeau :

• Si is_accepting == True — la tâche est exécutée.
• Si is_accepting == False — le message est renvoyé à la file avec requeue=True.

À la réception du signal SIGTERM, le drapeau est mis à False, après quoi l'application attend que toutes les tâches en cours se terminent (avec un buffer de 5–10 secondes) puis s'arrête. Cela garantit qu'aucun message n'est perdu et qu'aucune incohérence de données ne survient.

Nuances importantes :

• Pour les workers multi-processus (p. ex., ProcessPoolExecutor), l'état is_accepting doit être accessible à tous les processus enfants. Sinon, certains consommateurs continueront à traiter de nouvelles tâches.
• Les opérations non idempotentes nécessitent des protections supplémentaires : le retraitement peut corrompre l'intégrité des données.
• Utiliser un drapeau distribué (p. ex., dans Redis) complique l'architecture mais peut être justifié dans les systèmes à forte charge.

Script de déploiement : Logique étape par étape

Le script de déploiement automatise le basculement entre les instances. La logique est la même pour les services web et les workers, mais avec des points d'entrée différents.

Étapes principales :

• Détermination de l'instance active (en analysant la configuration nginx ou la liste des conteneurs en cours d'exécution).
• Démarrage de l'instance inactive (docker compose up -d).
• Vérification de la préparation de la nouvelle instance via health check (jusqu'à 30 tentatives avec des intervalles de 2 secondes).
• Mise à jour de la configuration nginx et exécution de nginx -s reload.
• Attente de la fin de toutes les requêtes HTTP actives (généralement 5 secondes).
• Arrêt de l'ancienne instance (docker compose stop).

Exemple pour un service web :

echo "server 127.0.0.1:${INACTIVE_PORT};" > "$UPSTREAM_CONF"
nginx -t && nginx -s reload
sleep 5
$COMPOSE stop web-${ACTIVE}

Cette séquence garantit que le trafic n'est jamais dirigé vers un service non préparé, et que l'ancienne instance s'arrête seulement après le basculement complet.

Compatibilité du schéma de base de données et migrations

L'un des principaux défis du déploiement bleu-vert est d'exécuter deux versions de l'application contre la même base de données simultanément. Pour éviter les erreurs, toutes les migrations doivent être compatibles vers l'arrière.

Approche recommandée — mise à jour en deux étapes :

• Premier déploiement : Supprimer l'utilisation du champ/table obsolète dans le code, mais conserver la structure en BD. Les versions nouvelle et ancienne fonctionnent correctement.
• Deuxième déploiement (après basculement complet du trafic) : Effectuer la migration pour supprimer les éléments de schéma inutilisés.

Cela augmente le nombre d'opérations mais élimine le risque de crash de l'ancienne instance dû à une incompatibilité de schéma.

Points clés

• Le déploiement bleu-vert sur Docker Compose est possible sans Kubernetes, mais nécessite une gestion manuelle des instances et du proxy.
• L'arrêt gracieux pour les workers est critique — sans cela, les messages peuvent être perdus ou dupliqués.
• Toutes les migrations BD doivent être compatibles vers l'arrière ; la suppression de champs nécessite une approche en deux étapes.
• Le health check de la nouvelle instance est obligatoire avant le basculement du trafic.
• La configuration Nginx doit être mise à jour de manière atomique et validée avec nginx -t.

— Editorial Team