Come abbinare le policy di riavvio di Docker a database, worker e app web

Abbina le policy di riavvio di Docker al ciclo di vita del servizio e alla semantica dell’uscita, invece di assegnare unless-stopped a ogni container in un file Compose.

Le policy di riavvio reagiscono quando il processo principale di un container termina; un controllo dello stato può contrassegnare come non integro un processo ancora in esecuzione senza riavviarlo automaticamente. Database, worker, app web, migrazioni e processi pianificati richiedono quindi scelte diverse in base al fatto che debbano rimanere attivi, al significato di un’uscita corretta e al modo in cui debbano essere segnalati i guasti ripetuti.

Separa il comportamento di riavvio dallo stato e dalla disponibilità

Una policy di riavvio stabilisce se Docker debba riavviare un container dopo l’arresto del suo processo. Un controllo dello stato verifica se il servizio in esecuzione è in grado di eseguire un’operazione definita. La disponibilità delle dipendenze stabilisce invece se un altro servizio debba ancora attendere prima di avviarsi. Risolvono problemi correlati, ma diversi.

Un’analisi del 2026 su stato e riavvio separati spiega questa distinzione e mostra come le condizioni di stato di Compose possano ritardare l’avvio dei servizi dipendenti finché un servizio non è effettivamente pronto.

Non aspettarti che restart: always ripari un processo web non integro che non termina mai, né che un controllo dello stato da solo lo riavvii. Fai terminare l’applicazione quando non è sicuro continuare, aggiungi un meccanismo esterno di correzione oppure genera un avviso quando lo stato è non integro, in base alla progettazione del servizio.

Usa policy di riavvio persistenti per i database a esecuzione continua

Normalmente ci si aspetta che un database su home server torni operativo dopo il riavvio dell’host o del demone Docker. unless-stopped è spesso un’impostazione predefinita pratica quando si desidera rispettare un arresto intenzionale da parte dell’amministratore; always è appropriato quando, per scelta progettuale, il riavvio deve annullare quello stato di arresto manuale.

Un’analisi di luglio 2026 su come funzionano le policy di riavvio descrive le differenze tra no, on-failure, always e unless-stopped, compreso il fatto che la policy reagisce alla terminazione del processo e non allo stato di salute.

Il database necessita inoltre di un vero controllo dello stato e di uno storage persistente. Riavviare ripetutamente PostgreSQL non può risolvere un disco pieno, una configurazione non valida, dati corrotti o una migrazione incompatibile. Genera un avviso sui riavvii ripetuti invece di considerarli una resilienza riuscita.

Scegli la policy dei worker in base alla coda e alla semantica dell’uscita

Un worker per code a esecuzione continua può richiedere unless-stopped se deve consumare sempre il lavoro disponibile. Un worker finito o un processo batch può usare on-failure:N, così gli errori temporanei ricevono un numero limitato di tentativi mentre un errore persistente arresta il processo in modo visibile.

Un’analisi aggiornata su tentativi limitati con on-failure sottolinea che il comportamento dei tentativi deve corrispondere al fatto che un processo debba rimanere attivo permanentemente o possa terminare normalmente.

Stabilisci cosa significa il codice di uscita 0 per l’immagine del worker. Se significa “lavoro completato”, always può trasformare un lavoro eseguito una sola volta in un ciclo infinito. Se il worker deve funzionare come demone, un’uscita corretta ma imprevista può comunque giustificare un riavvio automatico tramite unless-stopped.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mantieni le app web attive a lungo, ma vincolale alle dipendenze reali

La maggior parte delle applicazioni web self-hosted è progettata per rimanere continuamente disponibile, quindi unless-stopped è generalmente più facile da gestire rispetto a una policy limitata ai soli errori. L’impostazione di riavvio non elimina la necessità che database, cache, DNS, segreti e percorsi montati siano pronti.

La diagnostica correlata di ZimaSpace sui cicli di riavvio causati dalle dipendenze del container mostra perché riavviare ripetutamente l’app visibile può nascondere il problema di database, cache, mount, migrazione o memoria che si è verificato per primo.

Usa i controlli dello stato delle dipendenze per stabilire l’ordine di avvio, quando appropriato, e limita il comportamento di ripetizione dell’applicazione. Un servizio web che si arresta ogni cinque secondi finché PostgreSQL non si avvia è meno osservabile di uno che attende la disponibilità e produce un unico avvio corretto.

Assegna alle migrazioni e ai lavori eseguiti una sola volta un ciclo di vita finito

I container per migrazioni, importazioni, attività di manutenzione e inizializzazione una tantum non sono normali demoni. Il loro stato di successo è spesso “termina con codice 0 e rimani arrestato”. Usare always o unless-stopped può eseguire nuovamente il lavoro completato in modo involontario.

Mantieni espliciti gli strumenti operativi eseguiti una sola volta invece di permettere che diventino servizi sempre attivi nascosti. Una migrazione o un importatore dovrebbe avere uno stato di successo finito, che rimanga visibile dopo la terminazione del comando.

Usa restart: "no" quando un errore deve causare un arresto per consentire l’ispezione, oppure on-failure con un numero limitato di tentativi solo quando il comando può essere ripetuto senza rischi. Per le migrazioni dello schema, verifica prima che sia supportata la ripetizione di una migrazione applicata solo parzialmente, quindi automatizza i tentativi.

Verifica la policy con scenari di errore reali

Per ogni servizio, verifica un’uscita corretta del processo, un arresto anomalo con codice diverso da zero, il riavvio dell’host, il riavvio del demone Docker, l’arresto manuale, una condizione di servizio non integro ma ancora in esecuzione e una dipendenza non disponibile. Registra lo stato previsto dopo ogni evento prima di definire resiliente la configurazione.

Monitora il numero di riavvii e genera un avviso quando supera una soglia bassa in un determinato intervallo. Il riavvio automatico dovrebbe ridurre il tempo di ripristino da un errore temporaneo; non dovrebbe rendere invisibile un arresto persistente producendo un flusso infinito di nuovi container.

Una buona matrice delle policy è esplicita: database e app web a esecuzione continua tornano operativi dopo i riavvii dell’infrastruttura, i worker demone si ripristinano in base alla semantica della coda, i lavori finiti si arrestano al completamento e i controlli dello stato e della disponibilità rendono visibili gli errori che la policy di riavvio non può rilevare.