Comprobaciones de salud

Una comprobación de salud le dice a Zenavo cuándo una instancia está lista para recibir tráfico. Un despliegue arranca la instancia nueva junto a la anterior y solo cambia el tráfico cuando la nueva la supera, y eso es lo que hace que los despliegues no tengan tiempo de inactividad.

Elige la comprobación en Service → Settings → Health Check:

• Port (por defecto): Zenavo comprueba que el primer puerto TCP o HTTP del servicio acepta conexiones, cada 10 segundos, con 5 segundos de tiempo máximo y 3 fallos permitidos. Los servicios sin un puerto así no tienen comprobación y cuentan como listos en cuanto arrancan.
• HTTP: Zenavo pide una ruta, como /healthz, en el primer puerto TCP o HTTP del servicio o en el puerto que indiques. Cualquier respuesta 2xx o 3xx significa listo. La petición sale del clúster, así que la imagen no necesita curl ni wget. Es la mejor opción para aplicaciones web.
• Command: un comando que se ejecuta dentro del contenedor, como pg_isready -U postgres; el código de salida 0 significa listo. Se ejecuta sin shell, así que para &&, | o $VARIABLES escribe sh -c "…". Las bases de datos añadidas desde la consola y muchas plantillas incluyen una.

Las comprobaciones HTTP y de comando tienen tiempos ajustables: el intervalo entre comprobaciones, el tiempo máximo de cada una, los fallos permitidos antes de que la instancia cuente como no sana (6 por defecto) y el periodo de arranque que se espera tras iniciar el contenedor (10 segundos por defecto). Aumenta el periodo de arranque en aplicaciones que tardan en arrancar, como las de Java o las que ejecutan migraciones al arrancar.

En un manifiesto:

"healthcheck": { "http": { "path": "/healthz" }, "interval": 10, "timeout": 5, "retries": 6, "start_period": 10 }

o "command": ["pg_isready", "-U", "postgres"] en lugar de "http".

Cuando falla una comprobación

• Durante un despliegue: si la instancia nueva no deja de fallar, el despliegue falla en cuanto queda claro, con el motivo de la última comprobación (por ejemplo HTTP probe failed with statuscode: 404) y los registros más recientes de la instancia. La instancia anterior sigue atendiendo.
• Después de un despliegue: una instancia que deja de superarla no recibe tráfico, y el servicio aparece como Unhealthy. Zenavo no la reinicia por fallar la comprobación; revisa sus registros y luego vuelve a desplegar o reiníciala.

Límite de fallos

Si un servicio no deja de caerse, Zenavo puede suspenderlo tras un número de reinicios (su límite de fallos) en lugar de reiniciarlo para siempre. El servicio muestra entonces un aviso; revisa sus registros y luego reanúdalo o despliega una corrección.