Docker Compose 5.5 : conteneurs d’initialisation natifs, fenêtres d’actualisation pull_policy et rapprochement des digests

Qui gère les serveurs Linux avec des applications conteneurisées a probablement déjà rencontré Docker Compose : l'outil qui permet de décrire, dans un seul fichier YAML, tous les services qui composent une application (base de données, backend, proxy inverse, cache) et de les démarrer avec une seule commande. Ces derniers mois, le projet a publié une série de mises à jour (de la version 5.3 de juillet 2026 à 5.5.1 du début de septembre) qui présentent quelques caractéristiques très populaires de la communauté des administrateurs de système:contenant initnatifs, une gestion plus raffinée des mises à jour d'imagespull_policyet unerapprochement des digestsqui évite les remises inutiles du contenant. Voyons en détail ce qui change et comment exploiter ces nouveautés en toute sécurité.

Qu'est-ce qu'un contenant init et pourquoi il sert

Acontenant init(initialization container) est un petit conteneur qui est exécuté avant le service réel, pour effectuer des opérations préliminaires: appliquer les migrations d'une base de données, télécharger des fichiers de configuration, définir les permissions correctes sur un dossier partagé, attendre qu'une dépendance soit prête. Avant la version 5.3 de Docker Compose (publiée le 2 juillet 2026), les administrateurs devaient recourir à des solutions indirectes, telles que les services "utilisation et lancement" mis de côté dans le fichier docker-compose.ymlet connecté viadepends_on, ou scripts shell exécutés manuellement avant le démarrage.

Avec l'introduction du support natif, les conteneurs init sont configurés directement dans le service par le biais de la nouvelle directivepre_start. Chaque étapepre_startest exécuté dans un conteneur temporaire immédiatement après la création du service principal mais avant son début réel; si une étape se termine par un code de sortie différent de zéro, le service ne s'en va pas, évitant ainsi une application pour démarrer dans un état incohérent (par exemple avec une base de données non encore mise à jour).

Un exemple pratique clarifie mieux l'opération:

services:
  app:
    image: myapp:latest
    user: "1000:1000"
    volumes:
      - data:/data
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]
      - image: busybox
        user: root
        command: sh -c 'chown -R 1000:1000 /data'

  db:
    image: postgres:18
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]

volumes:
  data:

Dans cet exemple, avant le serviceappdeux étapes sont prises en séquence : la migration de la base de données par la commande d'application elle-même, et la correction des permissions sur le dossier partagé/datautilisant une image minimalebusybox. Si vous ne spécifiez pas une image différente, chaque étape par défaut hérite de l'image du service principal ; toutes les étapes partagent également les mêmes réseaux et les mêmes volumes du service, alors les fichiers préparés lors de l'initialisation sont immédiatement visibles au conteneur définitif. Un détail utile pour ceux qui gèrent des environnements avec des ressources limitées : une étapepre_startqui n'a pas changé par rapport à l'exécution précédente et qui est déjà allé à bonne fin est automatiquement sauté dans les exécutions successives.

pull_policy: mises à jour d'images plus intelligentes

La directivepull_policyexiste depuis longtemps dans Docker Compose et vous permet de vérifier quand une image doit être téléchargée à nouveau depuis le registre: les valeurs les plus communes sonttoujours(Toujours télécharger la dernière version),manquant(Télécharger seulement si l'image n'est pas présente localement),♪( jamais télécharger, utile dans des environnements isolés) etconstruire(construit l'image localement au lieu de la télécharger). Avec la version 5.5.0, publiée le 17 août 2026,compose pullest devenu plus conscient du temps passé par la dernière mise à jour: il respecte les fenêtres de rafraîchissement configurables (par exemple, les exécutions quotidiennes, hebdomadaires ou toutes les exécutions N), évitant de reconnecter inutilement le registre à distance lorsque l'image a déjà été vérifiée récemment. Pour un administrateur qui gère des dizaines de conteneurs sur plusieurs serveurs, il en résulte moins de trafic réseau généré par des contrôles automatiques et des temps de déploiement plus prévisibles, surtout lorsque des mises à jour sont lancées par un pipeline d'automatisation ou un travail de cron planifié.

Rapprochement des digesteurs : des rappels moins inutiles

Aussi dans la version 5.5.0 un nouveau mécanisme a été introduitrapprochement des images digestes. En résumé, Docker Compose compare maintenant plus précisément le digest (l'empreinte unique) de l'image réellement utilisée par un conteneur avec celle de l'image la plus récente disponible, évitant de recréer un conteneur lorsque, en réalité, il n'y a pas de changements substantiels à appliquer. Qui travaille avec Docker sait combien c'est gênant de voir un service redémarrer sans raison apparente pendant une simpledocker compose up: Ce changement réduit ce genre d'interruptions inutiles. Mais il est bon de savoir que, comme indiqué dans les notes officielles,la première foisque vous exécutezcompose upAprès la mise à niveau de cette version, certains conteneurs existants pourraient encore être recréés, car les digests sont revalorisés une fois avec la nouvelle logique. Il est donc conseillé de planifier ce premier redémarrage dans une fenêtre de maintenance, en particulier pour les services de production.

Les autres nouvelles de 5.5.1

La version la plus récente, 5.5.1 (3 septembre 2026), porte principalement sur les améliorations mineures mais utiles dans le débogage :Crochet du cycle de vie(les commandes exécutées automatiquement au début ou à l'arrêt d'un service) capturent et montrent maintenant leur sortie directement dans le terminal, ce qui simplifie le diagnostic lorsque quelque chose tourne mal pendant ces étapes. Les erreurs de suivi OpenTelemetry ont également été améliorées lors de l'utilisation du drapeau--debug, utile pour ceux qui intègrent Compose dans des environnements d'observation plus complexes. Parmi les corrections de bug, nous signalons également une meilleure gestion de la synchronisation des répertoires liés (fonctionwatch) et une meilleure prise en charge des options IPAM dans la création de réseaux.

Comment mettre à jour Docker Compose en toute sécurité

Avant de mettre à niveau, il est bon de vérifier la version actuellement installée avec la commandedocker compose version. Sur la plupart des distributions Linux, Docker Compose est installé comme un plugin client Docker et des mises à jour avec le paquetdocker-compose-pluginvia le gestionnaire de paquets système (p. ex.apt update && apt upgrade docker-compose-pluginsur Debian et Ubuntu). Alternativement, ceux qui ont installé le plugin manuellement peuvent télécharger la dernière piste directement depuis la page de sortie officielle sur GitHub.

Quelques suggestions pratiques pour ceux qui administrent des serveurs en production:

Testez d'abord dans un environnement de mise en scène.Comme on l'a vu, le nouveau mécanisme de rapprochement du digest peut causer la récréation de certains conteneurs au premier départ après la mise à jour : mieux le découvrir dans un environnement non critique.
Lisez toujours les notes de sortie officiellesavant de mettre à niveau vers la production, pour voir s'il y a des changements de comportement affectant vos fichiersdocker-compose.yml.
Utiliser le contenant initremplacer tout script d'initialisation externe déjà utilisé : en plus de simplifier la maintenance, cela rend le comportement de l'application plus prévisible et documenté directement dans le fichier de configuration.
Évaluer pull_policy refresh windowssi vous gérez de nombreux hôtes et que vous voulez réduire la charge sur les journaux Docker privés de l'entreprise.

Dans l'ensemble, ces innovations confirment une tendance claire dans l'évolution de Docker Compose : la rendre de plus en plus adaptée aux scénarios de production réels, réduire le besoin de scripts externes et améliorer la prévisibilité des mises à jour, deux aspects particulièrement appréciés par les systèmes Linux quotidiennement.

Sources officielles

Notes de sortie officielles de Docker Compose sur GitHub
Documents officiels Docker: Utiliser des contenants init dans Compose
Documentation officielle Docker: Tire Docker Compose