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
- Error rate
- Latency (P50, P95, P99)
- Throughput
- Resource usage (CPU, memory)
Alertas
- Error rate > 1%
- Latency P95 > threshold
- Health check failures
- Resource exhaustion
Best Practices
- Testar em staging primeiro: Sempre testar blue-green em staging
- Health checks robustos: Verificar dependências
- Monitoramento ativo: Monitorar durante alternância
- Rollback preparado: Ter processo de rollback documentado
- Comunicação: Notificar equipe antes de deploy
- 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