Blue Green Deployment

Blue-Green Deployment - C-Suite

Este documento descreve o processo de Blue-Green Deployment para o ecossistema C-Suite, permitindo deploys sem downtime e rollback rápido.

Visão Geral

Blue-Green Deployment mantém duas versões idênticas do ambiente (blue e green), alternando tráfego entre elas para deploys sem downtime.

Arquitetura

                    Load Balancer
                         |
        +----------------+----------------+
        |                                 |
    Blue (v1)                        Green (v2)
    [Running]                        [New Version]

Estratégias

1. Docker Swarm (Atual)

Deploy Blue-Green

# 1. Deploy nova versão como "green"
docker service create \
  --name csuite-api-green \
  --replicas 2 \
  --network superbot-swarm-network \
  csuite-api:v2

# 2. Testar green
curl http://green-endpoint/health

# 3. Alternar tráfego no Traefik
# Atualizar labels para apontar para green

# 4. Remover blue após verificação
docker service rm csuite-api-blue

Script Automatizado

#!/bin/bash
# blue_green_deploy.sh

SERVICE_NAME="csuite-api"
NEW_VERSION="v2"
CURRENT_COLOR=$(docker service ls | grep $SERVICE_NAME | awk '{print $2}' | grep -o '[^-]*$')

if [ "$CURRENT_COLOR" == "blue" ]; then
  NEW_COLOR="green"
else
  NEW_COLOR="blue"
fi

# Deploy nova versão
docker service create \
  --name ${SERVICE_NAME}-${NEW_COLOR} \
  --replicas 2 \
  --network superbot-swarm-network \
  ${SERVICE_NAME}:${NEW_VERSION}

# Aguardar health check
sleep 30
curl -f http://${NEW_COLOR}-endpoint/health || exit 1

# Alternar tráfego (atualizar Traefik labels)
# ...

# Remover versão antiga após período de observação
sleep 300
docker service rm ${SERVICE_NAME}-${CURRENT_COLOR}

2. AWS ECS

Task Definitions

{
  "family": "csuite-api",
  "containerDefinitions": [{
    "name": "csuite-api",
    "image": "csuite-api:v2",
    "portMappings": [{
      "containerPort": 8000
    }]
  }]
}

Deploy

# 1. Registrar nova task definition
aws ecs register-task-definition --cli-input-json file://task-definition.json

# 2. Criar novo serviço (green)
aws ecs create-service \
  --cluster csuite-cluster \
  --service-name csuite-api-green \
  --task-definition csuite-api:v2 \
  --desired-count 2

# 3. Testar green
curl http://green-alb/health

# 4. Alternar target group no ALB
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:... \
  --default-actions Type=forward,TargetGroupArn=green-tg-arn

# 5. Remover blue após verificação
aws ecs update-service \
  --cluster csuite-cluster \
  --service csuite-api-blue \
  --desired-count 0

3. Kubernetes

Deploy

# deployment-green.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: csuite-api-green
spec:
  replicas: 2
  selector:
    matchLabels:
      app: csuite-api
      version: green
  template:
    metadata:
      labels:
        app: csuite-api
        version: green
    spec:
      containers:
      - name: csuite-api
        image: csuite-api:v2
        ports:
        - containerPort: 8000
# 1. Deploy green
kubectl apply -f deployment-green.yaml

# 2. Criar service para green
kubectl expose deployment csuite-api-green --port=8000

# 3. Testar
curl http://green-service/health

# 4. Alternar ingress
kubectl patch ingress csuite-api -p '{"spec":{"rules":[{"host":"api.example.com","http":{"paths":[{"path":"/","backend":{"serviceName":"csuite-api-green"}}]}}]}}'

# 5. Remover blue
kubectl delete deployment csuite-api-blue

Processo Completo

1. Preparação

# Verificar estado atual
docker service ls | grep csuite-api

# Backup de dados críticos
python scripts/backup_database.py --database csuite

2. Deploy Green

# Build nova imagem
docker build -t csuite-api:v2 .

# Deploy green
docker service create --name csuite-api-green ...

3. Validação

# Health checks
curl http://green-endpoint/health
curl http://green-endpoint/ready

# Smoke tests
pytest tests/smoke_tests.py --endpoint=http://green-endpoint

# Verificar logs
docker service logs csuite-api-green --tail 100

4. Alternância

# Atualizar Traefik/ALB para apontar para green
# (depende da plataforma)

# Monitorar métricas
watch -n 5 'curl -s http://green-endpoint/metrics | grep http_requests'

5. Observação

# Monitorar por período (ex: 15 minutos)
# Verificar:
# - Error rates
# - Latency
# - Resource usage
# - Business metrics

6. Finalização

# Se tudo OK, remover blue
docker service rm csuite-api-blue

# Se problemas, rollback para blue
# (reverter Traefik/ALB)

Rollback

Rollback Rápido

# 1. Reverter Traefik/ALB para blue
# 2. Verificar blue ainda está rodando
docker service ls | grep csuite-api-blue

# 3. Se não estiver, recriar
docker service create --name csuite-api-blue ...

# 4. Remover green problemático
docker service rm csuite-api-green

Script de Rollback

#!/bin/bash
# rollback.sh

SERVICE_NAME="csuite-api"
CURRENT_COLOR="green"
ROLLBACK_COLOR="blue"

echo "Rolling back to $ROLLBACK_COLOR..."

# Reverter tráfego
# (depende da plataforma)

# Verificar rollback
sleep 10
curl -f http://${ROLLBACK_COLOR}-endpoint/health || {
  echo "Rollback failed!"
  exit 1
}

echo "Rollback successful!"

Monitoramento

Métricas Críticas

Alertas

Best Practices

  1. Testar em staging primeiro: Sempre testar blue-green em staging
  2. Health checks robustos: Verificar dependências
  3. Monitoramento ativo: Monitorar durante alternância
  4. Rollback preparado: Ter processo de rollback documentado
  5. Comunicação: Notificar equipe antes de deploy
  6. Horários: Fazer deploys em horários de baixo tráfego quando possível

Automação

CI/CD Integration

# .github/workflows/deploy.yml
deploy:
  steps:
    - name: Deploy Green
      run: ./scripts/blue_green_deploy.sh green

    - name: Health Check
      run: ./scripts/health_check.sh green

    - name: Switch Traffic
      if: success()
      run: ./scripts/switch_traffic.sh green

    - name: Monitor
      run: ./scripts/monitor.sh 300

    - name: Cleanup Blue
      if: success()
      run: ./scripts/cleanup.sh blue

Referências

🔊 Text-to-Speech

1.0x
1.0
Pronto para reproduzir