Cómo reiniciar automáticamente un contenedor Docker cuando deja de responder

Seguro que te ha pasado: tienes un servicio funcionando en Docker que, por razones misteriosas, se queda colgado cada ciertos días. ¿Cómo reiniciar automáticamente un contenedor Docker cuando deja de responder? Es frustrante intentar optimizar el código o la configuración y que nada funcione, pero te das cuenta de que un simple reinicio manual soluciona el problema y deja todo operativo durante una semana más. En lugar de estar pendiente del reloj, lo ideal es montar un sistema que haga este trabajo sucio por ti.

Gestionar la disponibilidad de los contenedores no solo implica que arranquen solos al encender el servidor, sino también asegurar que respondan correctamente a las peticiones. A veces el contenedor parece estar «vivo» para Docker, pero la aplicación interior no responde, lo que nos obliga a buscar soluciones que vayan desde los parámetros básicos del demonio hasta la creación de servicios complejos en el sistema operativo.

Políticas de reinicio nativas de Docker

La forma más sencilla de reiniciar automáticamente un contenedor Docker es utilizando la bandera --restart al lanzar un contenedor o mediante el comando docker update si el contenedor ya está creado. Docker ofrece varias opciones según lo que busques. Por ejemplo, la política always hará que el contenedor se reinicie siempre, sin importar si el proceso terminó con un error o si fue el propio demonio de Docker el que se reinició.

Si prefieres algo más quirúrgico, unless-stopped es la opción estrella para muchos. Esta configuración es idéntica a la anterior, salvo que, si tú detienes el contenedor a mano para hacerle un mantenimiento, Docker no intentará encenderlo automáticamente tras un reinicio del servidor, respetando tu decisión manual.

Para los que solo quieren actuar ante fallos críticos, existe on-failure. Esta política solo dispara el reinicio si el contenedor termina con un código de salida distinto de cero. Incluso puedes limitarlo añadiendo un número de reintentos máximos, evitando que el sistema entre en un bucle infinito de reinicios si el error es persistente y grave.

Automatización para contenedores «Unhealthy»

Aquí es donde la cosa se pone interesante. A veces, un contenedor sigue marcando que está «Up» (encendido), pero su estado de salud es unhealthy porque no pasa los chequeos internos. Las políticas anteriores no sirven aquí, ya que el proceso técnicamente no ha muerto. Para solucionar esto, podemos implementar la directiva HEALTHCHECK en el Dockerfile o en el archivo de Docker Compose, definiendo un comando (como un curl a un puerto específico) para verificar que la app responde.

Una vez que tenemos el chequeo de salud configurado, podemos crear un script de Bash que se ejecute cada pocos minutos mediante el crontab de Linux. Este script debe filtrar los contenedores que estén en estado unhealthy o aquellos que hayan salido con el código de error 128 y ejecutar un docker restart sobre ellos.

Para que esto funcione sin problemas y poderreiniciar automáticamente un contenedor Docker, es fundamental que el usuario que ejecuta el cron tenga los permisos necesarios en el grupo docker. De esta forma, el sistema monitoriza el entorno cada 5 o 10 minutos y levanta cualquier servicio que se haya quedado «zombie», garantizando una disponibilidad casi total sin intervención humana.

Integración avanzada con systemd

Cuando trabajas en entornos más profesionales, quizás quieras que tus contenedores se comporten como servicios nativos de Linux. Integrar Docker con systemd permite gestionar dependencias complejas, como asegurar que la base de datos arranque antes que la aplicación web. Esto se logra creando archivos .service en la ruta /etc/systemd/system/.

Podemos diseñar una secuencia de apagado y encendido controlada. Mediante scripts personalizados vinculados a systemd, es posible detener los contenedores en orden inverso a sus dependencias para evitar que se corrompan los datos. Usando el tipo oneshot y configurando los targets adecuados (como multi-user.target o shutdown.target), el servidor se encarga de todo el flujo de vida del contenedor.

Otra opción potente para reiniciar automáticamente un contenedor Docker cuando deja de responder es utilizar la bandera --rm en combinación con systemd. Esto permite que el contenedor se elimine al detenerse y se cree uno nuevo desde la imagen base al iniciar, asegurando que el estado del contenedor sea siempre limpio e inmutable, delegando la persistencia de datos únicamente a los volúmenes externos.

Herramientas externas y alternativas modernas

Si no quieres complicarte escribiendo scripts de Bash, existen herramientas de terceros. Hay aplicaciones de código abierto diseñadas específicamente para reiniciar contenedores basándose en un cronograma establecido, lo cual es muy útil para tareas recurrentes como la renovación de certificados SSL. Asimismo, herramientas como Uptime Kuma permiten monitorizar la salud de los servicios desde un panel visual y enviar notificaciones a Telegram o Gotify si algo falla. Todas son de gran ayuda para reiniciar automáticamente un contenedor Docker cuando este deja de responder.

Para quienes buscan una alternativa más ligera o nativa, Podman es una opción magnífica. Gracias a su arquitectura sin demonio y a la funcionalidad de Quadlet, permite crear archivos declarativos simples que systemd convierte automáticamente en servicios optimizados, ofreciendo una integración mucho más orgánica que la de Docker tradicional.

Tener un control total sobre el ciclo de vida de tus servicios implica combinar el uso de políticas de reinicio, la vigilancia constante mediante healthchecks y, en casos más complejos, el apoyo de systemd o herramientas de monitorización para que tu infraestructura sea robusta y no dependa de que alguien se acuerde de reiniciar el servidor manualmente cada semana.