Un contenedor no es algo estático: pasa por distintos estados a lo largo de su existencia, desde que se crea hasta que se elimina. Comprender este ciclo de vida es clave para gestionar tus contenedores con confianza, saber qué les ocurre en cada momento y elegir el comando adecuado para cada situación. En esta lección recorreremos todos los estados posibles de un contenedor, las transiciones entre ellos y los comandos que las provocan, prestando especial atención a una duda muy habitual entre principiantes: la diferencia entre detener (stop) y matar (kill) un contenedor.

A lo largo de su vida, un contenedor puede encontrarse en uno de varios estados. Conocerlos te ayuda a interpretar lo que ves en docker ps y a saber qué acción tomar.

Una aclaración importante: en la práctica, los estados stopped y exited aparecen muy relacionados. Cuando detienes un contenedor, su proceso principal termina y Docker lo muestra como Exited en el listado, junto con el código de salida.

Ocurre cuando creas un contenedor sin arrancarlo. Esto se hace con docker create en lugar de docker run.

• docker create: prepara el contenedor (descarga la imagen, reserva recursos) pero no lo arranca.
• El contenedor queda en estado created, listo para ejecutarse más tarde con docker start.

Es el estado normal de un contenedor activo. Se alcanza con docker run (que crea y arranca a la vez) o con docker start sobre un contenedor existente.

Un contenedor pausado tiene todos sus procesos congelados en memoria. No consume CPU, pero sigue ocupando RAM. Es útil para liberar procesador temporalmente sin perder el estado.

El contenedor ha dejado de ejecutarse. Puede ser porque su programa terminó por sí solo o porque tú lo detuviste. Los datos de su sistema de archivos siguen ahí hasta que lo elimines.

Las transiciones entre estados se provocan con comandos concretos. Esta tabla resume qué comando lleva de un estado a otro.

Veamos cada comando con ejemplos prácticos.

Vuelve a poner en marcha un contenedor que estaba detenido o que solo se había creado.

• servidor_web: el nombre (o ID) del contenedor a arrancar.
• A diferencia de docker run, no crea un contenedor nuevo: reutiliza el existente, conservando su configuración y datos.

Detiene un contenedor en ejecución de forma ordenada.

• Docker envía la señal SIGTERM al proceso principal, dándole tiempo para cerrar conexiones, guardar datos y terminar limpiamente.
• Si tras un periodo de gracia (10 segundos por defecto) el proceso no ha terminado, Docker envía SIGKILL para forzar el cierre.

Puedes ajustar el tiempo de espera:

• -t 30: concede 30 segundos antes de forzar el cierre. Útil para aplicaciones que necesitan más tiempo para apagarse con seguridad.

Equivale a un stop seguido de un start en un solo comando.

• Muy práctico para aplicar cambios de configuración o recuperar un servicio que se ha quedado bloqueado.

• pause: suspende todos los procesos del contenedor sin terminarlos. La aplicación deja de responder, pero su estado en memoria se conserva intacto.
• unpause: reanuda la ejecución exactamente en el punto donde se detuvo.

Detiene un contenedor de forma inmediata y forzada.

• Docker envía directamente la señal SIGKILL, que termina el proceso al instante, sin periodo de gracia.
• El contenedor no tiene oportunidad de cerrar nada limpiamente.

Esta es una de las distinciones más importantes que debes interiorizar.

En resumen: usa siempre docker stop como opción por defecto. Reserva docker kill para cuando un contenedor está colgado y no responde a stop.

Para ver el estado actual de tus contenedores, usa docker ps:

• docker ps: muestra solo los que están en running.
• docker ps -a (all): incluye también los que están en created, exited, etc. La columna STATUS te indica el estado de cada uno.

• Confundir run con start: docker run siempre crea un contenedor nuevo; docker start reutiliza uno existente. Si haces run repetidamente, acumularás contenedores.
• Usar kill por costumbre: matar contenedores constantemente puede corromper datos. Acostúmbrate a stop.
• Pensar que un contenedor pausado no consume nada: un contenedor en paused libera CPU, pero sigue reteniendo memoria.
• Olvidar -a al listar: si un contenedor "ha desaparecido", probablemente está detenido. Usa docker ps -a para verlo.
• No conceder tiempo suficiente con stop: si tu aplicación necesita más de 10 segundos para cerrar, ajusta -t para evitar cortes abruptos.
• Consejo: revisa el código de salida (columna STATUS) de los contenedores exited; un código distinto de 0 suele indicar que algo falló.

Crea un contenedor de Nginx sin arrancarlo, comprueba su estado, arráncalo, pausa y reanuda, y finalmente detenlo. Observa el estado en cada paso.

Lanza dos contenedores de Nginx. Detén uno con docker stop y el otro con docker kill. Comprueba que ambos terminan, y razona qué diferencia hubo internamente.

Lanza un contenedor de Nginx, reinícialo con un solo comando y verifica que sigue en ejecución después.

Solución 1

Cada comando provoca una transición de estado que puedes confirmar con docker ps / docker ps -a.

Solución 2

ordenado tuvo la oportunidad de cerrarse limpiamente; forzado se cortó de golpe.

Solución 3

docker restart equivale a un stop seguido de un start.

En esta lección hemos recorrido el ciclo de vida completo de un contenedor: sus estados (created, running, paused, stopped/exited), las transiciones entre ellos y los comandos que las controlan (start, stop, restart, pause, unpause, kill). Hemos aclarado la diferencia fundamental entre detener (stop, ordenado) y matar (kill, forzado) un contenedor, una distinción que evita pérdidas de datos accidentales.

En la siguiente lección, Gestionando Contenedores, aprenderás a trabajar con ellos en el día a día: listarlos, inspeccionarlos, leer sus logs, entrar en ellos con exec, copiar ficheros y eliminarlos de forma ordenada.