StackPractices
EN
intermediate Por Mathias Paulenko

Receta: Despliegue Blue-Green

Despliega con zero downtime usando ambientes blue-green, conmutación instantánea de tráfico y capacidades de rollback automatizado.

blue-green deployment zero-downtime devops ci-cd
Temas: devops

Visión General

El despliegue blue-green es una estrategia de release que mantiene dos ambientes de producción idénticos: uno activo (blue) y otro inactivo (green). Las nuevas versiones se despliegan en el ambiente inactivo, se validan con smoke tests, y luego el tráfico se conmuta instantáneamente. Si surgen problemas, el rollback es una simple conmutación de tráfico, tomando segundos en lugar de horas.

Cuándo Usar

Usa este recurso cuando:

  • El downtime durante despliegues es inaceptable (SLA > 99.9%). Consulta Health Check Endpoint para verificación de readiness.
  • Necesitas capacidad de rollback instantáneo sin redeployar. Consulta Feature Flags para toggles instantáneos.
  • Ejecutas migraciones de base de datos que deben ser retrocompatibles. Consulta Docker Compose Local Dev para testing local de migraciones.
  • Validas nuevos releases contra tráfico real de producción vía canary routing. Consulta Istio Canary Deployment para shifting progresivo de tráfico.

Solución

Conmutación de Tráfico con Nginx (Bash)

#!/bin/bash
# Conmuta tráfico de blue a green

BLUE_IP="10.0.1.10"
GREEN_IP="10.0.1.11"
NGINX_CONF="/etc/nginx/sites-enabled/app"

# Actualizar upstream para apuntar a green
sed -i "s/server $BLUE_IP:8080/server $GREEN_IP:8080/" $NGINX_CONF
nginx -s reload

# Health check en green
if ! curl -sf http://$GREEN_IP:8080/health; then
  # Rollback instantáneo
  sed -i "s/server $GREEN_IP:8080/server $BLUE_IP:8080/" $NGINX_CONF
  nginx -s reload
  echo "Rollback completado"
  exit 1
fi

Kubernetes Deployment con Service Switch

apiVersion: v1
kind: Service
metadata:
  name: app-active
spec:
  selector:
    version: blue  # Cambiar a "green" para conmutar
  ports:
    - port: 80
      targetPort: 8080

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
      version: green
  template:
    metadata:
      labels:
        app: web
        version: green
    spec:
      containers:
        - name: app
          image: myapp:v2.0.0

AWS Route 53 Weighted Routing

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "green",
        "Weight": 100,
        "TTL": 60,
        "ResourceRecords": [{"Value": "1.2.3.4"}]
      }
    }]
  }'

Explicación

Cómo funciona:

  1. Ambiente blue sirve todo el tráfico de producción
  2. Ambiente green recibe el nuevo despliegue
  3. Smoke tests validan green (health checks, transacciones sintéticas)
  4. Conmutación de tráfico dirige a todos los usuarios hacia green
  5. Blue permanece caliente como target de rollback instantáneo
  6. Próximo deploy va a blue, los roles se intercambian

Compatibilidad de base de datos:

  • Las migraciones deben ser retrocompatibles (agregar columnas, nunca eliminar)
  • Blue debe tolerar el schema de green; green debe tolerar el schema de blue
  • Usa feature flags para ocultar nuevas columnas de blue

Variantes

EstrategiaDowntimeVelocidad de RollbackCosto
Blue-GreenCeroInstantáneo (segundos)2x infraestructura
RollingCeroLento (minutos)1x + surge
CanaryCeroMedio (minutos)1x + pequeño surge
RecreateAltoN/A1x

Lo que funciona

  • Mantén blue caliente por un ciclo de deploy: No desmantelar hasta que el próximo despliegue tenga éxito
  • Automatiza la conmutación: Las actualizaciones manuales de DNS son propensas a errores; usa pipelines CI/CD
  • Monitorea durante la conmutación: Observa tasas de error, latencia y métricas de negocio por 5-10 minutos post-conmutación
  • Usa sticky sessions con cuidado: Conmutar durante una sesión puede interrumpir conexiones stateful
  • Comparte estado vía stores externos: Ambos ambientes deben acceder a las mismas bases de datos, caches y colas

Errores Comunes

  1. Blue/green stateful: Las sesiones almacenadas en memoria se pierden durante conmutaciones; usa Redis o JWT
  2. Configs diferentes: Blue y green deben tener variables de entorno idénticas excepto la versión
  3. Olvidar testear rollback: Un despliegue que no puede hacer rollback de forma segura no está listo para producción
  4. Conflictos de schema de base de datos: Cambios de schema breaking desplegados antes de que ambas apps sean compatibles
  5. Dejar ambientes viejos corriendo: Los ambientes no utilizados generan costos en la nube; automatiza la limpieza

Tips de Rendimiento

  1. Escala blue hacia abajo entre deploys. Mantén blue en 1 réplica para ahorrar costos manteniendo capacidad de rollback:
kubectl scale deployment app-blue --replicas=1
  1. Usa spot instances para el ambiente idle. Green corre brevemente durante el deploy; córrelo en spot instances más baratas:
nodeSelector:
  node-role.kubernetes.io/spot: "true"
  1. Cachéa la imagen Docker en todos los nodos. Pre-pull la nueva imagen para evitar startup lento durante la conmutación:
# Usar un DaemonSet para pre-pull
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-pre-puller
spec:
  template:
    spec:
      initContainers:
      - name: pull
        image: myapp:v2.0.0
        command: ["true"]
      containers:
      - name: pause
        image: gcr.io/google_containers/pause

Preguntas frecuentes

¿Esta solución está lista para producción?

Sí. Los ejemplos de código arriba muestran implementaciones probadas. Adapta el manejo de errores y la configuración a tu entorno específico antes de desplegar.

¿Cuáles son las características de rendimiento?

El rendimiento depende de tu volumen de datos e infraestructura. Las soluciones mostradas priorizan claridad. Para escenarios de alto throughput, añade caching, batching y connection pooling según sea necesario.

¿Cómo depuro problemas con este enfoque?

Empieza con el ejemplo mínimo de arriba. Añade logging en cada paso. Prueba con entradas pequeñas primero, luego escala. Usa el debugger de tu lenguaje para revisar los edge cases.

Pipeline CI/CD con GitHub Actions 
# .github/workflows/blue-green.yml
name: Blue-Green Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to green
        run: |
          kubectl apply -f k8s/green-deployment.yaml
          kubectl rollout status deployment/app-green --timeout=120s

      - name: Smoke test green
        run: |
          GREEN_IP=$(kubectl get svc app-green -o jsonpath='{.spec.clusterIP}')
          for i in $(seq 1 10); do
            if curl -sf "http://$GREEN_IP:8080/health"; then
              echo "Green healthy"
              break
            fi
            sleep 5
          done

      - name: Switch traffic to green
        run: |
          kubectl patch svc app-active -p '{"spec":{"selector":{"version":"green"}}}'

      - name: Verify production
        run: |
          sleep 30
          if ! curl -sf https://api.example.com/health; then
            kubectl patch svc app-active -p '{"spec":{"selector":{"version":"blue"}}}'
            echo "Rollback triggered"
            exit 1
          fi

      - name: Scale down blue
        run: kubectl scale deployment app-blue --replicas=0
Estrategia de Migración de Base de Datos 
import psycopg2

def expand_migrate(conn):
    """Fase 1: Expand — agregar nuevas columnas, mantener las viejas."""
    with conn.cursor() as cur:
        cur.execute("""
            ALTER TABLE users
            ADD COLUMN IF NOT EXISTS email_v2 VARCHAR(255);
        """)
        cur.execute("""
            UPDATE users SET email_v2 = email;
        """)
        conn.commit()

def contract_migrate(conn):
    """Fase 2: Contract — remover columnas viejas después de decomisionar blue."""
    with conn.cursor() as cur:
        cur.execute("""
            ALTER TABLE users DROP COLUMN IF EXISTS email;
        """)
        conn.commit()

# Secuencia de deploy:
# 1. Ejecutar expand_migrate (tanto blue como green funcionan)
# 2. Conmutar tráfico a green
# 3. Después de validación, ejecutar contract_migrate (solo green usa el nuevo schema)
Script de Monitoreo Post-Conmutación 
#!/bin/bash
# monitor-post-switch.sh

DURATION=300  # 5 minutos
INTERVAL=10
END=$((SECONDS + DURATION))

while [ $SECONDS -lt $END ]; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health)
  LATENCY=$(curl -s -o /dev/null -w "%{time_total}" https://api.example.com/health)
  ERROR_RATE=$(curl -s https://api.example.com/metrics | grep error_rate | awk '{print $2}')

  echo "$(date -Iseconds) status=$STATUS latency=${LATENCY}s error_rate=$ERROR_RATE"

  if [ "$STATUS" != "200" ] || (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
    echo "ALERT: Rollback"
    kubectl patch svc app-active -p '{"spec":{"selector":{"version":"blue"}}}'
    exit 1
  fi

  sleep $INTERVAL
done

echo "Monitoreo completo. Green está estable."
Guide

Despliegues Blue-Green y Canary

Guía práctica de estrategias de deploy: blue-green, canary, rolling y feature flags. Minimiza riesgo y tiempo de rollback al liberar a producción.

Doc

Plantilla de Checklist Post-Deploy

Plantilla de checklist para verificar deployments: health checks, smoke tests, validación de métricas y rollback readiness antes de declarar all-clear.

Guide

Guía de Pipelines CI/CD

Una guía práctica para construir pipelines CI/CD con GitHub Actions, testing, estrategias de deployment y procedimientos de rollback.

Recipe

Implementar graceful shutdown y reinicios sin downtime

Cómo implementar graceful shutdown y reinicios sin downtime para servidores web, workers y contenedores

Recipe

Despliegues Canary con Istio Service Mesh

Como usar el splitting de trafico de Istio para realizar despliegues canary seguros desplazando gradualmente usuarios entre versiones de aplicaciones

Recipe

Traffic Mirroring para Testing en Producción

Replica tráfico de producción a ambientes de staging para testing realista, despliegues shadow y validación de performance sin impactar usuarios.