Confronto tra Docker Stop e Kill: Quando Usare Ciascun Comando

Quando il tuo container deve essere arrestato, docker stop e docker kill non sono intercambiabili. La differenza è importante soprattutto quando la tua app scrive dati, mantiene connessioni di rete o ha bisogno di tempo per la pulizia prima di uscire.

Usa docker stop per arresti normali. Usa docker kill quando hai bisogno di un segnale immediato, di solito perché il container ha ignorato un arresto graduale o stai testando il comportamento in caso di guasto.

Comprendere docker stop

Il comando docker stop chiede al processo principale del container di uscire in modo pulito. Per impostazione predefinita, Docker invia SIGTERM al PID 1 all'interno del container, attende un periodo di grazia, e poi invia SIGKILL se il processo è ancora in esecuzione.

Il primo segnale può essere modificato dall'istruzione STOPSIGNAL dell'immagine o dall'opzione --stop-signal usata quando il container viene creato. Nella maggior parte dei casi quotidiani, comunque, puoi pensare a docker stop come "invia una richiesta di arresto all'app, poi forzala solo se non esce".

• Salvare il suo stato corrente.
• Chiudere le connessioni di rete aperte.
• Rilasciare le risorse che detiene.
• Completare eventuali operazioni in corso (come scrivere dati su disco).

Sui container Linux, il tempo di attesa predefinito è comunemente di 10 secondi, a meno che non sia stato configurato un timeout di stop diverso per il container. I container Windows usano un valore predefinito più lungo. Puoi sovrascrivere il tempo di attesa per comando con -t o --time.

Come funziona docker stop

1. Invia SIGTERM: Docker invia un segnale SIGTERM al processo primario (PID 1) all'interno del container.
2. Attende il periodo di grazia: Docker attende che il processo esca.
3. Invia SIGKILL (se necessario): Se il processo non è uscito entro la fine del periodo di grazia, Docker invia un segnale SIGKILL.

Quando usare docker stop

• Arresto normale dell'applicazione: Questo è il metodo preferito per arrestare applicazioni che devono spegnersi in modo pulito, come database, server web o applicazioni che eseguono scritture critiche.
• Ambienti di sviluppo: Per arresti di routine durante lo sviluppo, docker stop assicura di non interrompere accidentalmente processi in corso.
• Ambienti di produzione per manutenzione programmata: Quando devi riavviare un servizio o eseguire aggiornamenti, docker stop permette all'applicazione di completare il suo lavoro.

Esempio

# Avvia un container chiamato 'my-web-server'
docker run -d --name my-web-server -p 80:80 nginx

# Arresta il container in modo graduale
docker stop my-web-server

# Verifica che il container sia fermo
docker ps -a | grep my-web-server

Se la tua app ha bisogno di più tempo per svuotare le code o chiudere le connessioni al database, dagli un timeout più lungo:

docker stop --time 30 my-web-server

Comprendere docker kill

Il comando docker kill invia un segnale al processo principale del container immediatamente. Per impostazione predefinita, quel segnale è SIGKILL. A differenza di SIGTERM, SIGKILL non può essere intercettato, ignorato o gestito dal processo. Il sistema operativo termina il processo senza dargli la possibilità di fare pulizia.

Ciò significa che dati non salvati, connessioni aperte o scritture in corso potrebbero essere interrotte. Un container di test senza stato potrebbe non preoccuparsene. Un database, un worker di code o un lavoro di elaborazione file probabilmente sì.

Puoi anche usare docker kill --signal per inviare un segnale diverso, come SIGHUP, ma se il tuo intento è un arresto graduale, docker stop è di solito più chiaro.

Come funziona docker kill

1. Invia SIGKILL: Docker invia un segnale SIGKILL direttamente al processo primario (PID 1) all'interno del container.
2. Terminazione immediata: Il processo viene terminato dal sistema operativo.

Quando usare docker kill

• Container che non rispondono: Quando un container è bloccato e docker stop non è riuscito a terminarlo nemmeno dopo il periodo di grazia.
• Arresti di emergenza: In situazioni in cui devi fermare un container immediatamente, indipendentemente dalle conseguenze, come incidenti di sicurezza o guasti critici.
• Test di resilienza: Per vedere come si comporta la tua applicazione quando il processo scompare senza fare pulizia.

Esempio

# Avvia un container chiamato 'my-test-app'
docker run -d --name my-test-app ubuntu sleep infinity

# Forza l'arresto del container
docker kill my-test-app

# Verifica che il container sia fermo
docker ps -a | grep my-test-app

Differenze Chiave Riassunte

Caratteristica	docker stop	docker kill
Segnale Inviato	Di solito SIGTERM, poi SIGKILL se il timeout scade	SIGKILL per impostazione predefinita
Terminazione	Graduale, permette la pulizia	Immediata, forzata, nessuna pulizia
Integrità dei Dati	Generalmente preserva l'integrità dei dati	Rischia corruzione dei dati o stato inconsistente
Caso d'Uso	Arresto normale, manutenzione programmata	Container che non rispondono, arresti di emergenza
Periodo di Grazia	Sì	No

Best Practice e Considerazioni

• Prova sempre prima docker stop: Per operazioni di routine, docker stop dovrebbe essere la tua scelta predefinita. Protegge le tue applicazioni e i tuoi dati.
• Comprendi i segnali della tua applicazione: Le applicazioni possono essere programmate per gestire i segnali SIGTERM. Assicurati che lo script di entry point della tua applicazione o il gestore di processi sia configurato per ascoltare e rispondere a SIGTERM in modo graduale.
• Regola il periodo di grazia per docker stop: Puoi specificare un periodo di grazia personalizzato per docker stop usando il flag -t o --time. Ad esempio, docker stop -t 30 my-container dà al container 30 secondi per spegnersi.
• Usa docker kill come ultima risorsa: Ricorri a docker kill solo quando docker stop è inefficace o in situazioni critiche e urgenti.
• Monitora la salute del container: Implementare controlli di salute nella tua configurazione Docker può aiutare a identificare container che stanno diventando non reattivi, permettendoti di affrontare potenzialmente i problemi prima che richiedano un docker kill.
• Controlla il comportamento del PID 1: Gli script wrapper di shell possono inghiottire i segnali se non li inoltrano al vero processo dell'app. Preferisci exec negli script di entry point in modo che l'app riceva direttamente i segnali di arresto.

Consiglio Pratico

Fai di docker stop la tua abitudine normale, specialmente per qualsiasi cosa con stato. Ricorri a docker kill solo quando il container non risponde, quando la velocità è più importante della pulizia, o quando stai deliberatamente testando il comportamento in caso di crash.