Cómo identificar qué dependencia del contenedor está causando un bucle de reinicios
Identifica la primera dependencia que deja de estar disponible antes de que la aplicación se cierre, en lugar de tratar cada contenedor que se reinicia como la causa principal.
En una pila de Docker Compose, la aplicación visible puede entrar en un bucle porque una base de datos aún está iniciándose, Redis no es accesible, el DNS devuelve el servicio equivocado, falta un montaje bind, ha cambiado un secreto, ha fallado una migración o la aplicación se cierra por presión de memoria. El diagnóstico más rápido captura el primer cierre y el error de dependencia, pausa los reinicios automáticos y luego prueba cada servicio necesario desde la misma red y con las mismas credenciales que usa el contenedor que falla.
Encuentra el primer contenedor que falla, no el más llamativo
Enumera los recuentos de reinicios, el estado actual, el estado de salud, el último código de salida y la hora de inicio de cada servicio de la pila. Ordena la cronología para que el fallo más temprano aparezca antes de que los contenedores secundarios comiencen a reconectarse o reiniciarse.
La guía de Netdata sobre bucles de reinicio muestra cómo los códigos de salida y los estados permiten distinguir entre cierres por falta de memoria, fallos de segmentación, terminaciones correctas y paradas relacionadas con el estado de salud. Una señal OOMKilled o del código de salida puede descartar la investigación de dependencias cuando en realidad la aplicación se está quedando sin memoria o falla internamente.
Si una dependencia falla primero, investígala antes que la aplicación. Si la aplicación se cierra primero con errores de conexión rechazada, tiempo de espera agotado, autenticación o archivo faltante, relaciona ese mensaje con la dependencia exacta que intentó utilizar.
Pausa la tormenta de reinicios y captura un fallo limpio
Desactiva temporalmente o sobrescribe la política de reinicio del servicio afectado y ejecútalo una vez en primer plano, o inspecciona sus registros completos a partir de un único intento de inicio. Conserva las marcas de tiempo del demonio de Docker y de cada dependencia.
Los reinicios automáticos repetidos pueden sobrescribir el primer error importante con fallos de conexión posteriores. Un contenedor que se reinicia cada pocos segundos también puede sobrecargar su base de datos, resolvedor DNS o volumen de registros y crear síntomas secundarios.
No elimines contenedores, volúmenes ni bases de datos durante esta captura. Detén únicamente la tormenta de reinicios, reproduce el fallo una vez y guarda el entorno, los montajes, las conexiones de red, el comando y el estado de salida antes de cambiar la configuración.
Mapea todas las dependencias que el contenedor necesita para estar listo
Anota la base de datos, caché, cola de mensajes, almacenamiento de objetos, resolvedor DNS, proveedor de identidad, archivos montados, secretos y API externas que necesita la aplicación. Incluye el nombre de servicio esperado, el puerto, el protocolo, el nombre de usuario, la base de datos y la ruta.
Dash0 explica que el orden de inicio de Compose no significa automáticamente que el proceso dentro de una dependencia esté listo; una aplicación puede iniciarse mientras Postgres aún se está inicializando. La solución es esperar al estado saludable de una dependencia, en lugar de limitarse a esperar que esté en ejecución.
Clasifica las dependencias como obligatorias u opcionales. La ausencia de un servicio de métricas opcional no debería reiniciar la aplicación principal, mientras que una base de datos no disponible puede requerir una espera, un reintento o una detención controlados.
Prueba cada dependencia desde la red del contenedor que falla
Utiliza un contenedor de diagnóstico temporal conectado a la misma red o ejecuta un shell compatible antes de que la aplicación se cierre. Prueba, en este orden, el DNS del nombre del servicio, el puerto TCP, TLS, la autenticación, una consulta a la base de datos y la ruta necesaria.
La guía de Last9 sobre comprobaciones de estado en Compose señala que las comprobaciones de disponibilidad impiden que los servicios dependientes se inicien hasta que los componentes críticos puedan responder realmente. Una comprobación útil valida la operación del servicio que necesitan los clientes, en lugar de confirmar únicamente que existe un proceso.
Si falla el DNS, inspecciona la pertenencia a la red y los alias. Si se abre la conexión TCP, pero falla la autenticación, compara los secretos y los usuarios. Si el inicio de sesión funciona, pero faltan el esquema, el bucket, la cola o el directorio esperados, corrige la inicialización en lugar de la red.
Comprueba los montajes, los secretos y las migraciones como dependencias
Compara los montajes bind actuales, los volúmenes con nombre, los permisos, la propiedad, los archivos de entorno, los archivos de secretos y la versión de la aplicación con la última implementación que funcionaba. Un contenedor puede acceder a su base de datos y aun así reiniciarse porque un archivo de configuración es de solo lectura o porque una migración no puede escribir.
Un caso práctico sobre el inicio de contenedores muestra que el orden de dependencias basado en el estado de salud puede impedir que una aplicación falle antes de que su base de datos esté lista. La secuencia de inicio condicional adquiere especial importancia durante el primer arranque y las migraciones.
Ejecuta las migraciones una vez con los registros visibles y haz una copia de seguridad de la base de datos antes de repetir pasos destructivos. Si ha cambiado la versión de la aplicación, verifica que la versión de la dependencia y la ruta de actualización del esquema sean compatibles.
Vuelve a habilitar los servicios en orden de dependencia y valida la estabilidad
Inicia primero la dependencia de nivel más bajo, espera a que su comprobación de estado real sea correcta, inicia después la siguiente capa y finalmente la aplicación. Registra los recuentos de reinicios y las transiciones de estado de salud durante varios intervalos de comprobación.
La guía de ZimaSpace sobre fallos de DNS dentro de los contenedores aborda una ruta de dependencia que puede manifestarse únicamente dentro del entorno de la aplicación.
El problema solo está resuelto cuando la aplicación se inicia una vez, todas las dependencias obligatorias permanecen saludables, las migraciones finalizan y un reinicio deliberado de una dependencia activa un reintento o una recuperación controlados en lugar de provocar otro bucle. Restablece la política de reinicio únicamente después de que el fallo raíz sea observable y esté acotado.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
