¿Cuál es la diferencia entre docker stopy docker kill?
Afaik, ambos detendrán un contenedor en funcionamiento. ¿Es eso lo que docker stopintenta detener el proceso que se ejecuta dentro del contenedor de la manera correcta, mientras docker killenvía una señal de cierre? Si es así, ¿cómo docker stopsabría cómo detener correctamente el proceso en ejecución? (Dado que esto difiere de un proceso a otro)
Respuestas:
¿Es que Docker Stop intenta detener el proceso que se ejecuta dentro del contenedor de la manera correcta, mientras que Docker kill enviará una señal de muerte?
Básicamente sí, la diferencia es sutil, pero se describe en la referencia de la Línea de comandos :
Por lo tanto, stopintenta desencadenar un apagado correcto enviando la señal POSIX estándar SIGTERM, mientras que killsimplemente elimina el proceso de forma predeterminada (pero también permite enviar cualquier otra señal):
La señal SIGTERM se envía a un proceso para solicitar su terminación. A diferencia de la señal SIGKILL, el proceso puede detectarla e interpretarla o ignorarla. Esto permite que el proceso realice una terminación agradable liberando recursos y guardando el estado si es apropiado. Cabe señalar que SIGINT es casi idéntico a SIGTERM.
Si bien no se aplica de ninguna manera, generalmente se espera que los procesos se manejen con SIGTERMgracia y hagan lo correcto según sus responsabilidades; esto puede fallar fácilmente debido a que el intento de cierre correcto tarda más que el período de gracia, lo cual es algo a considerar si la integridad de los datos es primordial (por ejemplo, para bases de datos); ver, por ejemplo, SIGTERM vs. SIGKILL del Mayor Hayden para una explicación más detallada:
La aplicación puede determinar qué quiere hacer una vez que se recibe un SIGTERM. Si bien la mayoría de las aplicaciones limpiarán sus recursos y se detendrán, algunas no. Una aplicación puede configurarse para hacer algo completamente diferente cuando se recibe un SIGTERM. Además, si la aplicación está en mal estado, como esperando E / S de disco, es posible que no pueda actuar sobre la señal que se envió.
docker killusaríamos a mano para ahorrar algo de tiempo durante el apagado, pero en un script, ¿no sería siempre mejor intentar un apagado correcto docker stop? Sin embargo, todavía veo muchos docker kills en scripts.
docker kill detendrá el proceso / programa del punto de entrada principal abruptamente
docker stop intentará detenerlo con gracia (preguntará cortésmente: P)
en ambos casos, los cambios en el sistema de archivos persistirán (en el momento de la detención o eliminación), por lo que si docker start <container>continúa, continuará desde allí.
docker killhaya cambios pendientes en el sistema de archivos que el proceso principal todavía tenía en la memoria se perderá, ¿entonces el sistema de archivos podría terminar dañado?
docker killes análogo a matar un proceso, no apagar la computadora.
Y además de las respuestas agregadas anteriormente
corriendo docker eventsdespués de docker stopmuestra eventos
corriendo docker eventsdespués de docker killmuestra eventos
docker stoptiene un tiempo de espera antes de matar el proceso. El valor predeterminado es de 10 segundos.
Esta tabla tiene aún más detalles.
Es análogo a quitar el enchufe del escritorio y apagar la computadora
Al igual que desconectar el Plug Off significa un apagado total, docker killsignifica una forma directa de matar a my_container, que no intenta cerrar el proceso con gracia primero.
Apagar la computadora significa enviar una señal al sistema operativo para apagar todos los procesos, lo que docker stopsignifica enviar SIGTERMseñal al contenedor en ejecución para detener los procesos con gracia.