¿Por qué falla la comprobación de estado de un contenedor mientras la aplicación sigue abriéndose?
Un contenedor puede seguir siendo utilizable aunque falle su comprobación de estado, porque la sonda prueba un comando, una dirección, un usuario o una condición de disponibilidad diferentes de los que utiliza el navegador.
En un servidor doméstico, la aplicación puede abrirse a través de un proxy inverso aunque Docker ejecute el comando de comprobación dentro del contenedor contra localhost, una utilidad ausente, el puerto incorrecto o una dependencia temporalmente no disponible. Empieza reproduciendo la sonda exacta dentro del contenedor y, después, compara su destino y resultado esperado con la ruta real del usuario antes de aumentar los reintentos o desactivar la comprobación de estado.
Compara lo que prueba el navegador con lo que prueba la comprobación de estado
Registra la URL y la ruta de red que abren correctamente la aplicación. Observa si el navegador llega a un proxy inverso, a un puerto del host publicado, a una IP local o directamente al contenedor.
Docker ejecuta la sonda configurada dentro del contenedor, por lo que puede probar un endpoint diferente del navegador. Un caso de la comunidad de Docker mostró que una comprobación de estado fallaba porque la imagen no contenía el comando curl utilizado por la sonda, aunque el proceso del servicio podía seguir ejecutándose.
Si la ruta correcta del navegador pasa por otro proxy o puerto, no consideres ese resultado una prueba de que el destino de la sonda interna sea correcto. Anota ambas rutas e identifica el primer componente que difiere.
Ejecuta el comando exacto de comprobación dentro del contenedor
Copia exactamente el comando de la comprobación de estado, incluida su forma de shell, URL, opciones, credenciales y variables de entorno. Ejecútalo dentro del contenedor en ejecución con el mismo usuario y captura el código de salida y la salida del comando.
Un contenedor marcado como no saludable puede seguir teniendo un proceso en ejecución, porque el estado de salud refleja el resultado de la sonda, no si los usuarios pueden cargar una página. El flujo de diagnóstico de Netdata distingue el fallo de la sonda del fallo del proceso antes de cambiar el comportamiento de reinicio.
Si el comando se ejecuta correctamente de forma manual, compara el usuario de ejecución, el shell, el directorio de trabajo, el entorno y los tiempos utilizados por la comprobación automática. Si falla manualmente, el error identifica ahora la siguiente capa sin tener que esperar otro intervalo de comprobación.
Comprueba la herramienta de la sonda, el shell, PATH y el usuario
Confirma que todos los ejecutables del comando de estado existan dentro de la imagen actual y que el usuario del contenedor pueda ejecutarlos. Las imágenes mínimas pueden omitir curl, wget, bash, las herramientas DNS o los almacenes de certificados.
Las sondas en forma de shell y en forma exec se comportan de manera diferente. Las comillas, tuberías, expansiones de variables y comandos compuestos requieren un shell disponible, mientras que un comando directo necesita la ruta completa del ejecutable cuando el entorno de la comprobación tiene un PATH limitado.
Ejecuta el comando con una ruta absoluta y con el usuario de servicio previsto. Corrige la imagen o la sonda en lugar de instalar herramientas de forma interactiva, porque un cambio manual en el contenedor desaparece tras la siguiente reconstrucción.
Verifica la dirección interna, el puerto y el protocolo
Inspecciona el servicio de escucha de la aplicación dentro del contenedor y compáralo con la URL de la sonda. Un puerto del host publicado como 8080:80 no significa que el servicio escuche en el puerto 8080 dentro del contenedor.
Las comprobaciones de estado deben probar el estado de la aplicación que controla el contenedor. La guía práctica de Dash0 señala que una sonda puede llamar a un endpoint HTTP o inspeccionar un proceso, pero el endpoint debe reflejar el estado real de disponibilidad del contenedor, en lugar de una ruta disponible únicamente a través de un proxy externo.
Prueba 127.0.0.1, la dirección de escucha del contenedor y el nombre del servicio solo cuando corresponda. Si la aplicación se vincula únicamente a un socket Unix o a otra interfaz, cambia la sonda para que utilice el punto de entrada interno real.
Distingue un inicio lento de un fallo permanente
Mide cuánto tardan la aplicación, la migración de la base de datos, el calentamiento de la caché o la carga del modelo en responder en el endpoint correcto. Compara ese tiempo con start_period, interval, timeout y retries.
Compose puede bloquear los servicios dependientes cuando una dependencia todavía aparece como no saludable, aunque después llegue a estar lista. Una regresión reportada en Compose mostró que un servicio se volvía saludable solo después de que el fallo de la dependencia ya hubiera detenido la pila, dejando al descubierto una ventana de inicio de la comprobación de estado demasiado estrecha.
Aumenta los tiempos únicamente cuando los registros demuestren que la aplicación avanza con normalidad. Un mayor número de reintentos no debe ocultar un puerto incorrecto, una migración fallida, un certificado ausente o una base de datos inalcanzable.
Mantén la sonda acotada y verifica la recuperación
Decide si la comprobación de estado debe representar la disponibilidad del proceso, la disponibilidad de la aplicación local o una cadena de dependencias más profunda. No marques como no saludable un contenedor local solo porque una API externa opcional no esté disponible.
La guía de ZimaSpace para encontrar la primera dependencia fallida es el siguiente paso cuando la aplicación no puede estar lista sin una base de datos, una caché o un servicio de red.
El problema se resuelve cuando la sonda automática exacta se ejecuta correctamente después del inicio normal, el contenedor permanece saludable durante los reinicios de las dependencias y el flujo de trabajo real de la aplicación sigue disponible. Mantén la sonda lo bastante estricta para detectar un servicio averiado, pero lo bastante acotada para evitar falsos fallos causados por sistemas no relacionados.
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...
