Blue-Green e Canary Depl

Blue-Green e Canary

1) Tarefa e ideias-chave

• Blue-Green: Mantendo duas versões paralelas (Blue - ativa, Green - nova), mudando o tráfego atômico. Um rápido retrocesso → recuperar a Blue instantaneamente.
• Canary: Incluímos uma nova versão em etapas (1% → 5% → 25% → 50% → 100%), monitoria de métricas SLO e paramos/revertemos em caso de degradação.

O princípio geral é separar a «entrega do artefacto» da «inclusão do tráfego» e automatizar a observabilidade + retração.

2) Quando escolher

• precisa de uma mudança instantânea (RTO RTO), serviços de state-less simples;
• há janelas de lançamento rigorosas/congelamento e verificações compreensíveis de smoke;
• Manter uma capacidade dupla de longa duração é caro, mas pode ser breve.

• mudanças complexas, necessitando de validação gradual no tráfego real;
• há telemetria madura (SLO, métricas de negócios), capacidade de auto-pé;
• é crítico limitar o raio de impacto (fluxo de fintech/iGaming).

Combo-pattern: Roda o Green e mude para ele através do estágio canary (Blue-Green como esqueleto, Canary como método de transferência de tráfego).

3) Arquitetura de rotação de tráfego

1. L4/L7-balanceador (ALB/NLB, Cloud Louad Balancer) é um grupo de target ponderado.

2. Entrada API/WAF - rota/weight em versões, cabeçalhos, cookies, regiões.

3. Serviço Mesh (Istio/Linkerd/Consul) - distribuição percentual, injeção fault, canetas de temporizações/retais/restrições.

4. Ingresss/NGINX/Envoy - peso upstream e rotação por atributos.

5. Argo Rollouts/Flagger - operadora controlador, progressão automática, integração com Prometheus/New Relic/Datadog.

4) Kubernetes: modelos práticos

4. 1 Blue-Green (por serviço selector)

Два Deployment: `app-blue` и `app-green`.
Um Service 'app-svc' com seletor para 'versão' desejada.

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: app-green, labels: { app: app, version: green } }
spec:
replicas: 4 selector: { matchLabels: { app: app, version: green } }
template:
metadata: { labels: { app: app, version: green } }
spec:
containers:
- name: app image: ghcr. io/org/app:1. 8. 0 apiVersion: v1 kind: Service metadata: { name: app-svc }
spec:
selector: {app: app, version: blue} # ← switch to green - change ports: [{port: 80, targetPort: 8080}]

Alteração - Alteração atômica do seletor (ou marcas) com o drain monitorado.

4. 2 Canary (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: app }
spec:
hosts: ["app. example. com"]
http:
- route:
- destination: { host: app. blue. svc. cluster. local, subset: v1 }
weight: 90
- destination: { host: app. green. svc. cluster. local, subset: v2 }
weight: 10

Troque 'weight' por degraus; adicione retry, timeout, outlier-detector no DestinationRule.

4. 3 Argo Rollouts (Engenho de Canário Automático)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: app }
spec:
replicas: 6 strategy:
canary:
canaryService: app-canary stableService: app-stable steps:
- setWeight: 5
- pause: {duration: 300} # 5 min observation
- analysis:
templates:
- templateName: slo-guard
- setWeight: 25
- pause: { duration: 600 }
- analysis:
templates: [{ templateName: slo-guard }]
- setWeight: 50
- pause: {}
trafficRouting:
istio:
virtualService:
name: app routes: ["http-route"]

O modelo de análise está associado a métricas (consulte abaixo).

5) SLO-gates e auto-revezamento

• Técnica: 'p95 _ latency', '5xx _ rate', 'erro _ budget _ burn', 'CPU/Memory throttling'.
• Produtos: 'CR (depósito)', 'sucesso de pagamento', 'scrog', 'ARPU' (em janelas frias).

• Se '5xx _ rate' nova versão> 0. 5% durante 10 min - pause e rollback.
• Se 'p95 _ latency' ↑> 20% da base for rollback.
• Se a promoção de canarinhos estiver em andamento, mas o orçamento SLO é queimado> 2 %/hora - hold.

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: slo-guard }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

6) Dados e compatibilidade (causa mais frequente de dor)

• Expand: adicionar novas colunas/índices nullable, suportar ambos os esquemas.
• Migrate: dupla gravação/leitura, back-fill.
• Contract: remover campos/códigos antigos após a saída de 100% do tráfego.
• Eventos/filas: versionize payload (v1/v2) e mantenha idempotency.
• Dinheiro/sessão: versionize as chaves; certifique-se de que o formato é compatível.

7) Integração com CI/CD e GitOps

CI: Montagem de um único artefacto (build once), assinatura de imagem, SBOM, testes.
CD: promoção do artefato através do ambiente; Blue-Green/Canary são controlados por manifestos.
GitOps: merj MR → controlador (Argo CD/Flux) aplica peso/seletor.
Ambientonments/Approvals: para prod steps - gate manual + auditar soluções.

8) NGINX/Envoy e LB na nuvem: exemplos rápidos

8. 1 NGINX (peso upstream)

nginx upstream app_upstream {
server app-blue:8080 weight=90;
server app-green:8080 weight=10;
}
server {
location / { proxy_pass http://app_upstream; }
}

8. 2 AWS ALB (Weighted Target Groups)

TG-Blue: 90, TG-Green: 10 → mude de peso através de IaC/CLI.
Vincule o CloudWatch-alerts aos violinos de carro rollback (mudança de peso para 0/100).

9) Segurança e conformidade

Zero trust entre versões: delimite os segredos/chave de criptografia rolling.
Policy-as-Code: Proibição do deploy de imagens não assinadas, 'no latest'.
Segredos e configs como artefatos de versões; O retrocesso inclui a reversão de configurs.
Auditoria: quem quando levantou o peso/alterou o seletor, com qual tíquete.

10) Custo e capacidade

O Blue-Green requer energia dupla durante o período de lançamento → planifique a janela.
Canary pode durar mais tempo → o custo de telemetria/observação, o conteúdo paralelo das duas versões.
Otimização: autoscaling por HPA/VPA, janelas curtas Blue-Green, lançamentos noturnos para serviços «pesados».

11) Reversões (runbook)

1. Congelar promoção (pause).
2. Reduzir o peso do Green para 0% (canary )/devolver o seletor para o Blue-green.
3. Verificar: erros/latência voltados para os compostos básicos, drenar compostos.
4. Abrir o incidente, recolher artefatos (logs, pistas, comparações de métricas).
5. Fix/reprod para o estágio, expulsar smoke, reiniciar a progressão.

12) Anti-pattern

Cruzamento de artefato entre estágio e prod (violação «build once»).
Canary surdo sem SLO/métricas - formalidade, não proteção.
Falta de bandeiras de fich, o lançamento tem de incluir 100% de comportamento ao mesmo tempo.
Health-check/liveness inoperantes → subterfúgios e falsa estabilidade.
Compatibilidade de BD para o eixo: o contrato é quebrado ao mudar.
Marcas de imagem mutáveis/' latest 'em venda.

13) Folha de cheque de implementação (0-45 dias)

0-10 dias

Escolha uma estratégia para os serviços B/G, Canary ou combinado.
Incluir assinatura de imagens, health-checks, readiness-amostras, 'no latest'.
Preparar dashboards SLO (latency/error rate/métricas de negócios).

11 a 25 dias

Automação de peso (Istio/Argo Rollouts/ALB-weights).
Configure analis templates, alertas e auto-rollback.
Mapear manifestos (Helm/Kustomize), integrar com GitOps.

26-45 dias

Implantar a estratégia de «expand-migrate-contract» para o banco de dados.
Cobrir flow kill-switch críticas com bandeiras.
Fazer «game day»: simule um retrocesso e um incidente.

14) Métricas de maturidade

% de lançamentos via Blue-Green/Canary (alvo> 90%).
Tempo médio de mudança/reversão (alvo <3 min).
Proporção de lançamentos com camião de carro SLO (e sem incidentes).
Cobertura de telemetria (traces/logs/metrics)> 95%.
Taxa de migração de BD no esquema expand-migrate-contract> 90%.

15) Aplicativos: modelos de políticas e piplins

OPA (exclusão de imagens não assinadas)

rego package admission. image

deny[msg] {
input. request. kind. kind == "Deployment"
some c img:= input. request. object. spec. template. spec. containers[c].image not startswith(img, "ghcr. io/org/")
msg:= sprintf("Image not from trusted registry: %v", [img])
}

Helm-values para canary (simplificado)

yaml canary:
enabled: true steps:
- weight: 5 pause: 300
- weight: 25 pause: 600
- weight: 50 pause: 900 sloGuards:
max5xxPct: 0. 5 maxP95IncreasePct: 20

GitHub Action - promoção de peso (pseudo)

yaml
- name: Promote canary to 25%
run: kubectl patch virtualservice app \
--type=json \
-p='[{"op":"replace","path":"/spec/http/0/route/1/weight","value":25}]'

16) Conclusão

Blue-Green e Canary não são estratégias mutuamente exclusivas, mas complementares. Construa-os sobre artefatos assinados, observabilidade SLO, gates automáticos e controle GitOps. Separe a entrega da inclusão, mantenha um rápido retrocesso e disciplina de migração - e os lançamentos serão previsíveis, seguros e rápidos.