Contenedores que quedan renombrados y el monitor los da por caídos
El monitoreo avisó que un servicio estaba caído. Estaba corriendo perfecto, con un nombre temporal que le quedó de un recreado interrumpido. Por qué el chequeo por nombre exacto miente y qué mirar en su lugar.
Llega la alerta: un servicio caído. Se entra al servidor, se listan los contenedores, y el servicio está ahí, funcionando, respondiendo. Pero con un nombre raro: un prefijo hexadecimal antes del nombre esperado.
El recreado del despliegue anterior se interrumpió a mitad de camino. El contenedor viejo quedó renombrado y el nuevo nunca se creó.
Qué pasa durante un recreado
La secuencia normal
- El contenedor existente se renombra con un prefijo temporal, para liberar el nombre.
- Se crea el contenedor nuevo con el nombre definitivo.
- Se detiene y se elimina el viejo.
Si el paso 2 falla —imagen que no existe, puerto ocupado, memoria insuficiente, disco lleno—, el proceso se corta y queda el contenedor viejo con nombre temporal. Sigue corriendo y sigue sirviendo: desde el punto de vista del usuario no pasó nada. Desde el punto de vista del monitoreo, el nombre que buscaba no existe.
Por qué el chequeo por nombre miente en los dos sentidos
| Situación | Chequeo por nombre | La realidad |
|---|---|---|
| Contenedor renombrado por recreado a medias | Dice caído | Está sirviendo |
| Contenedor arriba pero la aplicación colgada | Dice bien | No responde a nadie |
| Contenedor reiniciándose en ciclo | Dice bien si justo lo agarra arriba | Cae cada pocos segundos |
La conclusión es la que se repite en todo monitoreo: medir lo que el usuario experimenta. Una petición real a la aplicación cubre las tres filas de la tabla; la existencia de un proceso, ninguna.
Cómo se arregla el contenedor y cómo el chequeo
Lo inmediato
- Forzar el recreado de ese servicio, sin reconstruir, para que se cree con su nombre y el viejo se elimine.
- Averiguar por qué falló la creación antes de repetir el despliegue: si fue memoria o disco, va a volver a pasar en el próximo servicio.
Lo que cambió en el monitoreo
- Chequeo por respuesta, no por nombre: una petición a la ruta de salud de cada servicio.
- Chequeos de salud declarados en la definición de cada contenedor, para que el estado refleje si la aplicación está lista y no sólo si el proceso arrancó.
- Detectar contenedores con nombre temporal como una condición propia, distinta de “caído”: es el rastro de un despliegue que falló y conviene verlo como tal.
- Alerta con contexto: qué servicio, desde cuándo y qué devuelve, en vez de un aviso genérico.
Antes de seguir, predecí
Que el despliegue no termine en silencio
El otro lado del problema es que el despliegue fallido no avisó. El comando devolvió un error que nadie leyó, y la alerta llegó mucho después por otra vía.
Tres hábitos que lo evitan
- Verificar después de desplegar, no al desplegar: que todos los servicios esperados estén arriba, con su nombre, y respondiendo.
- Que el script falle fuerte. Si un paso falla, que se detenga y lo diga, en vez de seguir con los siguientes.
- Espacio y memoria antes de empezar. Las dos causas más frecuentes de creación fallida son disco lleno y memoria insuficiente, y las dos se pueden chequear en un segundo.
Más a fondo · nivel seniorEl recreado no es atómico y no puede serlo
Entre que el contenedor viejo se detiene y el nuevo atiende, hay un intervalo. En un servidor chico eso es un corte de unos segundos, aceptable para la mayoría de las aplicaciones. Si no lo es, la solución no es un recreado más rápido sino levantar la versión nueva antes de bajar la vieja y mover el tráfico cuando la nueva esté lista, que es lo que hace un despliegue azul-verde. Tiene un costo: durante la transición conviven las dos versiones, y por eso las migraciones tienen que ser compatibles hacia atrás.
El recreado interrumpido en el log
Buscá en el log
La alerta dice que el servicio está caído y el contenedor está ahí, respondiendo. ¿Qué línea explica las dos cosas a la vez?
debug 2info 5warn 1error 311 de 11
El motor renombró el contenedor viejo con un prefijo hexadecimal —ese es el primer paso del recreado— y ahí se cortó. El contenedor sigue corriendo y sirviendo, por eso responde; pero ya no se llama como espera el chequeo, por eso la alerta dice que está caído. Las dos cosas son ciertas. Y lo peligroso es que un despliegue interrumpido así no deja ningún error: termina, con código distinto de cero que nadie miró, y el sistema queda en un estado que ningún archivo de configuración describe.
Que el despliegue no termine en silencio
Cierre
Autoevaluación
¿Lo entendiste?
Práctica