[{"data":1,"prerenderedAt":230},["ShallowReactive",2],{"seo-verification":3,"blog-docker-compose-production-checklist-ma-fr":6,"promo-bar-likely":229},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-docker-compose-production-checklist-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":171,"ctaBody":172,"ctaButton":173,"ctaUrl":174,"relatedPosts":175},229,"docker-compose-production-checklist",{"fr":10,"en":12,"ar":13,"es":14},"docker-compose-in-production-10-point-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","checklist-docker-compose-en-produccion","Docker Compose en production : checklist des 10 points","Docker Compose en production : 10 réglages, health checks, secrets, rollback, dépannage et passage de docker-compose v1 à docker compose sur Ubuntu 26.04.",12,1,false,"2026-08-06T00:00:00+00:00","2026-10-23T13:27:09+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},3,"Déploiement","deploiement","bg-success\u002F10 text-success",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg","Un fichier docker-compose.yml qui tourne sur votre poste ne survit pas tel quel à la production. Redémarrage après reboot, limites de ressources, secrets, rotation des logs : autant de réglages absents par défaut qui provoquent des pannes silencieuses une fois le service exposé. Cette checklist réunit les 10 paramètres à contrôler avant de déployer une stack Compose sur un VPS, puis les health checks, les secrets, le rollback et le dépannage. Elle couvre aussi le passage de `docker-compose` à `docker compose`, que la montée vers Ubuntu 26.04 oblige à régler.",[34,38,52,55,89,137,140,150,153,156,159,162,165,168],{"type":35,"title":36,"body":37},"h2","Pourquoi une checklist avant la prod","Docker Compose a été pensé pour le développement : ses valeurs par défaut privilégient la simplicité, pas la robustesse. Un conteneur ne redémarre pas après un reboot de l'hôte, ses logs grossissent sans limite, il peut consommer toute la RAM de la machine et il écoute sur toutes les interfaces réseau. En production, ces réglages absents se transforment en incidents : disque plein à 3 h du matin, base de données perdue après un `docker compose down`, service injoignable après une coupure de courant. Durcir une stack Compose ne demande pas de réécriture, seulement une dizaine d'ajouts ciblés. Passez chaque point de cette liste avant de mettre en ligne, et votre service tiendra la charge et les redémarrages sans surveillance constante.",{"type":39,"title":40,"items":41},"ul","Les 10 points en un coup d'œil",[42,43,44,45,46,47,48,49,50,51],"**restart: unless-stopped** — le conteneur redémarre après un reboot de l'hôte ou un crash","**healthcheck** — Docker détecte un conteneur bloqué et permet les redémarrages progressifs","**limites CPU\u002Fmémoire** — un service emballé ne peut plus asphyxier ses voisins","**secrets via .env ou Docker secrets** — jamais de mot de passe en clair dans le fichier Compose","**volumes nommés** — les données survivent à un `docker compose down`","**rotation des logs** — `max-size` et `max-file` empêchent le disque de se remplir","**isolation réseau** — séparez `frontend` et `backend`, n'exposez pas tout sur le bridge par défaut","**binding de ports** — `127.0.0.1:PORT` derrière un reverse proxy, pas `0.0.0.0`","**tags d'image épinglés** — une version ou un digest, jamais `latest`","**depends_on avec condition** — `service_healthy` évite les courses au démarrage",{"type":35,"title":53,"body":54},"Prérequis","Il vous faut un VPS avec Docker Engine et le plugin Compose v2. La commande est `docker compose`, sans tiret : vérifiez-la avec `docker compose version`, car la syntaxe `deploy.resources` hors Swarm exige Compose v2 (l'ancien `docker-compose` est traité plus bas). Contrôlez aussi le moteur avec `docker version`. Docker Engine 29.7.2 corrige \u003Ca href=\"https:\u002F\u002Fwww.imperva.com\u002Fblog\u002Fcopyescape-docker-vulnerability-cve-2026-17106\u002F\">CVE-2026-17106\u003C\u002Fa> (CopyEscape), une race condition de `docker cp` divulguée le 10 août 2026 : un conteneur non fiable peut y écraser un fichier de l'hôte, y compris le binaire `runc`. Côté poste de travail, le correctif est arrivé dans Docker Desktop 4.86.0. En attendant la mise à jour, n'exécutez pas `docker cp` depuis un conteneur dont vous ne maîtrisez pas le contenu. Rangez le projet dans un dossier dédié (`\u002Fopt\u002Fmonapp`), avec un `.env` en `chmod 600`. Prévoyez un reverse proxy en amont — Traefik, Caddy ou Nginx — car le binding de ports suppose que le trafic public ne touche jamais vos conteneurs, et versionnez le fichier Compose.",{"type":56,"title":57,"steps":58},"steps","Les 10 étapes détaillées",[59,62,65,68,71,74,77,80,83,86],{"title":60,"body":61},"1. Politique de redémarrage","Ajoutez `restart: unless-stopped` à chaque service. Le conteneur redémarre après un crash ou un reboot de l'hôte, mais reste arrêté si vous l'avez stoppé volontairement. Évitez `restart: always` qui relancerait même un conteneur que vous vouliez laisser à l'arrêt, et préférez `unless-stopped` pour des services applicatifs et `on-failure` pour des tâches ponctuelles qui ne doivent pas boucler indéfiniment.",{"title":63,"body":64},"2. Healthcheck","Déclarez un bloc `healthcheck:` avec un `test` (par exemple `curl -f http:\u002F\u002Flocalhost:8080\u002Fhealth || exit 1`), un `interval` (fréquence de vérification, ex. `30s`), un `timeout` (délai avant échec, ex. `10s`) et des `retries` (nombre d'échecs consécutifs avant passage à `unhealthy`, ex. `3`). Ajoutez aussi `start_period: 40s` pour les services qui mettent du temps à démarrer, afin d'éviter de les marquer `unhealthy` pendant leur initialisation. Docker marque alors le conteneur `healthy` ou `unhealthy`, ce qui permet aux autres services de réagir à un blocage via `depends_on: condition: service_healthy`.",{"title":66,"body":67},"3. Limites de ressources","Sous `deploy.resources.limits`, fixez `cpus` et `memory` (par exemple `memory: 512M`). Sans limite, un service qui fuit peut consommer toute la RAM et faire tuer les autres par l'OOM killer. Ajoutez aussi des `reservations` pour garantir un minimum au démarrage. En Compose v2 hors Swarm, les `limits` sont appliquées en tant que contraintes cgroup ; les `reservations` sont déclaratives et ne bloquent pas le démarrage, mais servent de référence pour la planification.",{"title":69,"body":70},"4. Secrets hors du fichier","Ne mettez jamais un mot de passe en clair dans le YAML. Référencez-les via `env_file: .env` ou `${VARIABLE}`, ou utilisez le mécanisme `secrets:` de Docker qui monte le secret en fichier dans `\u002Frun\u002Fsecrets\u002F` à l'intérieur du conteneur, hors de portée de `docker inspect`. Ajoutez `.env` à votre `.gitignore` et vérifiez avec `git status` que ce fichier n'est jamais suivi.",{"title":72,"body":73},"5. Volumes nommés","Déclarez vos données dans des volumes nommés avec un driver explicite plutôt qu'en bind-mount anonyme. Un volume nommé survit à `docker compose down` ; seul `down -v` l'efface. Documentez chaque volume pour savoir ce que vous sauvegardez, et associez-lui une stratégie de backup testée : une sauvegarde sans test de restauration est une donnée non sauvegardée.",{"title":75,"body":76},"6. Rotation des logs","Ajoutez un bloc `logging:` avec `driver: json-file` et des options `max-size: \"10m\"` et `max-file: \"3\"`. Sans cela, les logs d'un conteneur bavard remplissent le disque jusqu'à la panne. Appliquez-le à chaque service. Pour des stacks à fort volume, envisagez le driver `local` (compression automatique) ou un driver externe comme `loki` si vous avez une infrastructure de logs centralisée.",{"title":78,"body":79},"7. Isolation réseau","Créez des réseaux nommés — un `frontend` pour ce qui est exposé, un `backend` pour la base de données — et n'attachez chaque service qu'aux réseaux dont il a besoin. Votre base ne doit être joignable que par l'application, jamais depuis le bridge par défaut partagé. Ajoutez `internal: true` sur le réseau `backend` pour empêcher tout accès depuis l'hôte ou Internet, même en cas d'erreur de configuration des ports.",{"title":81,"body":82},"8. Binding de ports","Derrière un reverse proxy, publiez sur `127.0.0.1:8080:8080` et non `8080:8080` (qui équivaut à `0.0.0.0`). Sinon le port reste accessible depuis Internet malgré le proxy, contournant vos règles TLS et d'authentification. Attention : Docker modifie directement les règles iptables et peut contourner UFW — le binding sur `127.0.0.1` est la seule garantie fiable côté Compose.",{"title":84,"body":85},"9. Tags d'image épinglés","Remplacez `image: postgres:latest` par une version précise (`postgres:16.3`) ou, mieux, par un digest (`postgres@sha256:...`). `latest` change sans prévenir et rend vos déploiements non reproductibles. Combinez avec `pull_policy: missing` pour un comportement prévisible : Compose ne tire une nouvelle image que si elle est absente en local, évitant les mises à jour imprévues lors d'un `docker compose up`.",{"title":87,"body":88},"10. Ordre de démarrage","Utilisez `depends_on` avec `condition: service_healthy` pour qu'un service n'attende pas seulement le lancement mais la disponibilité réelle de sa dépendance. Cela suppose un healthcheck sur le service dépendant (étape 2) et supprime les courses au démarrage. Pour les services qui ne supportent pas de healthcheck natif, vous pouvez utiliser `condition: service_started` combiné à un script d'attente (`wait-for-it.sh` ou `dockerize`).",{"type":90,"title":91,"headers":92,"rows":96},"comparison","Défauts de dev contre réglages de prod",[93,94,95],"Paramètre","Défaut en dev","Recommandé en prod",[97,101,105,109,113,117,121,125,129,133],[98,99,100],"restart","no","unless-stopped",[102,103,104],"healthcheck","absent","défini avec interval et retries",[106,107,108],"mémoire","sans contrainte de nombre","limit fixée (ex. 512M)",[110,111,112],"secrets","en clair possible",".env ou Docker secrets",[114,115,116],"volumes","anonymes","nommés avec driver",[118,119,120],"logs","sans limite","max-size + max-file",[122,123,124],"réseau","bridge par défaut","frontend \u002F backend séparés",[126,127,128],"ports","0.0.0.0","127.0.0.1 derrière proxy",[130,131,132],"image","latest","version ou digest épinglé",[134,135,136],"depends_on","démarrage seul","condition: service_healthy",{"type":35,"title":138,"body":139},"docker-compose ou docker compose : la rupture d'Ubuntu 26.04","Deux outils portent presque le même nom. `docker-compose`, avec tiret, est Compose v1, écrit en Python : son dépôt le déclare en fin de vie depuis la disponibilité générale de Compose v2, annoncée par Docker le 26 avril 2022. `docker compose`, avec une espace, est Compose v2, écrit en Go et branché sur la CLI Docker comme plugin. Ubuntu 26.04 achève la transition : le paquet `docker-compose` n'est plus dans l'archive depuis Ubuntu 25.10, et le paquet `docker-compose-v2` n'installe que le plugin, dans `\u002Fusr\u002Flibexec\u002Fdocker\u002Fcli-plugins\u002F`. Après la montée de version, tout script qui appelle encore l'ancien nom s'arrête sur `docker-compose: command not found`. Côté CI, GitHub a sorti Compose v1 de ses runners hébergés le 9 juillet 2024, et fait basculer `ubuntu-latest` vers Ubuntu 26.04 entre le 19 octobre et le 19 novembre 2026 : un workflow qui installait `docker-compose` à la main est à revérifier. Deux écarts de comportement sont documentés. Les noms de conteneurs prennent un tiret au lieu d'un tiret bas (`monapp-web-1` contre `monapp_web_1`), sauf avec `--compatibility`. Et la clé `version:` est ignorée, avec l'avertissement « the attribute `version` is obsolete, it will be ignored ».",{"type":39,"title":141,"items":142},"Migrer vos scripts et poser un shim",[143,144,145,146,147,148,149],"**Inventaire** — `grep -rnE 'docker-compose( |$)' \u002Fopt \u002Fetc\u002Fcron* \u002Fetc\u002Fsystemd ~\u002F.bashrc` liste les appels à corriger.","**Scripts et Makefile** — remplacez le tiret par une espace (`docker compose up -d`) ; les sous-commandes courantes restent les mêmes.","**cron et systemd** — appelez `\u002Fusr\u002Fbin\u002Fdocker compose` en chemin absolu, car cron tourne avec un `PATH` réduit.","**GitHub Actions** — testez vos workflows avec `runs-on: ubuntu-26.04` avant la bascule, ou épinglez `ubuntu-24.04` le temps de corriger, comme GitHub le recommande.","**Shim temporaire** — un fichier exécutable `\u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose` de deux lignes, `#!\u002Fbin\u002Fsh` puis `exec docker compose \"$@\"`, rattrape les appels oubliés. Docker maintient aussi `compose-switch`, qui traduit la syntaxe v1 vers v2.","**Noms de conteneurs** — remplacez les `docker exec monapp_web_1` codés en dur par `docker compose exec web`, qui ne dépend pas du séparateur.","**Vérification** — `docker compose version` répond, `docker compose config` passe sans avertissement, `command -v docker-compose` ne pointe que vers le shim.",{"type":35,"title":151,"body":152},"Health checks avancés : surveiller l'état réel du service","Un health check utile mesure l'état fonctionnel du service, pas seulement sa disponibilité réseau. Pour une API HTTP, testez un endpoint léger (`\u002Fhealth` ou `\u002Fready`) qui ne retourne 200 que si la connexion à la base est établie. Pour PostgreSQL, utilisez `pg_isready -U postgres` ; pour Redis, `redis-cli ping` suffit. La colonne `STATUS` de `docker compose ps` affiche `healthy`, `unhealthy` ou `starting`. Un conteneur bloqué en `starting` au-delà de `start_period` signale un problème d'initialisation : `docker compose logs service` en donne la cause. Le paramètre `start_period` est distinct de `interval` : il ouvre une fenêtre de grâce pendant laquelle les échecs ne comptent pas dans les `retries`, indispensable aux services qui migrent leur schéma au démarrage.",{"type":35,"title":154,"body":155},"Secrets Docker sans Swarm : monter des fichiers dans \u002Frun\u002Fsecrets\u002F","Hors Swarm, Compose accepte les secrets de type fichier. Déclarez le secret dans la section `secrets:` au niveau racine, en pointant vers un fichier local (`file: .\u002Fsecrets\u002Fdb_password.txt`), puis référencez-le dans le service avec `secrets: [db_password]`. Docker monte ce fichier en lecture seule dans `\u002Frun\u002Fsecrets\u002Fdb_password` : l'application le lit comme un fichier ordinaire, et sa valeur n'apparaît ni dans les variables d'environnement affichées par `docker inspect`, ni dans les logs. Pour une rotation, versionnez le secret : créez `db_password_v2` à côté de `db_password_v1`, faites lire `v2` au service, redéployez-le seul avec `docker compose up -d --no-deps service`, puis supprimez `v1` une fois le déploiement validé. L'interruption se limite à la recréation de ce conteneur, et l'ancien secret reste disponible pour revenir en arrière.",{"type":35,"title":157,"body":158},"Rollback : revenir en arrière après un déploiement raté","Le rollback d'une stack Compose se prépare avant le déploiement, pas après l'incident. Gardez l'image précédente taguée et disponible localement : ajoutez un tag explicite `monapp:stable` avant chaque mise à jour. Pour revenir en arrière, remettez l'ancien tag dans le fichier Compose (ou dans le `.env` si la version est une variable), puis relancez `docker compose up -d`. Les volumes ne sont pas touchés par un changement d'image, ce qui rend le retour applicatif rapide ; une migration de schéma, en revanche, doit avoir sa migration inverse prête avant le déploiement. Pour les mises en ligne critiques, séparez `docker-compose.yml` (version stable) et `docker-compose.override.yml` (version candidate) : `docker compose -f docker-compose.yml up -d` ignore l'override et revient à l'état stable.",{"type":160,"body":161},"tip","Testez toujours votre stack durcie en local avant de la pousser en production : lancez `docker compose config` pour valider la syntaxe, puis `docker compose up` et simulez un reboot avec `docker compose restart`. Vérifiez que les conteneurs reviennent `healthy` et que les données persistent après un `down` suivi d'un `up`.",{"type":35,"title":163,"body":164},"Dépannage : 6 erreurs courantes et leurs solutions","**`docker: unknown command: docker compose`** : le plugin Compose n'est pas installé. Sur Ubuntu, installez `docker-compose-v2` depuis l'archive, ou `docker-compose-plugin` si Docker vient du dépôt officiel de Docker, puis vérifiez avec `docker compose version`. **`network not found`** : après un `docker compose down`, les réseaux nommés sont supprimés ; un conteneur externe qui tente de les rejoindre échoue. Déclarez les réseaux partagés en `external: true` ou synchronisez le redémarrage des stacks dépendantes. **`port is already in use`** : un autre processus (nginx de l'hôte, stack orpheline) occupe le port. Identifiez-le avec `ss -tlnp | grep :PORT` puis arrêtez-le. **OOM (Out Of Memory)** : le kernel tue un conteneur sans prévenir — cherchez `OOMKilled: true` dans `docker inspect container_id`, puis relevez `deploy.resources.limits.memory` ou traquez la fuite avec `docker stats`. **`permission denied on volume`** : le processus du conteneur tourne avec un UID qui n'a pas accès au bind-mount. Vérifiez-le avec `docker compose exec service id`, puis ajustez le dossier hôte (`chown -R UID:GID \u002Fchemin`) ou ajoutez `user: \"UID:GID\"` au service. **Conteneur qui redémarre en boucle** : `docker compose logs --tail=50 service` révèle l'erreur de démarrage — le plus souvent une variable d'environnement manquante, un fichier de configuration introuvable ou une dépendance non prête (résolu par `depends_on` avec `service_healthy`).",{"type":35,"title":166,"body":167},"Sauvegarder les volumes sans corruption","Copier les fichiers d'un volume PostgreSQL ou MySQL **à chaud** avec `rsync` ou `tar` produit presque à coup sûr une sauvegarde corrompue : le moteur écrit pendant la copie, et les pages de données sont capturées à des points de contrôle différents. La règle est de **toujours faire un dump SQL avant le snapshot du volume** : `pg_dump` ou `mysqldump` produisent un état cohérent que vous pouvez archiver ou transférer. Pour automatiser cette approche sur un VPS Docker, des outils comme \u003Ca href=\"https:\u002F\u002Fpistack.xyz\u002Fposts\u002F2026-05-11-self-hosted-docker-volume-backup-offen-nautical-loomchild-guide\u002F\">Restic et Offen Docker Backup\u003C\u002Fa> orchestrent le gel de la base, le dump SQL, le snapshot chiffré et l'envoi vers un stockage distant. Associez chaque volume nommé de l'étape 5 à une restauration testée.",{"type":35,"title":169,"body":170},"Conclusion","Ces dix réglages transforment un fichier Compose de développement en une stack capable de survivre aux reboots, aux pics de charge et aux nuits sans surveillance. Health checks, secrets montés en fichier, rollback préparé et passage complet à `docker compose` complètent ce socle. Rien de tout cela ne demande d'outil supplémentaire : tout tient dans le YAML et les scripts que vous avez déjà. Déroulez la checklist avant chaque mise en ligne, par exemple via une revue de `docker compose config` intégrée au déploiement. Vous pourrez ensuite ajouter un reverse proxy comme Traefik ou Caddy, ou une couche d'orchestration comme Coolify.","Déployez votre stack Compose en production","Un VPS ServOrbit vous donne la racine, la RAM et le contrôle réseau nécessaires pour faire tourner une stack Docker Compose durcie. Choisissez votre configuration et déployez en quelques minutes.","Déployer sur VPS ServOrbit","\u002Fvps-cloud",[176,192,211],{"id":177,"slug":178,"slugs":179,"title":183,"excerpt":184,"readTime":185,"views":23,"isPinned":19,"noindex":19,"publishedAt":186,"updatedAt":187,"category":188,"categories":189,"featuredImage":29,"bgImage":30,"posterImage":191,"relatedSolution":29},38,"deployer-avec-traefik",{"fr":178,"en":180,"ar":181,"es":182},"deploy-your-applications-with-traefik-on-a-vps","انشر-تطبيقاتك-باستخدام-traefik-على-خادم-vps","desplegar-con-traefik","Déployer vos applications avec Traefik sur un VPS","Déployez Traefik en reverse proxy sur votre VPS : routage automatique des conteneurs Docker, certificats SSL Let's Encrypt et load balancing.",11,"2026-05-13T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[190],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdeployer-avec-traefik-poster.svg",{"id":193,"slug":194,"slugs":195,"title":199,"excerpt":200,"readTime":201,"views":202,"isPinned":19,"noindex":19,"publishedAt":203,"updatedAt":204,"category":205,"categories":206,"featuredImage":29,"bgImage":30,"posterImage":208,"relatedSolution":209},39,"deployer-avec-caddy",{"fr":194,"en":196,"ar":197,"es":198},"deploy-your-applications-with-caddy-on-a-vps","انشر-تطبيقاتك-باستخدام-caddy-على-خادم-vps","desplegar-con-caddy","Caddy en reverse proxy sur VPS : guide complet","Installez et configurez Caddy comme reverse proxy sur votre VPS : HTTPS automatique Let's Encrypt, multi-apps, sécurité et dépannage des erreurs courantes.",8,4,"2026-05-12T00:00:00+00:00","2026-09-25T23:43:04+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[207],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdeployer-avec-caddy-poster.svg",{"categorySlug":25,"appSlug":210},"caddy",{"id":212,"slug":213,"slugs":214,"title":218,"excerpt":219,"readTime":17,"views":220,"isPinned":19,"noindex":19,"publishedAt":221,"updatedAt":222,"category":223,"categories":224,"featuredImage":29,"bgImage":30,"posterImage":226,"relatedSolution":227},41,"deployer-avec-coolify",{"fr":213,"en":215,"ar":216,"es":217},"deploy-your-applications-with-coolify-on-a-vps","نشر-تطبيقاتك-باستخدام-coolify-على-vps","desplegar-aplicaciones-con-coolify-en-un-vps","Déployer vos applications avec Coolify sur un VPS","Déployer Coolify sur un VPS : installation, configuration HTTPS, connexion Git, première application, bases de données, sauvegardes et dépannage.",2,"2026-05-10T00:00:00+00:00","2026-10-31T01:54:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[225],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdeployer-avec-coolify-poster.svg",{"categorySlug":25,"appSlug":228},"coolify",true,1794270703311]