DevOpsQuest
0 XP

DEVOPSQUEST

Minha Trilha
Módulo 5 · CI/CD com GitHub Actions

Entrega progressiva: blue/green, canary e rollback orientado por métricas

Intermediário 50 min+25 XPKuberneteskubectlGitHub Actions

Objetivos desta aula

  • Comparar blue/green e canary segundo risco e custo
  • Separar disponibilidade técnica de saúde do negócio
  • Planejar critérios de promoção e aborto
  • Trocar o tráfego entre versões identificáveis
  • Compatibilizar migrações com retorno à versão anterior

Estratégia de deploy controla exposição ao risco. Um container iniciar não demonstra que os pedidos continuam sendo processados. Defina critérios de aceitação, como taxa de erros e latência, antes de liberar tráfego para uma versão nova.

Blue/green mantém dois ambientes completos: um atende usuários e o outro recebe a release candidata. Depois de testes, o roteamento muda para o novo ambiente. A troca pode ser rápida, mas duplicar capacidade tem custo e os dois ambientes podem compartilhar o mesmo banco.

Canary expõe uma parcela do tráfego e amplia a exposição em etapas, por exemplo 5%, 25% e 100%. A distribuição precisa de um controlador ou proxy que suporte pesos; aumentar réplicas não garante uma divisão precisa de requisições entre versões.

O tamanho da amostra afeta a decisão. Cinco minutos com três requisições não demonstram segurança. Compare a candidata com a versão estável, observe um volume mínimo e defina limites de erro e latência; se faltarem dados, aguarde ou peça avaliação humana.

No laboratório blue/green, dois Deployments existentes usam app: cloudshop-api e o label slot com valores blue ou green. O Service seleciona um slot; mudar esse seletor altera os endpoints. O exemplo pressupõe autenticação e contexto Kubernetes já configurados.

Readiness e smoke test são complementares. rollout status só é significativo para disponibilidade quando o Deployment tem probes e limites adequados. Faça uma chamada funcional controlada antes e depois da troca, sem disparar cobranças reais no teste.

Rollback de aplicação não desfaz dados. Se uma migração remove uma coluna necessária pela versão anterior, trocar o tráfego de volta pode piorar o incidente. Prefira expandir o esquema, migrar o uso e remover o campo apenas em release posterior, após a janela de reversão.

A operação precisa de trilha e exclusão mútua. Registre digest, slot anterior, métricas e responsável pela promoção. Serialize deploys do mesmo ambiente com concurrency, evite desligar o slot antigo imediatamente e valide o serviço novamente após um rollback.

Na prática

Service para dois Deployments já existentes

yaml

apiVersion: v1
kind: Service
metadata:
  name: cloudshop-api
  namespace: cloudshop
spec:
  selector:
    app: cloudshop-api
    slot: blue # Cada Deployment deve ter seu próprio slot no template do Pod.
  ports:
    - port: 80
      targetPort: 3000
# Deployments cloudshop-api-blue e cloudshop-api-green devem ter readinessProbe.

Promover green com possibilidade de retorno explícito

bash

set -euo pipefail
# Execute em contexto de staging antes de repetir o procedimento em produção.
# Pré-requisito: green já implantado por digest e validado por smoke test direto.
kubectl -n cloudshop rollout status deployment/cloudshop-api-green --timeout=120s
ANTERIOR=$(kubectl -n cloudshop get service cloudshop-api -o jsonpath='{.spec.selector.slot}')
test "$ANTERIOR" = blue # Evita repetir a promoção sobre um estado inesperado.
# A troca afeta novas conexões após a propagação dos endpoints.
kubectl -n cloudshop patch service cloudshop-api --type=merge \
  -p '{"spec":{"selector":{"slot":"green"}}}'
# Valide métricas e smoke test via entrada real do ambiente antes de encerrar.
# Se os critérios de aborto forem atingidos, execute o retorno abaixo:
# kubectl -n cloudshop patch service cloudshop-api --type=merge \
#   -p '{"spec":{"selector":{"slot":"blue"}}}'
# Depois do retorno, confirme erros, latência e processamento de pedidos.

Por que isso importa

Entregas progressivas limitam o número de usuários afetados e tornam a decisão de rollback objetiva, não baseada em intuição.

Erro comum

Declarar sucesso só porque os Pods estão prontos ou supor que reverter a imagem também reverte migrações.

Dica de produção

Defina limites por serviço e uma janela de observação; preserve capacidade do slot anterior até encerrar a validação.

Alerta de segurança

Endpoints de teste e versões inativas também precisam de autenticação e políticas de rede; não exponha o slot green publicamente para facilitar validações.

Pergunta de entrevista

Quando você escolheria canary em vez de blue/green, e quais condições fariam abortar a promoção?

Glossário

blue/green
Estratégia com dois ambientes e troca do destino de tráfego entre eles.
canary
Liberação progressiva de uma versão para uma parcela controlada do tráfego.
smoke test
Verificação curta dos comportamentos essenciais após uma mudança.
readiness
Sinal de que uma instância está apta a receber tráfego.
expand/contract
Evolução de esquema que adiciona compatibilidade antes de remover estruturas antigas.

Conexão com o CloudShop

Planejar a entrega blue/green do CloudShop e ensaiar a troca de tráfego e o retorno com critérios documentados.

Quiz da aula

  1. 1. Qual característica define um canary?

  2. 2. Qual mudança ameaça um rollback de aplicação?

  3. 3. rollout status com sucesso comprova qual aspecto?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima