Implantações in-place e blue/green

Automatizando implantações na AWS

Dunieski Otano

Amazon Web Services Solutions Architect

A queda das 2h da manhã

• Deploy de uma vez dá errado
• Todo servidor roda a versão quebrada
• Clientes veem erros por uma hora
• Rollback requer outro deploy completo

Por que a estratégia de deploy importa

• Um release ruim pode derrubar o serviço
• Tudo de uma vez = mais rápido, mais arriscado
• Gradual = mais lento, mais seguro
• A estratégia limita o raio de impacto se falhar

Implantações in-place

• Deploy nas mesmas instâncias que atendem o tráfego
• Um lote por vez: metade, depois metade; ou uma a uma
• Health-check de cada lote antes de seguir
• Barato; sem infraestrutura extra

Implantações blue/green

• Blue = frota atual em produção
• Green = nova frota com a nova versão
• O load balancer desvia o tráfego de blue para green
• A frota antiga permanece disponível para rollback rápido

Lambda e ECS são blue/green por design

• Lambda: tráfego muda via ponteiro de versão de alias
• ECS: tráfego muda via replacement task set
• Sem duplicar frotas no estilo EC2
• Você ainda escolhe uma configuração de deploy

Escolhendo entre in-place e blue/green

• Orçamento apertado, patch de baixo risco → in-place
• Precisa de zero downtime ou rollback instantâneo → blue/green
• Servidor legado único → in-place é a única opção
• Lambda ou ECS → blue/green é nativo

Rollback no CodeDeploy

• Rollback = reimplantar a revisão anterior bem-sucedida
• Acionar automaticamente em falha de deploy
• Acionar automaticamente em alarme do CloudWatch
• Blue/green rollback: voltar o load balancer

Vamos praticar!

Automatizando implantações na AWS