Mettre à jour une stack Docker Compose en production

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.

C'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é.

L'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.

La première action, avant toute mise à jour, est de remplacer chaque image: getmeili/meilisearch:latest ou image: supabase/postgres par une version explicite.

Deux formes sont acceptables :

- Tag de version : image: getmeili/meilisearch:v1.53.0 — lisible, versionnable dans git, facile à patcher.
- Digest SHA256 : image: getmeili/meilisearch@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).

Pour connaître le digest d'une image déjà en cours d'exécution :

docker inspect --format='{{index .RepoDigests 0}}' getmeili/meilisearch:v1.53.0

Une 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).

Ces quatre exemples illustrent pourquoi le protocole ci-dessus n'est pas théorique.

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 /meili_data --import-dump /backup.dump) — opération possible uniquement si vous avez exporté avant de mettre à jour.

Supabase Docker PostgreSQL 15 → 17 (PG 17 par défaut à partir du 17 juin 2026) : le conteneur supabase/postgres: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.

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/TS 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.

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 (./postgres, ./nocodb) dont le chemin de montage change entre deux déploiements démarre sur une base vide. Les volumes nommés évitent cette dérive.

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 :

# .env
MEILISEARCH_VERSION=v1.53.0
POSTGRES_VERSION=15.6

# docker-compose.yml
services:
  meilisearch:
    image: getmeili/meilisearch:${MEILISEARCH_VERSION}

Mettre à jour une version devient alors un commit unique sur .env — lisible dans git log, réversible par git revert, et déployable par CI/CD sans modifier le fichier Compose principal.

Pour 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.