[{"data":1,"prerenderedAt":166},["ShallowReactive",2],{"seo-verification":3,"blog-docker-compose-mise-a-jour-best-practices-vps-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-docker-compose-mise-a-jour-best-practices-vps-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":109,"ctaBody":110,"ctaButton":111,"ctaUrl":112,"relatedPosts":113},427,"docker-compose-mise-a-jour-best-practices-vps",{"fr":10,"en":12,"ar":13,"es":14},"docker-compose-update-best-practices-vps","أفضل-ممارسات-تحديث-docker-compose-على-vps","docker-compose-actualizacion-buenas-practicas-vps","Mettre à jour une stack Docker Compose en production","Protocole complet pour mettre à jour Docker Compose en production : pinning de version, backup de volumes et rollback en deux minutes.",9,0,false,"2026-10-09T00:00:00+00:00","2026-10-09T22:36: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-mise-a-jour-best-practices-vps-poster.svg","Un `docker compose pull` suivi d'un `up -d` : ça a toujours marché, jusqu'au jour où ça ne marche plus. Les breaking changes récents de Meilisearch v1.54, Supabase PostgreSQL 15→17, Langfuse v3→v4 et NocoDB 2026.09 l'ont confirmé brutalement — des instances stables, en production depuis des mois, irrécupérables après une mise à jour non préparée. Ce guide vous donne un protocole reproductible : avant de puller, vous sauvegardez ; avant de relancer, vous vérifiez les notes de version ; et si quelque chose casse, vous revenez à l'image précédente en moins de deux minutes.",[34,38,46,49,68,72,75,103,106],{"type":35,"title":36,"body":37},"h2","Pourquoi `latest` est le vrai coupable","Quand une image Docker taguée `latest` est mise à jour dans le registry, votre `docker compose pull` la télécharge silencieusement. Aucun avertissement, aucun diff. Vous relancez la stack, et vous découvrez que le nouveau conteneur ne peut pas lire les données laissées par l'ancien.\n\nC'est exactement ce qui s'est produit avec **Meilisearch v1.54**. Le moteur de recherche a introduit dans cette version un nouveau format de stockage vectoriel (passage d'arroy à HNSW par défaut) qui rend le répertoire de données incompatible avec les versions antérieures. Résultat : au démarrage, Meilisearch refuse d'ouvrir la base et entre en crash-loop. Le seul chemin de sortie propre est de créer un dump avant la mise à jour — opération impossible une fois le conteneur bloqué.\n\nL'image `latest` ne résout pas la même chose selon l'heure du pull. Deux développeurs qui exécutent `docker compose pull` à douze heures d'intervalle peuvent tirer des versions différentes. Sur une stack de production, cette ambiguïté est inacceptable. La solution n'est pas de ne jamais mettre à jour : c'est de **contrôler explicitement quelle version tourne** et de décider consciemment quand passer à la suivante.",{"type":39,"title":40,"items":41},"ul","Ce que ce guide couvre — et ce qu'il ne couvre pas",[42,43,44,45],"**Ce que ce guide couvre** : le protocole pas-à-pas pour mettre à jour une stack Docker Compose sur un VPS — pinning de version, sauvegarde de volumes, vérification des notes de version, rollback rapide, healthchecks comme garde-fou.","**Prérequis couverts par d'autres guides** : la checklist de durcissement initiale (`docker-compose-production-checklist`), la configuration de `depends_on` et `service_healthy` (`docker-compose-depends-on-healthcheck`), et la comparaison des outils de mise à jour automatique comme Watchtower ou Diun.","**Ce que ce guide ne recommande pas** : Watchtower ou tout outil d'auto-pull en production — c'est précisément le contre-patron que les cas de breaking changes illustrent.","**Public cible** : développeurs et agences qui gèrent une ou plusieurs stacks Docker Compose en production sur VPS, avec accès root et volumes persistants.",{"type":35,"title":47,"body":48},"Étape 1 — Épingler toutes vos images","La première action, avant toute mise à jour, est de remplacer chaque `image: meili\u002Fmeilisearch:latest` ou `image: supabase\u002Fpostgres` par une version explicite.\n\nDeux formes sont acceptables :\n\n- **Tag de version** : `image: getmeili\u002Fmeilisearch:v1.53.0` — lisible, versionnable dans git, facile à patcher.\n- **Digest SHA256** : `image: getmeili\u002Fmeilisearch@sha256:abc123…` — immuable, garantit que vous tirez exactement le même artefact à chaque redéploiement, même si le tag a été réécrit (ce qui arrive sur les registries publics).\n\nPour connaître le digest d'une image déjà en cours d'exécution :\n\n```bash\ndocker inspect --format='{{index .RepoDigests 0}}' getmeili\u002Fmeilisearch:v1.53.0\n```\n\nUne fois vos images épinglées, committez le fichier `docker-compose.yml` dans git. Chaque bump de version devient un commit, ce qui vous donne un historique clair et un rollback trivial (`git revert` + `docker compose up -d`).",{"type":50,"title":51,"steps":52},"steps","Protocole de mise à jour — les 5 étapes",[53,56,59,62,65],{"title":54,"body":55},"Lire les notes de version avant de puller","Avant tout, consultez les release notes de la nouvelle version. Cherchez les mots `breaking`, `migration`, `incompatible`, `pg_upgrade`, `dump`. Ce n'est pas facultatif : Supabase a documenté explicitement que la mise à jour de PostgreSQL 15 vers 17 **exige un `pg_upgrade` manuel** — le conteneur PG 17 refuse de démarrer sur un volume PG 15, et le processus d'initialisation ne migre pas automatiquement les données.\n\nPour Langfuse v4 (sorti le 17 août 2026), les SDKs Python v2 et antérieurs **sont rejetés à l'ingestion** par le nouveau stack — une rupture qui affecte tous les services clients qui tracent via l'ancienne API.\n\nTrois minutes de lecture vous évitent plusieurs heures de récupération de données.",{"title":57,"body":58},"Sauvegarder les volumes avant le pull","Ne pullez jamais avant d'avoir un backup exploitable. Pour les volumes nommés, deux approches :\n\n**Dump applicatif (recommandé pour les bases de données)** — le service doit être `healthy` avant de dumper :\n\n```bash\ndocker compose exec db pg_dump -U postgres -Fc mydb > backup_$(date +%Y%m%d_%H%M%S).dump\n```\n\n**Snapshot de volume brut** — utile pour les stockages binaires (Meilisearch, Redis, MinIO) :\n\n```bash\ndocker run --rm \\\n  --volumes-from $(docker compose ps -q meilisearch) \\\n  -v $(pwd)\u002Fbackups:\u002Fbackup \\\n  alpine tar czf \u002Fbackup\u002Fmeili_$(date +%Y%m%d_%H%M%S).tar.gz \u002Fmeili_data\n```\n\nVérifiez que le backup est lisible avant de continuer. Un fichier de dump corrompu découvert pendant la récupération est le scénario le plus coûteux qui soit.",{"title":60,"body":61},"Puller la nouvelle image et tester hors ligne","Mettez à jour le tag dans votre `docker-compose.yml`, puis pullez l'image sans redémarrer le service :\n\n```bash\ndocker compose pull meilisearch\n```\n\nSi votre environnement le permet, testez la nouvelle image sur un clone du volume dans un environnement ddev ou sur une VM de staging avant de toucher à la production. Vérifiez dans les logs de démarrage qu'aucune erreur de migration ne s'affiche :\n\n```bash\ndocker compose up -d meilisearch\ndocker compose logs -f meilisearch\n```\n\nAttendez que le healthcheck passe à `healthy` avant de valider. Un service qui démarre mais qui n'est pas encore `healthy` n'est pas un service prêt.",{"title":63,"body":64},"Vérifier les healthchecks","Un healthcheck bien configuré est votre première ligne de détection. Il doit être présent sur chaque service critique de la stack, au format Compose v2 :\n\n```bash\nhealthcheck:\n  test: [\"CMD-SHELL\", \"curl -sf http:\u002F\u002Flocalhost:7700\u002Fhealth || exit 1\"]\n  interval: 10s\n  timeout: 5s\n  retries: 5\n  start_period: 30s\n```\n\nLe champ `start_period` est critique pour les services à démarrage lent (bases de données, moteurs de recherche) : il évite que Docker déclare le conteneur `unhealthy` pendant la phase d'initialisation et déclenche un redémarrage prématuré.\n\nConsultez `docker-compose-depends-on-healthcheck` pour la configuration complète de `service_healthy` sur PostgreSQL — le même principe s'applique à tout service qui a besoin d'un temps d'amorçage.",{"title":66,"body":67},"Rollback en cas de problème","Si la nouvelle version ne démarre pas ou produit des erreurs, le rollback doit prendre moins de deux minutes. La procédure :\n\n1. Revenez au tag précédent dans `docker-compose.yml` (ou `git revert` si vous avez commité le bump).\n2. Relancez uniquement le service concerné, sans recréer les volumes :\n\n```bash\ndocker compose up -d --no-deps --force-recreate meilisearch\n```\n\n3. Vérifiez immédiatement les logs :\n\n```bash\ndocker compose logs -f meilisearch\n```\n\nLe flag `--no-deps` est essentiel : il redémarre le service cible sans toucher aux autres conteneurs (base de données, cache, proxy). Sans lui, `docker compose up -d` peut recréer la totalité de la stack.\n\n⚠️ Si la nouvelle version a migré le format des données sur disque (cas Meilisearch v1.54, Supabase PG17), le rollback d'image ne suffit pas — c'est pourquoi le backup du volume est une précondition, pas une option.",{"type":69,"title":70,"body":71},"tip","Gardez la version précédente disponible localement","Avant de puller la nouvelle image, taguez l'image actuellement en production sous un nom de rétention :\n\n```bash\ndocker tag getmeili\u002Fmeilisearch:v1.53.0 getmeili\u002Fmeilisearch:rollback\n```\n\nCela vous permet de revenir à l'état exact en cas d'urgence, même si vous n'avez plus accès au registry ou si la connexion est lente. Sur un VPS avec une bande passante contrainte, ce tag local vous économise plusieurs minutes de téléchargement au pire moment.",{"type":35,"title":73,"body":74},"Les breaking changes récents qui ont cassé des instances","Ces quatre exemples illustrent pourquoi le protocole ci-dessus n'est pas théorique.\n\n**Meilisearch v1.53 → v1.54** (2026) : introduction du store vectoriel HNSW comme format par défaut. Meilisearch refuse d'ouvrir un index créé avec l'ancien format arroy. Le démarrage entre en crash-loop avec `Your database version is incompatible with your current engine version`. La seule sortie propre est de créer un dump (`meilisearch --db-path \u002Fdata --import-dump \u002Fbackup.dump` sur la nouvelle version) — opération possible uniquement si vous avez exporté avant de mettre à jour.\n\n**Supabase Docker PostgreSQL 15 → 17** (migration activée le 17 juin 2026) : le conteneur `supabase\u002Fpostgres:17` ne peut pas lire un volume initialisé par PG 15. Supabase documente explicitement que le saut nécessite un `pg_upgrade` via un script dédié — le processus d'initialisation du conteneur ne le fait pas automatiquement. Sans migration préalable, la base ne démarre pas.\n\n**Langfuse v3 → v4** (GA le 17 août 2026) : la v4 abandonne les endpoints d'ingestion batch legacy au profit d'OpenTelemetry. Les SDKs Python v2 et antérieurs et les SDKs JS\u002FTS v3 et antérieurs sont **rejetés à l'ingestion** dès le démarrage de la stack v4. Si vos services clients n'ont pas migré avant la mise à jour du serveur, ils perdent silencieusement toutes leurs traces.\n\n**NocoDB 2026.09.x** : la série 2026.09 reconstruit les images Docker pour éliminer des dépendances vulnérables. Les installations utilisant des bind-mounts (`.\u002Fpostgres`, `.\u002Fnocodb`) au lieu de volumes nommés peuvent démarrer sur une base vide après le pull — NocoDB ne retrouve pas ses données si le chemin de montage a changé entre versions. Migration vers les volumes nommés requise avant la mise à jour.",{"type":76,"title":77,"headers":78,"rows":83},"comparison","Stratégies de mise à jour : comparatif",[79,80,81,82],"Stratégie","Sécurité des données","Temps de préparation","Rollback",[84,89,94,99],[85,86,87,88],"`docker compose pull` + `up -d` direct","Aucune garantie — breaking changes non détectés","\u003C 1 minute","Difficile si migration de données",[90,91,92,93],"Bump de tag versionné + backup de volume","Élevée — données sauvegardées avant tout changement","10 à 20 minutes","Trivial : revert du tag + `up -d --no-deps`",[95,96,97,98],"Test sur staging avant prod","Maximale — breaking changes détectés hors prod","Variable selon l'env","Non nécessaire si le test a passé",[100,101,102,102],"Image pinnée par digest SHA256","Élevée — immunisé contre le tag-overwrite","Identique au tag versionné",{"type":35,"title":104,"body":105},"Intégrer ce protocole dans votre workflow","Un protocole qui reste dans un guide ne sert à rien. Pour qu'il soit appliqué systématiquement, externalisez la version dans un fichier `.env` versionné dans git :\n\n```bash\n# .env\nMEILISEARCH_VERSION=v1.53.0\nPOSTGRES_VERSION=15.6\n```\n\n```bash\n# docker-compose.yml\nservices:\n  meilisearch:\n    image: getmeili\u002Fmeilisearch:${MEILISEARCH_VERSION}\n```\n\nMettre à jour une version devient alors un commit unique sur `.env` — lisible dans `git log`, réversible par `git revert`, et déployable par CI\u002FCD sans modifier le fichier Compose principal.\n\nPour les agences qui gèrent plusieurs stacks clients, créez un fichier `CHANGELOG_INFRA.md` par client : chaque mise à jour y est tracée avec la version précédente, la date, le backup effectué et l'issue de la mise à jour. C'est aussi ce qui vous protège contractuellement en cas d'incident ultérieur.",{"type":69,"title":107,"body":108},"Automatiser sans perdre le contrôle","Si vous voulez être alerté des nouvelles versions sans auto-pull, **Diun** (Docker Image Update Notifier) surveille votre registry et vous envoie une notification (Slack, email, webhook) quand une nouvelle image est disponible. Vous restez décisionnaire sur le moment de la mise à jour.\n\nC'est la différence fondamentale avec Watchtower : Diun notifie, Watchtower agit. Sur une stack de production avec des volumes persistants, la notification est le bon niveau d'automatisation — l'action reste manuelle et précédée du protocole ci-dessus.","Un VPS avec accès root pour appliquer ce protocole","Dumps complets, snapshots avant mise à jour, rollback sur une image précédente : ce protocole exige un accès root et un stockage local contrôlable. Un hébergement mutualisé ne donne pas ce niveau de contrôle sur les volumes Docker.","Voir les VPS Cloud","\u002Fvps-cloud",[114,130,146],{"id":115,"slug":116,"slugs":117,"title":121,"excerpt":122,"readTime":123,"views":18,"isPinned":19,"publishedAt":124,"updatedAt":125,"category":126,"categories":127,"featuredImage":29,"bgImage":30,"posterImage":129,"relatedSolution":29},229,"docker-compose-production-checklist",{"fr":116,"en":118,"ar":119,"es":120},"docker-compose-in-production-10-point-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","checklist-docker-compose-en-produccion","Docker Compose en production : checklist des 10 points","Checklist Docker Compose en production : 10 réglages essentiels, health checks, secrets sans downtime, rollback, dépannage des erreurs courantes, CVE-2026-17106.",12,"2026-08-06T00:00:00+00:00","2026-09-29T14:40:45+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[128],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":131,"slug":132,"slugs":133,"title":137,"excerpt":138,"readTime":139,"views":18,"isPinned":19,"publishedAt":140,"updatedAt":141,"category":142,"categories":143,"featuredImage":29,"bgImage":30,"posterImage":145,"relatedSolution":29},282,"docker-compose-depends-on-healthcheck",{"fr":132,"en":134,"ar":135,"es":136},"depends-on-is-not-enough-postgresql-healthcheck-in-compose","depends-on-لا-يكفي-healthcheck-لـ-postgresql-في-compose","docker-compose-healthcheck-postgresql","depends_on ne suffit pas : healthcheck PostgreSQL dans Compose","Pourquoi `depends_on` seul ne garantit pas que PostgreSQL est prêt, et comment configurer un healthcheck fiable avec `service_healthy` pour éviter les races conditions.",8,"2026-08-19T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[144],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-depends-on-healthcheck-poster.svg",{"id":147,"slug":148,"slugs":149,"title":153,"excerpt":154,"readTime":155,"views":18,"isPinned":19,"publishedAt":156,"updatedAt":157,"category":158,"categories":163,"featuredImage":29,"bgImage":30,"posterImage":165,"relatedSolution":29},382,"securite-vps-mises-a-jour-automatiques-debian-ubuntu",{"fr":148,"en":150,"ar":151,"es":152},"vps-automatic-security-updates-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","actualizaciones-seguridad-vps-debian-ubuntu","Mises à jour de sécurité automatiques sur VPS Debian\u002FUbuntu","Configurez unattended-upgrades sur vos VPS Debian\u002FUbuntu pour automatiser les patches de sécurité et réduire la surface d'attaque de votre parc client.",10,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":139,"name":159,"slug":160,"color":161,"icon":162},"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[164],{"id":139,"name":159,"slug":160,"color":161,"icon":162},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",1791585654934]