Concepto clave

Las estrategias de despliegue blue-green y canary son técnicas avanzadas para implementar cambios en producción minimizando el riesgo y el tiempo de inactividad. Imagina que tienes dos teatros idénticos (blue y green): mientras uno está en uso con la versión actual, el otro se prepara con la nueva versión. Al cambiar el tráfico de un teatro a otro, el cambio es instantáneo y reversible. En contraste, el despliegue canary es como liberar una nueva bebida primero a un pequeño grupo de clientes: si no hay reacciones adversas, se expande gradualmente a todos. Estas estrategias son esenciales en entornos cloud donde la disponibilidad y la experiencia del usuario son críticas.

En el contexto de CI/CD con GitHub Actions, estas estrategias te permiten automatizar despliegues seguros. Blue-green es ideal para cambios drásticos que requieren un rollback rápido, mientras que canary es perfecto para probar nuevas funcionalidades con usuarios reales antes de un lanzamiento completo. Ambas reducen el blast radius de posibles errores, algo clave para un DevOps Engineer que gestiona aplicaciones modernas.

Cómo funciona en la práctica

Para implementar blue-green en un entorno cloud como AWS o Azure, sigue estos pasos:

Prepara dos entornos idénticos (ej., blue con versión 1.0, green con versión 2.0).
Usa GitHub Actions para desplegar la nueva versión en el entorno inactivo (green).
Ejecuta pruebas automatizadas en green para validar la versión.
Cambia el tráfico de blue a green usando un balanceador de carga o reglas de enrutamiento.
Monitorea el rendimiento; si hay problemas, revierte rápidamente a blue.

Para canary, el proceso es gradual:

Despliega la nueva versión a un pequeño porcentaje de usuarios (ej., 5%).
Usa métricas de monitoreo (como latencia o tasa de error) para evaluar el impacto.
Incrementa gradualmente el tráfico a la nueva versión (ej., 20%, 50%, 100%).
Si se detectan anomalías, detén el despliegue o revierte.

GitHub Actions orquesta estos pasos mediante workflows que integran con herramientas cloud, asegurando que cada fase sea automática y reproducible.

Codigo en accion

Ejemplo de workflow de GitHub Actions para blue-green en AWS Elastic Beanstalk:

name: Blue-Green Deployment to AWS

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      
      - name: Deploy to Green Environment
        run: |
          # Desplegar nueva version en entorno green
          aws elasticbeanstalk create-environment-version \
            --application-name my-app \
            --version-label v2.0 \
            --source-bundle S3Bucket=my-bucket,S3Key=app-v2.zip
          
          # Esperar a que green este saludable
          aws elasticbeanstalk wait environment-healthy \
            --environment-name my-app-green
      
      - name: Swap Blue and Green
        run: |
          # Cambiar tráfico de blue a green
          aws elasticbeanstalk swap-environment-cnames \
            --source-environment-name my-app-blue \
            --destination-environment-name my-app-green

Ejemplo de workflow para canary en Kubernetes usando Istio:

name: Canary Deployment with Istio

on:
  push:
    branches: [ main ]

jobs:
  canary:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Deploy Canary (5% traffic)
        run: |
          # Aplicar configuración de Istio para enrutar 5% del tráfico
          kubectl apply -f istio-canary.yaml
          
          # Contenido de istio-canary.yaml:
          # apiVersion: networking.istio.io/v1beta1
          # kind: VirtualService
          # metadata:
          #   name: my-service
          # spec:
          #   hosts:
          #   - my-service
          #   http:
          #   - route:
          #     - destination:
          #         host: my-service
          #         subset: v1
          #       weight: 95
          #     - destination:
          #         host: my-service
          #         subset: v2
          #       weight: 5
      
      - name: Monitor and Ramp Up
        run: |
          # Esperar 10 minutos y monitorear métricas
          sleep 600
          # Si métricas son OK, aumentar a 20%
          kubectl apply -f istio-ramp-up.yaml

Errores comunes

No configurar monitoreo adecuado: Desplegar sin métricas (como tasa de error o latencia) impide detectar problemas temprano. Solución: Integra herramientas como Prometheus o CloudWatch en tu workflow.
Olvidar limpiar recursos antiguos: En blue-green, dejar entornos inactivos consume costos. Solución: Automatiza la eliminación del entorno viejo después del cambio.
Pruebas insuficientes en el entorno inactivo: Cambiar tráfico sin validar puede causar caídas. Solución: Ejecuta pruebas de humo y de integración en green antes del swap.
Gestionar mal las variables de entorno: Diferencias entre blue y green llevan a inconsistencias. Solución: Usa secretos de GitHub y configuraciones idénticas.
Ignorar el rollback automatizado: No planificar la reversión aumenta el riesgo. Solución: Incluye pasos en el workflow para revertir rápidamente si fallan las métricas.

Checklist de dominio

Entiendo la diferencia entre blue-green (cambio completo) y canary (gradual).
Puedo configurar un workflow de GitHub Actions para blue-green en un proveedor cloud.
Sé integrar monitoreo (ej., métricas de AWS o Kubernetes) en el despliegue.
He automatizado pruebas pre-despliegue en el entorno inactivo.
Manejo secretos y configuraciones de forma segura entre entornos.
Puedo revertir un despliegue usando GitHub Actions en caso de errores.
Documento los pasos y resultados de cada despliegue para mejora continua.

Implementa un despliegue blue-green para una app web en AWS

En este ejercicio, crearás un workflow de GitHub Actions que automatice un despliegue blue-green para una aplicación web simple en AWS Elastic Beanstalk. Sigue estos pasos:

Prepara tu entorno:
- Crea una aplicación en AWS Elastic Beanstalk con dos entornos: my-app-blue y my-app-green.
- Configura secretos en GitHub para AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY.
Desarrolla el workflow:
- En tu repositorio, crea un archivo .github/workflows/blue-green.yml.
- Usa el ejemplo de código de la lección como base, adaptándolo a tu aplicación.
- Asegúrate de incluir pasos para desplejar en green, esperar a que esté saludable, y luego cambiar el tráfico.
Agrega mejoras:
- Incorpora un paso para ejecutar pruebas automatizadas (ej., con curl o un script) en green antes del swap.
- Añade un paso opcional para eliminar el entorno blue antiguo después de confirmar que green funciona.
Prueba el despliegue:
- Haz un push a la rama main para activar el workflow.
- Verifica en la consola de AWS que el tráfico se cambió correctamente.
- Simula un error y prueba el rollback manual o automático.

Entrega un enlace a tu repositorio con el workflow funcional y una breve explicación de los resultados.

Pistas

Usa la acción oficial de AWS para configurar credenciales de forma segura.
Aprovecha los comandos de la CLI de AWS para gestionar entornos en Elastic Beanstalk.
Considera agregar un paso de notificación (ej., con Slack) al completar el despliegue.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Implementa estrategias de despliegue blue-green y canary