Docker Compose 5.5: init container nativi, pull_policy con finestre di refresh e riconciliazione dei digest

Chi gestisce server Linux con applicazioni containerizzate ha probabilmente già incontrato Docker Compose: lo strumento che permette di descrivere, in un unico file YAML, tutti i servizi che compongono un'applicazione (database, backend, reverse proxy, cache) e di avviarli con un solo comando. Negli ultimi mesi il progetto ha rilasciato una serie di aggiornamenti (dalla versione 5.3 di luglio 2026 fino alla 5.5.1 di inizio settembre) che introducono alcune funzionalità molto richieste dalla community di amministratori di sistema: i cosiddetti init container nativi, una gestione più raffinata degli aggiornamenti delle immagini tramite pull_policy e una riconciliazione dei digest che evita riavvii superflui dei container. Vediamo nel dettaglio cosa cambia e come sfruttare queste novità in modo sicuro.

Cos'è un init container e perché serve

Un init container (container di inizializzazione) è un piccolo container che viene eseguito prima del servizio vero e proprio, per svolgere operazioni preliminari: applicare le migrazioni di un database, scaricare file di configurazione, impostare i permessi corretti su una cartella condivisa, attendere che una dipendenza sia pronta. Prima della versione 5.3 di Docker Compose (rilasciata il 2 luglio 2026), per ottenere questo comportamento gli amministratori dovevano ricorrere a soluzioni indirette, come servizi "usa e getta" definiti a parte nel file docker-compose.yml e collegati tramite depends_on, oppure script di shell eseguiti manualmente prima dell'avvio.

Con l'introduzione del supporto nativo, gli init container si configurano direttamente all'interno del servizio tramite la nuova direttiva pre_start. Ogni passo elencato in pre_start viene eseguito in un container temporaneo subito dopo la creazione del servizio principale ma prima del suo avvio effettivo; se un passo termina con un codice di uscita diverso da zero, il servizio non parte, evitando così che un'applicazione si avvii in uno stato incoerente (ad esempio con un database non ancora aggiornato).

Un esempio pratico chiarisce meglio il funzionamento:

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:

In questo esempio, prima che il servizio app venga avviato vengono eseguiti in sequenza due passi: la migrazione del database tramite il comando dell'applicazione stessa, e la correzione dei permessi sulla cartella condivisa /data usando l'immagine minimale busybox. Se non si specifica un'immagine diversa, ogni passo eredita di default l'immagine del servizio principale; tutti i passaggi condividono inoltre le stesse reti e gli stessi volumi del servizio, quindi i file preparati durante l'inizializzazione sono immediatamente visibili al container definitivo. Un dettaglio utile per chi amministra ambienti con risorse limitate: un passo pre_start che non è cambiato rispetto all'esecuzione precedente e che è già andato a buon fine viene saltato automaticamente nelle esecuzioni successive.

pull_policy: aggiornamenti delle immagini più intelligenti

La direttiva pull_policy esiste da tempo in Docker Compose e permette di controllare quando un'immagine deve essere scaricata nuovamente dal registro: i valori più comuni sono always (scarica sempre l'ultima versione), missing (scarica solo se l'immagine non è già presente localmente), never (non scaricare mai, utile in ambienti isolati) e build (costruisce l'immagine localmente invece di scaricarla). Con la versione 5.5.0, rilasciata il 17 agosto 2026, il comando compose pull è diventato più consapevole del tempo trascorso dall'ultimo aggiornamento: rispetta infatti le finestre di refresh configurabili (ad esempio con cadenza giornaliera, settimanale o ogni N esecuzioni), evitando di ricontattare inutilmente il registro remoto quando l'immagine è già stata verificata di recente. Per un amministratore che gestisce decine di container su più server, questo si traduce in meno traffico di rete generato dai controlli automatici e in tempi di deploy più prevedibili, specialmente quando gli aggiornamenti vengono lanciati da una pipeline di automazione o da un cron job pianificato.

Riconciliazione dei digest: meno riavvii inutili

Sempre nella versione 5.5.0 è stato introdotto un nuovo meccanismo di riconciliazione dei digest delle immagini. In sintesi, Docker Compose ora confronta in modo più preciso il digest (l'impronta univoca) dell'immagine effettivamente in uso da un container con quello dell'immagine più recente disponibile, evitando di ricreare un container quando, in realtà, non ci sono modifiche sostanziali da applicare. Chi lavora con Docker sa quanto sia fastidioso vedere un servizio riavviarsi senza un motivo apparente durante un semplice docker compose up: questo cambiamento riduce proprio questo tipo di interruzioni non necessarie. È bene però sapere che, come segnalato nelle note di rilascio ufficiali, la prima volta che si esegue compose up dopo l'aggiornamento a questa versione, alcuni container esistenti potrebbero comunque venire ricreati, perché i digest vengono rivalutati una tantum con la nuova logica. È quindi consigliabile pianificare questo primo riavvio in una finestra di manutenzione, soprattutto per i servizi in produzione.

Le altre novità della 5.5.1

La versione più recente, la 5.5.1 (3 settembre 2026), si concentra soprattutto su miglioramenti minori ma utili in fase di debug: gli hook di ciclo di vita (i comandi eseguiti automaticamente all'avvio o allo spegnimento di un servizio) ora catturano e mostrano il loro output direttamente nel terminale, il che semplifica la diagnosi quando qualcosa va storto durante queste fasi. È stata inoltre migliorata la visualizzazione degli errori di tracciamento OpenTelemetry quando si usa il flag --debug, utile per chi integra Compose in ambienti di osservabilità più complessi. Tra le correzioni di bug segnaliamo anche una migliore gestione della sincronizzazione delle directory collegate (funzione watch) e un supporto più solido alle opzioni IPAM nella creazione delle reti.

Come aggiornare Docker Compose in sicurezza

Prima di aggiornare, è buona norma verificare la versione attualmente installata con il comando docker compose version. Su gran parte delle distribuzioni Linux, Docker Compose viene installato come plugin del client Docker e si aggiorna insieme al pacchetto docker-compose-plugin tramite il gestore dei pacchetti di sistema (ad esempio apt update && apt upgrade docker-compose-plugin su Debian e Ubuntu). In alternativa, chi ha installato il plugin manualmente può scaricare il binario più recente direttamente dalla pagina delle release ufficiali su GitHub.

Alcuni suggerimenti pratici per chi amministra server in produzione:

Testare prima in un ambiente di staging. Come visto, il nuovo meccanismo di riconciliazione dei digest può causare la ricreazione di alcuni container al primo avvio dopo l'aggiornamento: meglio scoprirlo in un ambiente non critico.
Leggere sempre le note di rilascio ufficiali prima di aggiornare in produzione, per capire se ci sono modifiche di comportamento che riguardano i propri file docker-compose.yml.
Sfruttare gli init container per sostituire eventuali script esterni di inizializzazione già in uso: oltre a semplificare la manutenzione, questo rende il comportamento dell'applicazione più prevedibile e documentato direttamente nel file di configurazione.
Valutare le finestre di refresh di pull_policy se si gestiscono molti host e si vuole ridurre il carico sui registri Docker privati aziendali.

Nel complesso, queste novità confermano una tendenza chiara nell'evoluzione di Docker Compose: renderlo sempre più adatto a scenari di produzione reali, riducendo la necessità di script esterni e migliorando la prevedibilità degli aggiornamenti, due aspetti particolarmente apprezzati da chi amministra sistemi Linux su base quotidiana.

Fonti ufficiali

Note di rilascio ufficiali di Docker Compose su GitHub
Documentazione ufficiale Docker: Use init containers in Compose
Documentazione ufficiale Docker: docker compose pull