Quelle stratégie de déploiement fonctionne sur un hôte unique avec Docker Compose et un reverse proxy ?

Question ouverte

Les stratégies de déploiement des orchestrateurs supposent plusieurs instances, un contrôleur et une répartition du trafic pilotable. Sur un hôte unique avec Docker Compose, peu de ces éléments sont disponibles : docker compose up -d remplace généralement le conteneur en cours d’exécution, et le proxy renvoie une erreur entre l’arrêt de l’ancien et le moment où le nouveau est prêt. La spécification Compose prévoit bien, dans la section deploy, un update_config avec order: start-first (nouvelle tâche démarrée en premier, avec un bref chevauchement) ainsi qu’un rollback_config ; savoir si et comment une installation Compose donnée les met en œuvre sans orchestrateur fait partie de la question. Les reverse proxys tels que Traefik proposent une répartition pondérée (Weighted Round Robin) entre services, ce qui permettrait de reproduire un déploiement canary. Concrètement :

• Quelles adaptations les petites équipes ont-elles réellement exploitées pendant des mois : deux conteneurs nommés (bleu/vert) avec basculement de règle du proxy, un second conteneur avec contrôle de santé et comportement start-first, une répartition pondérée dans le proxy, ou simplement une brève interruption avec page de maintenance ?
• Qu’est-ce qui a échoué : des migrations de base de données incompatibles avec la coexistence des deux versions ; des volumes qu’un seul conteneur peut utiliser ; des connexions longues (WebSockets, téléversements) coupées lors du basculement ; une configuration de proxy entretenue à la fois dans des fichiers et dans des labels de conteneurs ?
• Comment le retour en arrière a-t-il été vérifié : lors d’un essai avant un incident ou seulement pendant l’incident ?
• À partir de combien de services, de déploiements par semaine ou d’utilisateurs les équipes ont-elles jugé avantageux de passer à un orchestrateur, et qu’est-ce qui les en avait empêchées auparavant ?
• Existe-t-il des mesures de la durée réelle d’interruption avec un simple up -d assorti d’un contrôle de santé, comparée à celle d’une adaptation blue-green ?

Ce qu'une réponse utile contient

La taille de l’hôte et du service, le proxy et la version de Compose, l’adaptation exacte avec un extrait de configuration, la durée d’exploitation, les défaillances rencontrées et leurs causes, la durée d’interruption mesurée ou estimée (en précisant ce qui a été mesuré), et le fait que la solution ait ou non résisté à un changement de personnel. Les propositions sans expérience d’exploitation sont bienvenues si elles sont présentées comme telles.