← Proyectos
Fiabilidad · Infraestructura

Si el despliegue falla,
el sistema vuelve solo

El reto: la firma Cosign garantiza el origen de una imagen, no que funcione. Una imagen firmada pero defectuosa supera el gate, se despliega, y la web cae. El sistema debe darse cuenta y revertir sin intervención a la última versión sana conocida.

El flujo, cuando algo sale mal
cosign verify gate de firma docker up nueva imagen health-check 3 reintentos ok deploy_ok en producción CAMINO FELIZ ROLLBACK falla 3× digest previo del registro redespliegue y nueva verificación rollback_ok web restaurada history.jsonl registro append-only

Cada desenlace —despliegue correcto, firma rechazada, error, rollback— queda anotado como un evento JSON en un registro que solo crece. Si el propio rollback fallara, el sistema lo registra y reclama intervención manual: es el único caso en que no hay más a qué volver.

Las decisiones, y su porqué
01
Reintentos antes de sentenciar
ProblemaUn health-check único no distingue un contenedor roto de uno que simplemente aún está arrancando.
AlternativasAlargar la espera fija penaliza todos los despliegues, también los sanos. Un único intento genera falsos positivos y rollbacks innecesarios.
DecisiónTres reintentos separados por dos segundos. Solo si los tres fallan se declara el despliegue fallido. Los parámetros son variables explícitas del script: se ajustan sin tocar la lógica.
02
El último digest bueno se deriva, no se guarda
ProblemaPara revertir hay que saber a qué versión volver, y esa información debe ser fiable precisamente en el momento en que algo acaba de fallar.
AlternativasUn fichero de estado con el "último digest bueno" es la vía obvia, pero puede desincronizarse del historial real: basta con que un despliegue lo actualice y falle después.
DecisiónNo existe fichero de estado. El digest se deriva del registro de despliegues: la última línea deploy_ok o rollback_ok es, por definición, la última versión que superó un health-check. Una única fuente de verdad, imposible de desincronizar.
03
Quien despliega, revierte
ProblemaDetectado el fallo, ¿qué pieza del sistema ejecuta la reversión?
AlternativasUn watchdog externo o las políticas de reinicio de Docker relanzan el contenedor, pero relanzan la misma imagen rota: reinician, no revierten.
DecisiónEl propio script de despliegue hace el rollback: captura el digest bueno antes de tocar nada y, si el health-check falla, lo restaura y vuelve a verificar. Sin demonios nuevos ni piezas extra: un solo flujo, auditable de principio a fin.
04
Eventos estructurados antes de tener quien los lea
ProblemaNadie es avisado hoy de un despliegue, un rechazo de firma o un rollback: es el punto ciego operativo de la plataforma.
AlternativasAcoplar el envío de alertas al script resolvería el aviso, pero cada cambio de canal obligaría a modificar la pieza más crítica del sistema.
DecisiónEl script solo emite hechos: eventos JSON en un registro append-only (history.jsonl), con ambos digests en cada rollback. La futura capa de notificación los leerá sin que el despliegue cambie una sola línea. Primero los datos; el canal, después.
El resultado

La validación fue una prueba real sobre producción: una imagen firmada pero sin servidor HTTP superó el gate y se desplegó. El health-check falló tres veces, el sistema recuperó el digest anterior del registro, lo redesplegó y verificó la web de nuevo — en segundos y sin intervención. El evento registró ambos digests: el que falló y el que restauró el servicio.

BashDockerCosignsystemdGHCRJSONLNginx
Connect → Automate → Augment → Deploy.
Firmar no basta: hay que verificar que funciona y saber volver.