La documentation Docker décrit la recréation d'un service lors d'une mise à jour Compose. Pour éviter cette interruption sur un VPS, nous proposons une bascule entre deux projets : préparez la nouvelle version avant de retirer l'ancienne.
1. Encadrer le premier déploiement
Prérequis : Docker Engine, le plugin Compose, Nginx avec HTTPS et une image testée de votre application. Elle doit écouter sur 0.0.0.0:3000 dans le conteneur et fournir /health, qui retourne un succès seulement lorsque ses dépendances sont prêtes.
Ce modèle vise un frontal HTTP sans état local : sessions et données persistantes sont externes et partagées. Excluez les tâches planifiées et travailleurs qui risqueraient de tourner en double. Les deux versions doivent accepter le même schéma de base ; sauvegardez les données avant une migration.
Créez compose.yaml dans un dossier de déploiement dédié :
services: web: image: ${APP_IMAGE:?APP_IMAGE required} ports: - "127.0.0.1:${APP_PORT:?APP_PORT required}:3000" restart: unless-stopped mem_limit: 512m logging: driver: json-file options: max-size: "10m" max-file: "3"Ajoutez les variables nécessaires à votre application. 512m est un exemple à mesurer, pas une recommandation universelle : le VPS doit pouvoir accueillir les deux versions, Nginx, le système et leurs marges.
Dans blue.env, indiquez votre vraie image avec un tag immuable ou un digest, puis APP_PORT=3001. Créez green.env avec la nouvelle image et APP_PORT=3002. Ces fichiers servent à l'interpolation Compose ; ils ne sont pas automatiquement injectés dans le conteneur.
2. Démarrer et vérifier les deux versions
Depuis ce dossier :
docker compose --env-file blue.env -p blue pulldocker compose --env-file blue.env -p blue up -dcurl -fsS http://127.0.0.1:3001/healthDans /etc/nginx/conf.d/app-upstream.conf, définissez :
upstream app_backend { server 127.0.0.1:3001;}Dans le bloc HTTPS de votre domaine, configurez :
location / { proxy_pass http://app_backend; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme;}sudo nginx -t && sudo systemctl reload nginxdocker compose --env-file green.env -p green pulldocker compose --env-file green.env -p green up -dcurl -fsS http://127.0.0.1:3002/healthdocker compose --env-file green.env -p green logs \ --tail=50 webdocker stats --no-streamTestez aussi une opération métier sur le port 3002. Un conteneur « running » ne prouve pas que l'application fonctionne. La politique de redémarrage répond à l'arrêt du processus ; elle ne détecte pas à elle seule un service bloqué.
3. Basculer, observer et garder un retour
Dans le fichier upstream, remplacez uniquement 3001 par 3002, puis :
sudo nginx -t && sudo systemctl reload nginxcurl -fsS https://example.com/healthRemplacez le domaine. Contrôlez depuis un autre réseau les réponses, la version servie, les journaux et les opérations métier. Gardez blue en marche pendant que les anciennes requêtes se terminent ; les connexions longues nécessitent une stratégie de drainage propre à l'application.
En cas d'échec, remettez 3001, testez et rechargez Nginx. Ce retour suppose que les données restent compatibles. Après drainage et validation :
docker compose --env-file blue.env -p blue stopErreurs courantes : port identique pour les deux projets, image latest non maîtrisée, RAM insuffisante ou migration SQL incompatible. Évitez down -v : supprimer des volumes ne fait pas partie de cette bascule. Un VPS unique reste un point de panne ; cette méthode traite la mise à jour applicative.
Sources : Docker, production, Docker, services Compose.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.