Cómo adaptar las políticas de reinicio de Docker a bases de datos, trabajadores y aplicaciones web
Adapta las políticas de reinicio de Docker al ciclo de vida del servicio y a la semántica de salida, en lugar de asignar unless-stopped a todos los contenedores de un archivo Compose.
Las políticas de reinicio reaccionan cuando finaliza el proceso principal de un contenedor; una comprobación de estado puede marcar como no saludable un proceso que sigue ejecutándose sin reiniciarlo automáticamente. Por ello, las bases de datos, los workers, las aplicaciones web, las migraciones y las tareas programadas necesitan opciones diferentes según si deben mantenerse activas, qué significa una salida correcta y cómo debe notificarse un fallo repetido.
Separa el comportamiento de reinicio del estado y la disponibilidad
Una política de reinicio indica si Docker debe volver a iniciar un contenedor después de que su proceso se detenga. Una comprobación de estado indica si el servicio en ejecución puede realizar una operación definida. La disponibilidad de las dependencias indica si otro servicio debe iniciarse todavía. Resuelven problemas relacionados, pero diferentes.
Un artículo de 2026 sobre estado y reinicio por separado explica esta separación y muestra cómo las condiciones de estado de Compose pueden retrasar el inicio de las dependencias hasta que un servicio esté realmente disponible.
No esperes que restart: always repare un proceso web no saludable que nunca finaliza, ni que una comprobación de estado por sí sola lo reinicie. Haz que la aplicación finalice cuando continuar no sea seguro, añade un mecanismo externo de corrección o alerta sobre el estado no saludable según el diseño del servicio.
Usa políticas de reinicio persistentes para bases de datos de larga duración
Normalmente se espera que una base de datos de un servidor doméstico vuelva a estar disponible después de reiniciar el equipo anfitrión o el demonio de Docker. unless-stopped suele ser un valor predeterminado práctico cuando se debe respetar una detención administrativa intencionada; always es apropiado cuando, por diseño, el reinicio debe prevalecer sobre ese estado de detención manual.
Un artículo de julio de 2026 sobre cómo las políticas de reinicio siguen la salida del proceso detalla las diferencias entre no, on-failure, always y unless-stopped, incluido el hecho de que la política reacciona a la salida del proceso y no al estado de salud.
La base de datos también necesita una comprobación de estado real y almacenamiento persistente. Reiniciar PostgreSQL repetidamente no puede solucionar un disco lleno, una configuración inválida, un estado dañado o una migración incompatible. Alerta sobre los reinicios repetidos en lugar de tratarlos como una resiliencia exitosa.
Elige la política del worker según la cola y la semántica de salida
Un worker de cola de larga duración puede requerir unless-stopped si debe consumir trabajo continuamente. Un worker finito o un proceso por lotes puede usar on-failure:N para que los errores transitorios reciban reintentos limitados, mientras que un fallo persistente se detenga de forma visible.
Un artículo actual sobre reintentos limitados con on-failure destaca que el comportamiento de los reintentos debe coincidir con si se espera que un proceso permanezca activo permanentemente o pueda finalizar con normalidad.
Debes saber qué significa el código de salida 0 para la imagen del worker. Si significa «trabajo completado», always puede convertir un trabajo de una sola ejecución completado correctamente en un bucle infinito. Si el worker debe funcionar como un demonio, una salida limpia inesperada aún puede justificar un reinicio automático mediante unless-stopped.
Mantén las aplicaciones web activas, pero supedítalas a dependencias reales
La mayoría de las aplicaciones web autoalojadas están diseñadas para permanecer disponibles continuamente, por lo que unless-stopped suele ser más fácil de comprender que una política limitada solo a fallos. La configuración de reinicio no elimina la necesidad de que la base de datos, la caché, el DNS, los secretos y las rutas montadas estén disponibles.
El diagnóstico relacionado de ZimaSpace sobre los bucles de reinicio causados por dependencias del contenedor muestra por qué reiniciar repetidamente la aplicación visible puede ocultar el fallo de la base de datos, la caché, el montaje, la migración o la memoria que ocurrió primero.
Usa comprobaciones de estado de las dependencias para ordenar el inicio cuando corresponda y limita los reintentos de la aplicación. Un servicio web que se bloquea cada cinco segundos hasta que PostgreSQL se inicia es menos observable que uno que espera a que esté disponible y produce un único inicio limpio.
Asigna un ciclo de vida finito a las migraciones y los trabajos de una sola ejecución
Los contenedores de migración, los importadores, las tareas de mantenimiento y los trabajos de inicialización únicos no son demonios comunes. Su estado correcto suele ser «salir con el código 0 y permanecer detenidos». Usar always o unless-stopped puede volver a ejecutar accidentalmente el trabajo completado.
Mantén explícitas las herramientas operativas de una sola ejecución en lugar de permitir que se conviertan en servicios ocultos siempre activos. Una migración o un importador debe tener un estado de éxito finito que permanezca visible después de que finalice el comando.
Usa restart: "no" cuando un fallo deba detener el proceso para su inspección, o on-failure limitado solo cuando sea seguro volver a ejecutar el comando. En las migraciones de esquema, comprueba primero que repetir una migración aplicada parcialmente sea compatible antes de automatizar los reintentos.
Prueba la política con fallos reales
Para cada servicio, prueba una salida limpia del proceso, un bloqueo con código distinto de cero, el reinicio del equipo anfitrión, el reinicio del demonio de Docker, una detención manual, una condición no saludable con el proceso en ejecución y una dependencia no disponible. Registra el estado esperado después de cada evento antes de considerar resiliente la configuración.
Supervisa el número de reinicios y alerta cuando supere un umbral pequeño dentro de un intervalo de tiempo. El reinicio automático debe reducir el tiempo de recuperación ante fallos transitorios; no debe hacer invisible un bloqueo persistente al producir un flujo interminable de contenedores nuevos.
Una buena matriz de políticas es explícita: las bases de datos y las aplicaciones web de larga duración vuelven a iniciarse tras los reinicios de la infraestructura, los workers demonio se recuperan según la semántica de la cola, los trabajos finitos se detienen al completarse y las comprobaciones de estado y disponibilidad exponen los fallos que la política de reinicio no puede detectar.
Productos recomendados
Soporte y Consejos
Más para leer
Cómo configurar los identificadores de usuario de los contenedores en varios recursos compartidos de NAS
Asigna el UID/GID de cada contenedor a sus recursos compartidos del NAS, usa grupos compartidos o ACL cuando sea necesario y considera PUID/PGID específicos...
Cómo configurar perfiles de Docker Compose para servicios opcionales del servidor doméstico
Deja los servicios necesarios sin perfil y usa perfiles para las herramientas opcionales. Prueba los objetivos directos y las dependencias en lugar de asumir...
Cómo optimizar las exclusiones de sincronización en la nube para los metadatos de aplicaciones NAS
Clasifica los metadatos de las aplicaciones NAS según su función de restauración. Excluye las cachés y los estados temporales, protege deliberadamente la configuración portátil...
