Qual è la differenza tra docker stope docker kill?
Dopo tutto, entrambi fermeranno un container in esecuzione. È quello che docker stoptenta di fermare il processo all'interno del contenitore nel modo corretto, mentre docker killinvierà un segnale di arresto ? In tal caso, come docker stopsapere come arrestare correttamente il processo in esecuzione. (Poiché questo differisce da un processo all'altro)
Risposte:
È che l'arresto della finestra mobile tenta di interrompere l'esecuzione del processo all'interno del contenitore nel modo corretto, mentre l'uccisione della finestra mobile invierà un segnale di arresto?
Fondamentalmente sì, la differenza è sottile, ma delineata nel riferimento della riga di comando :
Quindi stoptenta di innescare un arresto grazioso inviando il segnale POSIX standard SIGTERM, mentre killper impostazione predefinita uccide semplicemente il processo (ma consente anche di inviare qualsiasi altro segnale):
Il segnale SIGTERM viene inviato a un processo per richiederne la chiusura. A differenza del segnale SIGKILL, può essere catturato, interpretato o ignorato dal processo. Ciò consente al processo di eseguire una buona terminazione rilasciando risorse e salvando lo stato, se appropriato. Va notato che SIGINT è quasi identico a SIGTERM.
Sebbene non siano comunque applicati, i processi dovrebbero generalmente gestirsi con SIGTERMgrazia e fare la cosa giusta a seconda delle loro responsabilità - questo può facilmente fallire a causa del grazioso tentativo di spegnimento che richiede più tempo del periodo di tolleranza, il che è qualcosa da considerare se l'integrità dei dati è di fondamentale importanza (ad es. per database); vedi ad esempio SIGTERM del maggiore Hayden contro SIGKILL per una spiegazione più dettagliata:
L'applicazione può determinare cosa vuole fare una volta ricevuto un SIGTERM. Mentre la maggior parte delle applicazioni pulirà le loro risorse e si fermerà, alcune potrebbero non farlo. Un'applicazione può essere configurata per fare qualcosa di completamente diverso quando si riceve un SIGTERM. Inoltre, se l'applicazione si trova in uno stato non valido, ad esempio in attesa di I / O del disco, potrebbe non essere in grado di agire sul segnale inviato.
docker killa mano per risparmiare un po 'di tempo durante l'arresto, ma in uno script, non sarebbe sempre meglio tentare un arresto grazioso tramite docker stop? Però sto ancora vedendo molte docker kills negli script.
docker kill interromperà bruscamente il processo / programma dell'entrata principale
docker stop proverò a fermarlo con grazia (chiederà educatamente: P)
in entrambi i casi le modifiche al filesystem saranno persistenti (al momento dell'arresto o dell'uccisione), quindi se docker start <container>continui da lì.
docker killmodifiche al file system in sospeso che il processo principale aveva ancora in memoria andrà perso, quindi il file system potrebbe finire danneggiato?
docker killè analogo all'uccisione di un processo, non allo spegnimento del computer.
E oltre alle risposte aggiunte in precedenza
in esecuzione docker eventsdopo docker stopmostra eventi
in esecuzione docker eventsdopo docker killmostra eventi
docker stopha un timeout prima di terminare il processo. L'impostazione predefinita è 10 secondi.
Questa tabella ha ancora più dettagli.
È analogo a Staccare la spina dal desktop e spegnere il computer
Come staccare la spina significa spegnere la corrente, docker killsignifica il modo diretto per uccidere my_container, che non tenta prima di chiudere il processo con grazia.
Arrestare il computer significa inviare un segnale al sistema operativo per arrestare tutti i processi in cui docker stopsignifica inviare un SIGTERMsegnale al contenitore in esecuzione per arrestare i processi con garbo.