Comparación entre Docker Stop y Kill: Cuándo Usar Cada Comando

Cuando tu contenedor necesita apagarse, docker stop y docker kill no son intercambiables. La diferencia importa más cuando tu aplicación escribe datos, mantiene conexiones de red o necesita tiempo de limpieza antes de salir.

Usa docker stop para apagados normales. Usa docker kill cuando necesites una señal inmediata, generalmente porque el contenedor ignoró una parada gradual o estás probando el comportamiento ante fallos.

Entendiendo docker stop

El comando docker stop solicita al proceso principal del contenedor que salga limpiamente. Por defecto, Docker envía SIGTERM al PID 1 dentro del contenedor, espera un período de gracia y luego envía SIGKILL si el proceso aún se está ejecutando.

Esa primera señal se puede cambiar mediante la instrucción STOPSIGNAL de la imagen o mediante la opción --stop-signal utilizada al crear el contenedor. En la mayoría de los casos cotidianos, sin embargo, puedes pensar en docker stop como "enviar a la aplicación una solicitud de apagado, luego forzarla solo si no sale".

• Guardar su estado actual.
• Cerrar conexiones de red abiertas.
• Liberar los recursos que posee.
• Completar cualquier operación en curso (como escribir datos en el disco).

En contenedores Linux, el tiempo de espera predeterminado es comúnmente de 10 segundos a menos que se haya configurado un tiempo de espera de parada diferente para el contenedor. Los contenedores Windows usan un valor predeterminado más largo. Puedes anular el tiempo de espera por comando con -t o --time.

Cómo funciona docker stop

1. Enviar SIGTERM: Docker envía una señal SIGTERM al proceso principal (PID 1) dentro del contenedor.
2. Esperar el período de gracia: Docker espera a que el proceso salga.
3. Enviar SIGKILL (si es necesario): Si el proceso no ha salido al final del período de gracia, Docker envía una señal SIGKILL.

Cuándo usar docker stop

• Apagado normal de la aplicación: Este es el método preferido para detener aplicaciones que necesitan apagarse limpiamente, como bases de datos, servidores web o aplicaciones que realizan escrituras críticas.
• Entornos de desarrollo: Para paradas rutinarias durante el desarrollo, docker stop asegura que no interrumpas accidentalmente procesos en curso.
• Entornos de producción para mantenimiento planificado: Cuando necesitas reiniciar un servicio o realizar actualizaciones, docker stop permite que la aplicación termine su trabajo.

Ejemplo

# Iniciar un contenedor llamado 'my-web-server'
docker run -d --name my-web-server -p 80:80 nginx

# Detener el contenedor de forma gradual
docker stop my-web-server

# Verificar que el contenedor está detenido
docker ps -a | grep my-web-server

Si tu aplicación necesita más tiempo para vaciar colas o cerrar conexiones de base de datos, dale un tiempo de espera más largo:

docker stop --time 30 my-web-server

Entendiendo docker kill

El comando docker kill envía una señal al proceso principal del contenedor inmediatamente. Por defecto, esa señal es SIGKILL. A diferencia de SIGTERM, SIGKILL no puede ser capturada, ignorada o manejada por el proceso. El sistema operativo finaliza el proceso sin darle la oportunidad de limpiar.

Eso significa que los datos no guardados, las conexiones abiertas o las escrituras en curso pueden interrumpirse. Un contenedor de prueba sin estado puede no importarle. Una base de datos, un trabajador de cola o un trabajo de procesamiento de archivos probablemente sí.

También puedes usar docker kill --signal para enviar una señal diferente, como SIGHUP, pero si tu intención es un apagado gradual, docker stop suele ser más claro.

Cómo funciona docker kill

1. Enviar SIGKILL: Docker envía una señal SIGKILL directamente al proceso principal (PID 1) dentro del contenedor.
2. Terminación inmediata: El proceso es terminado por el sistema operativo.

Cuándo usar docker kill

• Contenedores que no responden: Cuando un contenedor está atascado y docker stop no ha podido terminarlo incluso después del período de gracia.
• Paradas de emergencia: En situaciones donde necesitas detener un contenedor inmediatamente, independientemente de las consecuencias, como incidentes de seguridad o fallos críticos.
• Pruebas de resiliencia: Para ver cómo se comporta tu aplicación cuando el proceso desaparece sin limpieza.

Ejemplo

# Iniciar un contenedor llamado 'my-test-app'
docker run -d --name my-test-app ubuntu sleep infinity

# Forzar la detención del contenedor
docker kill my-test-app

# Verificar que el contenedor está detenido
docker ps -a | grep my-test-app

Diferencias Clave Resumidas

Característica	docker stop	docker kill
Señal Enviada	Generalmente SIGTERM, luego SIGKILL si expira el tiempo de espera	SIGKILL por defecto
Terminación	Gradual, permite limpieza	Inmediata, forzada, sin limpieza
Integridad de Datos	Generalmente preserva la integridad de los datos	Riesgo de corrupción de datos o estado inconsistente
Caso de Uso	Apagado normal, mantenimiento planificado	Contenedores que no responden, paradas de emergencia
Período de Gracia	Sí	No

Mejores Prácticas y Consideraciones

• Siempre intenta docker stop primero: Para operaciones rutinarias, docker stop debe ser tu opción predeterminada. Protege tus aplicaciones y datos.
• Comprende las señales de tu aplicación: Las aplicaciones pueden programarse para manejar señales SIGTERM. Asegúrate de que el script de punto de entrada de tu aplicación o el administrador de procesos esté configurado para escuchar y responder a SIGTERM de forma gradual.
• Ajusta el período de gracia para docker stop: Puedes especificar un período de gracia personalizado para docker stop usando el indicador -t o --time. Por ejemplo, docker stop -t 30 my-container le da al contenedor 30 segundos para apagarse.
• Usa docker kill como último recurso: Recurre a docker kill solo cuando docker stop sea ineficaz o en situaciones críticas y urgentes.
• Monitorea la salud del contenedor: Implementar comprobaciones de salud en tu configuración de Docker puede ayudar a identificar contenedores que se están volviendo no respondedores, permitiéndote abordar problemas potencialmente antes de que requieran un docker kill.
• Verifica el comportamiento del PID 1: Los scripts envoltorio de shell pueden tragarse las señales si no las reenvían al proceso real de la aplicación. Prefiere exec en los scripts de punto de entrada para que la aplicación reciba las señales de apagado directamente.

Conclusión Práctica

Haz de docker stop tu hábito normal, especialmente para cualquier cosa con estado. Recurre a docker kill solo cuando el contenedor no responda, cuando la velocidad importe más que la limpieza, o cuando estés probando deliberadamente el comportamiento de fallo.