Docker ti offre diverse opzioni per gestire il ciclo di vita del tuo container. I contenitori normalmente non si riavviano automaticamente dopo la chiusura. Con i criteri di riavvio, puoi assumere il controllo sui cicli di vita dei singoli container.
I criteri di riavvio verranno utilizzati ogni volta che un contenitore interrompe l'esecuzione. Docker esamina anche le politiche di riavvio all'avvio del demone. Puoi utilizzare questo meccanismo per richiamare i container con il tuo host dopo i riavvii.
Norme disponibili
Attualmente sono disponibili quattro diversi criteri di riavvio:
no
– Questa politica non avvierà mai automaticamente un container. Questa è la politica predefinita per tutti i contenitori creati condocker run
.always
– Docker assicurerà che il container sia sempre in esecuzione. Se il container si ferma, verrà immediatamente riavviato. Puoi comunque fermare manualmente il contenitore condocker stop
ma Docker lo riattiverà al prossimo riavvio del demone.on-failure
– Il contenitore verrà riavviato se si arresta a causa di un errore. Docker non attiverà il container dopo il riavvio del demone.unless-stopped
– Funziona in modo simile aalways
. La differenza è che Docker non riavvierà mai il container se è stato arrestato manualmente.
In genere utilizzerai una delle ultime tre opzioni per i carichi di lavoro di produzione. Poiché i contenitori Docker vengono spesso utilizzati per servizi in background di lunga durata, di solito si desidera che si riavviino ogni volta che qualcosa va storto. Il no
politica è più adatta all'uso dello sviluppo locale. È anche utile per contenitori di utilità che eseguono un singolo eseguibile e quindi terminano.
Può essere difficile decidere quale criterio di riavvio utilizzare. always
è spesso la scelta più naturale, ma il comportamento di riavvio del demone può essere facilmente trascurato. Se desideri che i container rimangano fermi in modo affidabile dopo aver eseguito docker stop
, dovresti usare unless-stopped
.
Docker rileva gli errori in base al codice di uscita emesso dal processo in primo piano del contenitore. Un codice di uscita di 1
o superiore viene interpretato come un errore. Questo corrisponde alla gestione Unix dei codici di uscita, dove solo 0
rappresenta un'esecuzione riuscita.
Quando Docker riavvia il tuo container, equivale a eseguire docker run
ancora. Ciò significa il ENTRYPOINT
dell'immagine verrà richiamato lo script. I sistemi Bootstrap dovrebbero sempre essere resilienti a più invocazioni.
Applicazione di una politica di riavvio
Puoi avviare un container con una politica di riavvio specifica passando il --restart
contrassegnare su docker run
:
docker run --name httpd --restart always httpd:latest
Se stai utilizzando Docker Compose, aggiungi il restart
campo nel tuo docker-compose.yml
:
services: httpd: image: httpd:latest restart: always
Puoi modificare la politica di riavvio di un container esistente utilizzando docker update
. Passa il nome del contenitore al comando. Puoi trovare i nomi dei contenitori eseguendo docker ps -a
.
docker update --restart-policy unless-stopped httpd
Puoi utilizzare docker update
con contenitori in esecuzione o fermi.
Riavvia i loop
Docker include un paio di salvaguardie contro i cicli di riavvio perpetuo. Il primo è un ritardo obbligatorio prima dell'attivazione delle politiche di riavvio. Docker non inizierà a monitorare i riavvii finché un contenitore non è in esecuzione da almeno 10 secondi. Ciò impedisce il riavvio continuo di un container guasto.
L'altro comportamento specialistico riguarda il docker stop
comando. Docker rispetterà sempre l'uso di docker stop
, quindi il contenitore non si riavvierà immediatamente dopo aver eseguito il comando. Se vuoi davvero riavviare il contenitore, usa docker restart
invece.
Limitazione dei tentativi di riavvio
Il on-failure
la politica di riavvio consente di specificare quanti tentativi devono essere tentati. Docker si arrenderà e lascerà il container in uno stato di arresto se non si avvia più volte di seguito.
docker run httpd:latest --restart on-failure:5
In questo esempio, Docker tenterà di riavviare il contenitore cinque volte dopo un errore (codice di uscita diverso da zero). Se il contenitore non si avvia al quinto tentativo, non verranno più tentati tentativi. Questa opzione è utile per i contenitori in cui è improbabile che un errore di avvio persistente venga risolto senza un intervento manuale.
Indagine sul motivo per cui i container si sono fermati
Se hai bisogno di sapere perché un container si è fermato, esegui docker ps -a
. Questo mostrerà i dettagli di tutti i tuoi container, fermi o in esecuzione. Trova il contenitore di destinazione e guarda nella sua colonna "Stato". Per i contenitori fermi, il codice di uscita verrà mostrato tra parentesi. Se il codice è maggiore di zero, il contenitore è terminato a causa di un errore.
Dovresti fare riferimento alla documentazione per il processo in esecuzione nel contenitore per determinare il significato dei singoli codici di errore. Tuttavia, puoi spesso ottenere informazioni dettagliate su ciò che ha causato un arresto anomalo recuperando i log del contenitore. I log rimangono disponibili dopo l'arresto di un container.
docker logs my-container
Il flusso di log aggrega l'output standard del contenitore e i flussi di errore standard. Se l'errore è stato registrato, dovresti aspettarti di vederlo nelle ultime righe di output.
Riepilogo
Le politiche di riavvio aiutano a garantire che i contenitori Docker siano disponibili quando ne hai bisogno. Il no
predefinito il criterio non è adatto per la maggior parte dei carichi di lavoro di produzione. Non vuoi che i tuoi container rimangano fermi in caso di arresto anomalo!
L'uso di una delle tre politiche di riavvio rende i contenitori più resilienti ai riavvii hardware e alla chiusura imprevista. Docker manterrà la disponibilità del servizio in caso di arresto anomalo del container.