- La configuración de políticas de reinicio como unless-stopped es vital para garantizar que los servicios vuelvan a estar activos tras un reinicio del sistema.
- La implementación de unidades de systemd resuelve conflictos de orden de arranque cuando existen dependencias de montajes de disco o redes externas.
- La actualización de contenedores mediante docker compose up -d es obligatoria para que los cambios en el archivo YAML surtan efecto en el motor de Docker.
Si te has topado con que tus servicios de Docker no arrancan automáticamente tras reiniciar el servidor, no te desesperes, que es un problema más común de lo que parece. A veces parece que el archivo de configuración está perfecto, pero al volver a conectar con la máquina te encuentras con que los contenedores se han quedado dormidos y no hay señales de vida en tus aplicaciones.
Para solucionar esto, hay que entender que no basta con escribir un par de líneas en un YAML; entra en juego la interacción entre el daemon de Docker, el sistema de gestión de servicios de Linux y la forma en que se almacenan las configuraciones. Vamos a desgranar paso a paso todas las causas posibles y cómo dejarlos niquelados para que no vuelvan a fallar.
El secreto de las políticas de reinicio en Compose
Para que un stack se levante solo, deben coincidir dos cosas: que el servicio de Docker esté habilitado en el sistema y que cada servicio tenga una política de reinicio adecuada. No existe un ajuste global para todo el archivo, así que hay que añadir la línea restart: unless-stopped o always a cada uno de los servicios definidos.
Aquí es donde mucha gente mete la pata: editar el archivo compose.yaml no cambia la configuración de un contenedor que ya está creado. La política de reinicio se graba en el objeto del contenedor, no se lee en tiempo real del archivo. Por eso, si solo cambias el texto y reinicias, no pasará nada. Tienes que ejecutar docker compose up -d para que Docker detecte el cambio, destruya el contenedor viejo y cree uno nuevo con la política correcta.
Diferencias reales entre los valores de restart
No todos los valores de reinicio sirven para lo mismo y elegir el equivocado puede darte dolores de cabeza. Aquí tienes el desglose real:
- no: Es el valor por defecto. El contenedor no se reiniciará jamás por su cuenta.
- always: Reinicia el contenedor siempre. Incluso si lo detuviste tú a mano hace una semana, en cuanto el daemon de Docker arranque, el contenedor volverá a encenderse. Puede ser un poco molesto si querías dejar algo apagado a propósito.
- unless-stopped: Es la opción más equilibrada. Se comporta como always, pero con una diferencia clave: si detuviste el contenedor manualmente, respetará tu decisión y se quedará apagado tras el reinicio del sistema.
- on-failure: Solo actúa si el contenedor falla (código de salida distinto de cero). Ojo aquí, porque un apagado normal del servidor no se considera un error, por lo que no sobrevivirá a un reinicio del host.
Cuando el daemon de Docker no es suficiente
A veces, aunque tengas el restart: unless-stopped, el stack falla. Esto suele pasar porque el daemon de Docker arranca antes que otros componentes críticos. Si tu pila depende de un disco cifrado, una carpeta compartida por NFS o una interfaz VPN que tarda en conectar, Docker podría intentar levantar el contenedor, no encontrar la ruta y crear una carpeta vacía, dejando tu base de datos sin datos.
En estos casos, la solución profesional es crear una unidad de systemd. Esto te permite decirle al sistema: «No arranques este stack hasta que el disco X esté montado». Para ello, se crea un archivo en /etc/systemd/system/ configurado como Type=oneshot y RemainAfterExit=yes. Es fundamental usar la directiva RequiresMountsFor= para asegurar que el almacenamiento esté disponible y After=docker.service para respetar el orden lógico.
Consideraciones técnicas y errores silenciosos
Hay detalles que pueden sabotear tu configuración sin avisar. Por ejemplo, si lanzas un contenedor usando docker compose run, este se trata como algo temporal y no heredará la política de reinicio del archivo YAML. Si notas que un servicio ignora las reglas, revisa cómo lo iniciaste.
Otro punto crítico es el Rootless Docker. Si ejecutas Docker sin privilegios de root, el daemon es un servicio de usuario que se cierra cuando cierras sesión. Para evitar que tus contenedores mueran al desconectarte, debes ejecutar loginctl enable-linger usuario, permitiendo que el proceso siga vivo en segundo plano.
Gestión avanzada y herramientas modernas
Hablemos de la evolución de las herramientas. Actualmente, el estándar es Docker Compose V5 (invocado como docker compose, sin guion), que ha sustituido al antiguo binario de Python. Para los que gestionan infraestructuras más grandes, existe Docker Swarm, que permite convertir varios hosts en un clúster gestionado centralmente mediante nodos maestros y esclavos.
En Swarm, la orquestación es más potente, permitiendo servicios replicados (para escalar instancias de un servidor web, por ejemplo) o servicios globales (para que cada nodo del clúster tenga una copia del contenedor, ideal para antivirus o monitoreo). Mientras que Compose es genial para un solo servidor, Swarm es la respuesta cuando necesitas alta disponibilidad y balanceo de carga nativo.
Mantenimiento y flujo de trabajo diario
Para mantener todo bajo control, es vital dominar los comandos de diagnóstico. El uso de docker compose ps nos da una foto rápida del estado, pero monitorizar los logs de Docker con Dozzle es donde ocurre la magia para encontrar errores de arranque. Si necesitas hacer un cambio rápido sin destruir el contenedor, docker compose exec es la vía más directa para entrar en la terminal del servicio y revisar archivos de configuración internos.
Es recomendable evitar la mezcla de gestores de procesos si no se sabe lo que se hace, aunque una unidad de systemd tipo oneshot convive perfectamente con las políticas de reinicio de Docker. De hecho, es el combo ganador: systemd se encarga de que el orden de arranque sea el correcto y el daemon de Docker se encarga de reiniciar el contenedor si este peta a las tres de la mañana.
La estabilidad de un entorno de contenedores depende de una configuración coherente entre la política de reinicio del archivo YAML, la correcta activación del servicio de Docker en el sistema y, en casos complejos, el uso de unidades de systemd para gestionar dependencias externas. Al combinar unless-stopped con una ejecución de docker compose up -d y asegurar la persistencia del usuario en modo rootless, se garantiza que las aplicaciones permanezcan operativas sin intervención manual tras cualquier reinicio del servidor.
Apasionado de la tecnología desde pequeñito. Me encanta estar a la última en el sector y sobre todo, comunicarlo. Por eso me dedico a la comunicación en webs de tecnología y videojuegos desde hace ya muchos años. Podrás encontrarme escribiendo sobre Android, Windows, MacOS, iOS, Nintendo o cualquier otro tema relacionado que se te pase por la cabeza.