Implementación Blue-Green en AWS: Guía paso a paso

El despliegue azul-verde es una estrategia de lanzamiento que minimiza el tiempo de inactividad y reduce el riesgo al ejecutar dos entornos de producción idénticos, denominados "Azul" y "Verde". En cualquier momento, solo uno de los entornos está activo, sirviendo todo el tráfico de producción.

Este artículo proporciona una guía detallada y práctica para implementar despliegues Blue-Green en AWS, centrándose en los patrones arquitectónicos, la automatización y el desafío crítico de gestionar componentes de estado.

Requisitos de arquitectura

Antes de implementar una estrategia Blue-Green, su arquitectura debe cumplir con varios principios fundamentales. No cumplir con estos requisitos anulará los beneficios y generará una complejidad operativa significativa.

Equipo de Ingeniería de Software Compartido Bajo Demanda, Por Suscripción.

Acceda a un equipo flexible y compartido de ingeniería de software bajo demanda a través de una suscripción mensual predecible. Desarrolladores, diseñadores, ingenieros de control de calidad y un gestor de proyectos gratuito le ayudan a crear MVPs, escalar productos e innovar con tecnologías modernas como React, Node.js y más.

Try 4Geeks Teams

1. Infraestructura Inmutable: La base para despliegues predecibles. Tanto los entornos Blue como Green deben construirse a partir de plantillas idénticas y controladas por versiones (por ejemplo, AMIs, imágenes de Docker, plantillas de CloudFormation/Terraform). El entorno Green nunca se modifica en su lugar; se crea de forma nueva a partir del nuevo artefacto, se prueba y luego se promociona. El antiguo entorno Blue se termina, no se actualiza.
2. Nivel de Aplicación Sin Estado: Sus servidores de aplicaciones deben ser sin estado. Cualquier dato de sesión, estado del usuario o archivos temporales deben externalizarse a una caché distribuida (como ElastiCache para Redis) o a un almacén de datos compartido (como S3 o DynamoDB). Esto garantiza que el tráfico se pueda dirigir entre entornos sin perder el contexto del usuario.
3. Automatización Integral: Todo el proceso—provisionamiento de infraestructura, despliegue de la aplicación, ejecución de pruebas y enrutamiento del tráfico—debe estar completamente automatizado. Los pasos manuales introducen el potencial de errores humanos, que es lo que está diseñada para eliminar esta estrategia. AWS CodePipeline, CodeBuild y CodeDeploy son las herramientas principales para esta orquestación.
4. Comprobaciones de Estado y Monitoreo Robustos: Debe tener comprobaciones de estado confiables que validen no solo la salud de la instancia (HTTP 200 OK) sino también la funcionalidad y las dependencias de la aplicación. Estas comprobaciones son las que determinan si el entorno Green está listo para recibir tráfico de producción.

Patrones de Implementación Centralizados en AWS

Existen dos métodos principales para dirigir el tráfico entre los entornos Blue y Green en AWS, cada uno con ventajas y desventajas específicas.

1. Conmutación a nivel DNS con Amazon Route 53

Este patrón implica la manipulación de registros DNS para redirigir el tráfico desde el punto final del entorno "Blue" al punto final del entorno "Green". Conceptualmente es simple, pero presenta inconvenientes notables.

Arquitectura:

Cada entorno (Azul y Verde) tiene su propio conjunto de recursos independiente, incluyendo un Balanceador de Carga de Aplicaciones (ALB) y un Grupo de Escalado Automático (ASG). Un único registro de Route 53, configurado con una Política de Enrutamiento Ponderada, apunta tanto a los ALB.

Flujo de Ejecución:

1. Provision Green: Se proporciona una pila completa y paralela (VPC, ALB, ASG, instancias EC2) para la nueva versión de la aplicación ("Green").
2. Implementar y probar: El nuevo artefacto de la aplicación se implementa en las instancias de Green. Se ejecutan pruebas de "smoke", pruebas de integración y comprobaciones de salud contra el nombre DNS directo del ALB de Green (por ejemplo, green-alb-12345.us-east-1.elb.amazonaws.com).
3. Actualizar los pesos DNS: Inicialmente, el registro ponderado de Route 53 dirige el 100% del tráfico al ALB de Blue y el 0% al ALB de Green. Para cambiar, actualiza el conjunto de registros para desplazar los pesos: 0% a Blue y 100% a Green.
4. Monitorear: Observa las métricas de la aplicación (latencia, tasas de error) para confirmar la salud del entorno de Green bajo una carga de producción completa.
5. Desactivar Blue: Después de un tiempo predeterminado ("bake time" (por ejemplo, una hora), el entorno de Blue se termina.

Equipo de Ingeniería de Software Compartido Bajo Demanda, Por Suscripción.

Acceda a un equipo flexible y compartido de ingeniería de software bajo demanda a través de una suscripción mensual predecible. Desarrolladores, diseñadores, ingenieros de control de calidad y un gerente de proyectos gratuito le ayudan a crear MVPs, escalar productos e innovar con tecnologías modernas como React, Node.js y más.

Try 4Geeks Teams

Ejemplo de AWS CLI (Cambio de ponderación de DNS):

Asume que tu id de zona es Z0123456789ABCDEF y tu dominio es api.example.com. El siguiente comando actualiza el conjunto de registros para dirigir todo el tráfico al Green ALB (nombre de DNS del Green ALB).

{
  "Comment": "Switching production traffic to the Green environment",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "CNAME",
        "SetIdentifier": "blue-environment",
        "Weight": 0,
        "TTL": 60,
        "ResourceRecords": [{ "Value": "blue-alb-dns-name.us-east-1.elb.amazonaws.com" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "CNAME",
        "SetIdentifier": "green-environment",
        "Weight": 100,
        "TTL": 60,
        "ResourceRecords": [{ "Value": "green-alb-dns-name.us-east-1.elb.amazonaws.com" }]
      }
    }
  ]
}

# Execute the change
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEF \
  --change-batch file://traffic-shift-to-green.json

• Ventajas: Fácil de entender; funciona en diferentes regiones.
• Desventajas: Caché DNS. Los clientes y los servidores DNS almacenarán en caché el registro DNS antiguo durante su tiempo de vida (TTL). Incluso con un TTL bajo (por ejemplo, 60 segundos), el cambio de tráfico no es instantáneo ni determinístico. Algunos usuarios pueden seguir accediendo al entorno "Blue" mucho después del cambio, lo cual puede ser problemático.

2. Conmutación a nivel de balanceador de carga con AWS CodeDeploy y Grupos de Destino de ALB

Este es el patrón recomendado y más robusto para la mayoría de los casos de uso. Proporciona un control de tráfico casi instantáneo y preciso, manipulando las reglas del "listener" del "Application Load Balancer", evitando por completo los retrasos en la propagación de DNS.

Arquitectura:

Se utiliza un único ALB (Balanceador de Carga) con dos grupos de destino distintos: target-blue y target-green. La regla del oyente de producción del ALB inicialmente dirige todo el tráfico a target-blue. El proceso de implementación implica la creación de un nuevo conjunto de instancias y su registro con target-green.

Flujo de ejecución (automatizado por AWS CodeDeploy):

1. Inicio de la implementación: Se inicia una nueva implementación en CodeDeploy, dirigida a un Grupo de Implementación configurado para Blue/Green.
2. Implementar Green: CodeDeploy provisiona un nuevo conjunto de instancias EC2 (la "flota de reemplazo" o "Green") según su plantilla de lanzamiento de Auto Scaling Group.
3. Instalar y probar: El archivo appspec.yml orquesta la implementación en estas nuevas instancias.
   • BeforeInstall:, Install:, AfterInstall:: La nueva revisión de la aplicación se descarga e instala.
   • ApplicationStart:, ValidateService:: La aplicación se inicia y se ejecutan las comprobaciones de salud.
   • Conexión de tráfico (BeforeAllowTraffic):): Este es un paso crucial. CodeDeploy le permite ejecutar una función Lambda para realizar pruebas de integración exhaustivas en el entorno Green antes de que reciba cualquier tráfico de producción.Redirigir tráfico:
4. Redireccionar tráfico: Si las pruebas tienen éxito, CodeDeploy modifica automáticamente la regla del oyente de la ALB para que apunte de target-blue a target-green. Este cambio es atómico e instantáneo.
5. Mantener el original (Tiempo de horneado): Las instancias antiguas en target-blue se mantienen en funcionamiento durante un período configurado. Esto permite una reversión inmediata si se detectan problemas después de la implementación.
6. Terminar Blue: Después de que expire el tiempo de horneado, CodeDeploy termina las instancias antiguas.

Ejemplo appspec.yml para CodeDeploy:

Este archivo define los puntos de conexión (hooks) que CodeDeploy ejecuta durante el ciclo de vida del despliegue.

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html/my-app
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root
  ValidateService:
    - location: scripts/validate_health.sh
      timeout: 60
      runas: root
  # Hooks for Blue/Green traffic control
  BeforeAllowTraffic:
    - location: scripts/run_integration_tests.sh
      timeout: 1800
  AfterAllowTraffic:
    - location: scripts/post_deployment_smoke_test.sh
      timeout: 300

• Ventajas: Cambio de tráfico instantáneo. Sin problemas de DNS. El proceso de reversión es igualmente rápido, simplemente revirtiendo el cambio en la regla del oyente. Se integra perfectamente con el ecosistema de AWS (CodePipeline, ASG).
• Desventajas: Configuración inicial ligeramente más compleja. Limitado a una única región.

El Desafío de la Base de Datos: Gestión del Estado

El mayor desafío en una implementación Blue-Green es la gestión de la capa de persistencia. Los niveles de aplicación sin estado son fáciles de intercambiar; las bases de datos no lo son.

Estrategia A: Base de datos compartida (Para cambios compatibles con versiones anteriores)

El enfoque más sencillo es que tanto los entornos Blue como Green compartan la misma base de datos.

• Requisito: Esto implica una estricta disciplina de esquema. Todas las modificaciones de la base de datos que se implementen con el entorno Green deben ser compatibles hacia atrás. Esto normalmente significa que solo se permiten cambios adicionales (nuevas tablas, nuevas columnas con valores predeterminados, nuevos índices). Los cambios destructivos (eliminar columnas, renombrar tablas) deben posponerse hasta que todo el tráfico haya sido redirigido del entorno Blue durante un período seguro.
• Reversión: La reversión es sencilla. Dado que ambas versiones de la aplicación estaban escribiendo en la misma base de datos, simplemente redirigir el tráfico de nuevo al entorno Blue funciona sin problemas.

Estrategia B: Implementación de Base de Datos Azul-Verde (Para Cambios)

Para cambios que no son compatibles con versiones anteriores, se requiere un enfoque más sofisticado.Implementación Blue/Green de Amazon RDS es una función gestionada que automatiza este proceso.

Flujo de Ejecución con RDS Blue/Green:

1. Crear Green DB: Utilizando la Consola o la CLI de AWS, creas un despliegue de base de datos "Green" a partir de tu instancia RDS "Blue" (producción). AWS crea una copia física completamente sincronizada de tu base de datos de producción.
2. Desplegar Green App: Proporciona tu entorno de aplicación Green y configúralo para que apunte al punto final de la base de datos Green.
3. Pruebas: Realiza la validación y las pruebas en el entorno Green aislado (app + DB). La base de datos Green continúa sincronizándose con la base de datos Blue a través de replicación lógica.
4. Cambio de entorno: Cuando estés listo, inicias el cambio de entorno. RDS realiza las siguientes acciones protegidas:
   • Bloquea las escrituras en ambas bases de datos Blue y Green.
   • Espera a que la base de datos Green se sincronice completamente con las últimas transacciones de la Blue.
   • Promueve la base de datos Green como la nueva primaria, renombrando los puntos finales de la base de datos para que la cadena de conexión de la aplicación no necesite cambiar.
   • Redirige la replicación del antiguo primario al nuevo.
5. Cambio de tráfico: Al mismo tiempo, realizas el cambio de tráfico de la aplicación (por ejemplo, mediante el intercambio del grupo de objetivos de ALB).

Este enfoque proporciona una completa separación y permite cambios complejos en el esquema, pero introduce una breve interrupción de escritura durante el cambio final (típicamente inferior a un minuto).

Conclusión

Implementar una estrategia de despliegue Blue-Green en AWS es una técnica poderosa para lograr despliegues con prácticamente cero tiempo de inactividad y mitigar los riesgos asociados al despliegue. Para la mayoría de las aplicaciones, el método de "Intercambio de Grupos de Destino" de ALB, orquestado por AWS CodeDeploy, ofrece el control más preciso y fiable sobre el tráfico.El método de intercambio de grupos de ALB (Application Load Balancer) orquestado por AWS CodeDeploy ofrece el control más preciso y fiable sobre el tráfico. La conmutación basada en DNS sigue siendo una alternativa viable y más sencilla para servicios donde los retrasos en la propagación de DNS son aceptables.

El éxito, sin embargo, se centra menos en el servicio específico de AWS y más en la disciplina arquitectónica. Adoptar una infraestructura inmutable, garantizar que las aplicaciones sean sin estado y automatizar rigurosamente el proceso son requisitos indispensables. Para los sistemas basados en estado, la base de datos se convierte en el principal desafío, lo que requiere una estrategia deliberada para gestionar la evolución del esquema, ya sea a través de una compatibilidad estricta hacia atrás o aprovechando funciones avanzadas como las implementaciones Blue/Green de RDS para una transición totalmente aislada.

Equipo de Ingeniería de Software Compartido Bajo Demanda, Con Suscripción.

Acceda a un equipo flexible y compartido de ingeniería de software bajo demanda a través de una suscripción mensual predecible. Desarrolladores, diseñadores, ingenieros de control de calidad y un gerente de proyectos gratuito le ayudan a construir MVPs, escalar productos e innovar con tecnologías modernas como React, Node.js y más.

Try 4Geeks Teams

Preguntas frecuentes