[{"data":1,"prerenderedAt":169},["ShallowReactive",2],{"seo-verification":3,"blog-docker-compose-mise-a-jour-best-practices-vps-ma-fr":6,"promo-bar-likely":168},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-docker-compose-mise-a-jour-best-practices-vps-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":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.",10,6,false,"2026-10-09T00:00:00+00:00","2026-11-08T01:13:13+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 ruptures de compatibilité de Meilisearch, de Supabase (PostgreSQL 15→17) et de Langfuse (v3→v4) l'ont rappelé : une instance stable, en production depuis des mois, peut refuser de démarrer ou rejeter ses données entrantes 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 le risque avec **Meilisearch**. La base de données porte le numéro de version du moteur qui l'a écrite : lors d'une montée de version, le nouveau moteur refuse de l'ouvrir tant qu'on ne lui demande pas explicitement de la migrer avec `--upgrade-db` (ou la variable `MEILI_UPGRADE_DB`). Avec une politique de redémarrage, le conteneur entre alors en crash-loop. Et une fois la base migrée, l'ancienne image ne peut plus la rouvrir : Meilisearch ne supporte pas le retour arrière. Le seul filet propre est un dump ou un snapshot du volume créé avant la mise à jour — opération impossible une fois la base migrée ou 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: getmeili\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 (v4.0.0 publiée le 29 juillet 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 -T db pg_dump -U postgres -Fc mydb > backup_$(date +%Y%m%d_%H%M%S).dump\n```\n\nL'option `-T` désactive le pseudo-terminal : sans elle, le flux binaire du dump peut être altéré.\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 après `--upgrade-db`, 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** (lors d'une montée de version) : un moteur plus récent refuse d'ouvrir une base écrite par une version antérieure, avec `Your database version (…) is incompatible with your current engine version`, tant que `--upgrade-db` n'est pas passé. Cette migration peut changer le format sur disque : en v1.37.0 (mars 2026), les index vectoriels encore au format arroy ont été convertis vers le nouveau store HNSW (hannoy). Et le retour arrière n'est pas supporté (`Downgrade is not supported`). La seule sortie propre après un échec est d'avoir exporté un dump avant la mise à jour, puis de l'importer (`meilisearch --db-path \u002Fmeili_data --import-dump \u002Fbackup.dump`) — opération possible uniquement si vous avez exporté avant de mettre à jour.\n\n**Supabase Docker PostgreSQL 15 → 17** (PG 17 par défaut à partir du 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** (v4.0.0 publiée le 29 juillet 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 que la stack v4 tourne dans son mode d'écriture par défaut (`events_only`) ; les modes `legacy` et `dual` servent à étaler la migration. Si vos services clients n'ont pas migré avant la mise à jour du serveur, ils perdent silencieusement toutes leurs traces.\n\n**NocoDB (série 2026.09)** : pas de base cassée, mais un changement incompatible annoncé à l'avance. Les notes de 2026.09.0 rappellent que les dates renvoyées par l'API REST, les webhooks et les exports passeront de la seconde à la milliseconde sur PostgreSQL et SQLite dans une version à venir. Un client qui lit les dates avec un format strict cassera sans que le serveur ne signale rien — c'est ce que la lecture des notes de version permet d'anticiper. Autre piège, indépendant de la version : une installation en bind-mounts (`.\u002Fpostgres`, `.\u002Fnocodb`) dont le chemin de montage change entre deux déploiements démarre sur une base vide. Les volumes nommés évitent cette dérive.",{"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,131,148],{"id":115,"slug":116,"slugs":117,"title":121,"excerpt":122,"readTime":123,"views":124,"isPinned":19,"noindex":19,"publishedAt":125,"updatedAt":126,"category":127,"categories":128,"featuredImage":29,"bgImage":30,"posterImage":130,"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","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,"2026-08-06T00:00:00+00:00","2026-10-23T13:27:09+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[129],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":132,"slug":133,"slugs":134,"title":138,"excerpt":139,"readTime":140,"views":141,"isPinned":19,"noindex":19,"publishedAt":142,"updatedAt":143,"category":144,"categories":145,"featuredImage":29,"bgImage":30,"posterImage":147,"relatedSolution":29},282,"docker-compose-depends-on-healthcheck",{"fr":133,"en":135,"ar":136,"es":137},"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,0,"2026-08-19T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[146],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fdocker-compose-depends-on-healthcheck-poster.svg",{"id":149,"slug":150,"slugs":151,"title":155,"excerpt":156,"readTime":17,"views":157,"isPinned":19,"noindex":19,"publishedAt":158,"updatedAt":159,"category":160,"categories":165,"featuredImage":29,"bgImage":30,"posterImage":167,"relatedSolution":29},382,"securite-vps-mises-a-jour-automatiques-debian-ubuntu",{"fr":150,"en":152,"ar":153,"es":154},"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.",2,"2026-09-26T00:00:00+00:00","2026-11-09T20:55:15+00:00",{"id":140,"name":161,"slug":162,"color":163,"icon":164},"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[166],{"id":140,"name":161,"slug":162,"color":163,"icon":164},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",true,1794270703163]