Sistema de deploy de código

01 · CONTEXTO E REQUISITOS

O que um sistema de deploy precisa garantir

Um sistema de deploy leva uma versão já construída até as máquinas que atendem os usuários. O desenho define como cada máquina recebe a mudança e como o sistema volta atrás se algo der errado. É um tema de padrões de disponibilidade.

Na experiência do Google, a maioria dos incidentes é provocada por envios de binários ou de configuração. Se uma release é implantada instantaneamente em todo lugar, os defeitos também são.

Os princípios de engenharia de release do workbook de SRE incluem deploys feitos por computadores, e não por pessoas, e artefatos com mudanças pequenas e autocontidas. Artefatos menores tornam a reversão mais barata e fácil.

02 · DO COMMIT AO PACOTE

A esteira de build e o repositório de pacotes

Segundo o livro de SRE do Google, os builds são herméticos: não dependem das bibliotecas e outros softwares instalados na máquina de build. A expectativa é que duas pessoas que compilam a mesma revisão em máquinas diferentes obtenham resultados idênticos.

1. A mudança entra na esteira, que cria uma branch de release a partir de uma revisão de integração escolhida, muitas vezes obtida do sistema de testes contínuos.

2. O build compila os binários e executa os testes unitários, muitas vezes em paralelo.

3. O resultado vira um pacote versionado com um hash único e assinado, para garantir a autenticidade.

4. Rótulos no pacote indicam em que ponto do processo de release ele está, como dev, canary ou production.

5. Também se gera um relatório de todas as mudanças desde a última release.

6. O processo de rollout pode implantar um novo binário em clusters sucessivos ao longo de várias horas.

No livro de SRE do Google, um rollout é uma unidade lógica de trabalho composta de uma ou mais tarefas individuais. Um deploy canário típico, ainda segundo o livro, inicia alguns jobs em produção depois dos testes de sistema.

03 · ESTRATÉGIAS DE ROLLOUT

Rolling, blue/green e canário

O objetivo do Google é ajustar o processo de deploy ao perfil de risco do serviço. Em serviços grandes voltados ao usuário, pode-se começar por um cluster e expandir exponencialmente até atualizar todos. Para infraestrutura sensível, o rollout pode se estender por vários dias, intercalando instâncias de regiões geográficas diferentes.

1. O serviço de deploy provisiona instâncias para o ambiente de substituição.

2. A última revisão da aplicação é instalada nas instâncias de substituição.

3. Há um tempo de espera opcional para atividades como teste da aplicação e verificação do sistema.

4. As instâncias de substituição são registradas no balanceador, o que redireciona o tráfego para elas; as do ambiente original são desregistradas e podem ser encerradas ou mantidas.

5. Se algo der errado, o CodeDeploy reverte reimplantando uma revisão implantada anteriormente; tecnicamente, a reversão é um novo deploy.

No Kubernetes, o Deployment em modo RollingUpdate reduz gradualmente os ReplicaSets antigos e aumenta o novo, e maxUnavailable e maxSurge controlam o processo. O controlador interrompe sozinho um rollout ruim, o que depende de maxUnavailable, cujo padrão é 25%.

Em ECS, o CodeDeploy permite deslocar o tráfego com configuração canary, linear ou all-at-once. Uma das predefinidas desloca 10 por cento do tráfego no primeiro incremento e os 90 por cento restantes cinco minutos depois.

04 · CANÁRIO NA PRÁTICA

Como montar e avaliar um canário

Um canário exige três capacidades: implantar a mudança em um subconjunto da população do serviço, avaliar se a mudança é boa ou ruim e integrar essa avaliação ao processo de release.

1. O orquestrador implanta o candidato em apenas um subconjunto da população do serviço.

2. O divisor de tráfego envia uma pequena parte do tráfego ao candidato e compara com o controle; a divisão pode usar pesos num balanceador, proxy ou DNS round-robin.

3. No total, o defeito mal aparece. A métrica-chave (no exemplo do livro, os códigos de resposta HTTP) precisa ser lida por versão.

4. No exemplo, o candidato serve a grande maioria dos erros. Com 20% de erros em 5% do tráfego, o erro geral fica em 1%.

5. Se a taxa de erro do canário está longe demais da do controle, isso sinaliza um canário ruim, e a resposta é pausar e reverter o deploy, ou chamar uma pessoa para investigar.

6. Se as taxas de erro são parecidas, o deploy segue normalmente, e o processo ganha confiança à medida que expõe a mudança a mais tráfego.

Para escolher o que medir, o workbook recomenda partir dos SLIs. No serviço do exemplo, as melhores métricas provavelmente são os códigos HTTP e a latência da resposta. Se a definição de comportamento aceitável é rígida demais, haverá muitos falsos positivos; se é frouxa demais, é mais provável que um canário ruim passe sem ser detectado.

Um canário representativo exige decisões em muitas dimensões. Quem implanta continuamente, por exemplo 20 vezes por dia, precisa de uma duração de canário bem menor, e defeitos de desempenho costumam se manifestar só sob carga alta.

05 · REVERSÃO E CONFIGURAÇÃO

Voltar atrás sem criar um segundo problema

O CodeDeploy reverte reimplantando uma revisão implantada anteriormente. Tecnicamente, os deploys revertidos são novos deploys. Deploy ou grupo pode ser configurado para reverter automaticamente quando o deploy falha ou um limite de monitoramento é atingido, e então se implanta a última versão boa conhecida.

No Kubernetes, por padrão 10 ReplicaSets antigos são mantidos. Apagado um ReplicaSet antigo, perde-se a capacidade de reverter para aquela revisão.

Frameworks de feature flag permitem separar o lançamento de funcionalidades da release do binário, e as funcionalidades de um binário podem ser habilitadas uma a uma pela configuração do experimento. No Google, gerar um pacote para o binário e outro para a configuração permite alterar cada um de forma independente.