.jpg)
Introducción Zero-downtime o despliegues sin tiempo de inactividad es una expectativa imprescindible para servicios modernos. Como responsable DevOps sabes la sensación de emergencia cuando una nueva versión deja la web inaccesible por unos segundos. En esta guía práctica describimos un patrón blue-green centrado en Docker y con Nginx como proxy inverso que mantiene a los usuarios ajenos a cualquier cambio.
Resumen del enfoque La idea central es sencilla Cuando conviven dos entornos idénticos blue entorno en producción y green la próxima versión Nginx enruta el tráfico al entorno activo y un trabajo de CI invierte el upstream una vez que los contenedores green superan las comprobaciones de salud.
Requisitos previos Un host compatible con Docker (VM Linux, instancia AWS EC2 o máquina local). Nginx instalado como proxy inverso en el mismo host o en un bastión separado. Repositorio Git en GitHub GitLab o Bitbucket. Familiaridad básica con Dockerfiles docker compose y una plataforma CI como GitHub Actions GitLab CI o CircleCI. Recomendación mantener Docker Engine en la versión 20.10 y Nginx en 1.21 para compatibilidad con los ejemplos.
Versionado de imágenes Docker Cada commit que modifique el Dockerfile debe producir una etiqueta semántica por ejemplo v1.2.3. Inyecta la SHA de Git usando etiquetas en la imagen para que las reversión sean trazables. En el pipeline CI exporta variables como GIT_TAG y GIT_SHA y etiquetado para poder ejecutar yourapp:1.4.0 en green y conservar yourapp:1.3.9 en blue.
Configuración de proxy con Nginx Concepto clave definir dos upstreams blue y green y variable de selección. Ejemplo mínimo descriptivo upstream blue servidor 127.0.0.1 puerto 3001 upstream green servidor 127.0.0.1 puerto 3002 usar la directiva map para asignar la variable $upstream por defecto blue y permitir que el CI altere ese valor a green cuando sea seguro reenviar tráfico. Al completar la implantación el job de CI actualiza la variable o la cabecera X-Deploy-Target y hace un nginx -s reload. Para revertir basta con volver a blue.
Pipeline CI CD Flujo recomendado con GitHub Actions pero aplicable a otras plataformas. Fases build y deploy. El job de build genera metadata etiquetas semver y SHA y publica la imagen en el registro. El job de deploy SSH al host extrae la imagen docker pull yourorg/yourapp GIT_TAG ejecuta la nueva instancia en puerto 3002 realiza un bucle de health check con curl a http localhost 3002 health hasta que responda 200 luego modifica el bloque map en la configuración de Nginx para cambiar default blue por default green y recarga Nginx. Mantén un periodo de gracia con la antigua instancia ejecutándose para permitir rollback manual fácil; finalmente puedes parar y renombrar contenedores para preparar el siguiente ciclo.
Comprobaciones de salud y conmutación La aplicación debe exponer un endpoint ligero /health que devuelva 200 solo cuando todas las dependencias internas base de datos caché APIs externas estén disponibles. Un bucle de predespliegue con curl evita que Nginx reciba tráfico hacia una versión no sana. Nginx puede realizar sus propias comprobaciones activas pero validar antes del cambio reduce riesgos.
Rollback Si green falla tras la conmutación tienes dos opciones Manual volver a editar por SSH la línea del map a default blue recargar Nginx y reiniciar el contenedor antiguo. Automático extender el workflow con una etapa post que monitorice los primeros minutos de tráfico mediante alertas Prometheus y dispare la reversión si se detectan errores.
Observabilidad y registros Cero downtime no es solo enrutamiento necesita visibilidad. Usa logs estructurados formato JSON por ejemplo con pino para Node y envía registros a una solución centralizada como Loki o Elastic Stack. Exporta métricas Prometheus desde ambas instancias en /metrics y crea dashboards en Grafana comparando blue vs green. Si dispones de tracing distribuido Jaeger u OpenTelemetry etiqueta los spans con la versión desplegada para correlacionar picos de latencia con releases.
Buenas prácticas de despliegue Etiquetas semánticas y SHA en la imagen para trazabilidad. Script de health check automatizado antes de cambiar upstream. Periodo de gracia corto para rollback manual. Evitar reinicios completos de Nginx usar nginx -s reload siempre que sea posible. Documentar pasos de rollback y opcionalmente automatizarlos.
Integración con servicios profesionales Si buscas apoyo para implementar esta estrategia, Q2BSTUDIO ofrece servicios de desarrollo de software a medida y despliegues fiables. Somos especialistas en aplicaciones a medida inteligencia artificial ciberseguridad servicios cloud aws y azure y soluciones de inteligencia de negocio. Para proyectos de desarrollo de aplicaciones a medida o migraciones cloud visita nuestra página de servicios cloud servicios cloud AWS y Azure.
Checklist definitiva Infraestructura mantener Docker Engine 20.10 en el host Nginx con upstreams blue y green claves SSH en secretos de CI. CI CD versionado semántico en etiquetas Docker health check automatizado antes del switch periodo de gracia para rollback. Nginx usar map para alternar upstream recargar con nginx -s reload. Observabilidad endpoint /health fiable logs centralizados métricas Prometheus y dashboards en Grafana tracing con etiquetas de despliegue. Plan de rollback pasos manuales documentados y opción de rollback automático por alertas.
Conclusión Tratar el proceso como código hace que los despliegues sin tiempo de inactividad sean repetibles versiona imágenes Docker mantén configuraciones Nginx declarativas y automatiza el pipeline de CI para minimizar intervenciones humanas. Sigue la checklist antes de cada merge a main y reducirás las regresiones de emergencia a casi cero. Si necesitas ayuda para implantar esta arquitectura o para servicios en inteligencia artificial ciberseguridad o automatización de procesos contacta con nuestro equipo en Q2BSTUDIO.
.jpg)
.jpg)
.jpg)
.jpg)