JLJoão Lorenzo
ENPT

Trabalhos / Deploys sem downtime

Deploys sem downtime, várias vezes por dia

Releases blue-green com Docker, GitHub Actions e nginx, usados por todos os produtos que eu lidero, com deploys várias vezes por dia.

Papel
Projetei e implantei em todos os produtos
Período
2025 — atual
Contexto
Cinco serviços em produção, em três produtos
Stack
Docker, GitHub Actions, nginx, PostgreSQL, Redis

O problema

Antes disso, alguns serviços reiniciavam no próprio servidor a cada release, então cada deploy era uma pequena queda, e o time esperava a noite para publicar.

O objetivo era simples: deploys seguros o bastante para rodar numa terça à tarde sem ninguém perceber, e uma release com problema que nunca chega aos usuários.

Como funciona um release

Deploy blue-green em um VPSO GitHub Actions gera uma imagem e envia para o servidor. O nginx manda o tráfego dos usuários para o slot ativo, green, enquanto o slot blue mantém a versão anterior em espera. Os dois slots usam o mesmo PostgreSQL. Um único worker roda as filas e as rotinas agendadas.GitHub Actionsbuild · testes · imagemimagem DockerVPSUsuáriosHTTPSnginxupstreamgreen · v42no ar · health gate okblue · v41em espera · versão anteriorWorkerfilas · crons · únicoPostgreSQLexpand / contract
Role →Depois de um release: o green roda a versão nova e recebe o tráfego; o blue mantém a anterior.
  1. Build. O GitHub Actions valida o pull request, gera a imagem Docker e envia para o servidor.
  2. Subir o slot livre. A versão nova sobe no slot que não está recebendo tráfego, ao lado do que está no ar.
  3. Health gate. O slot novo precisa passar no health check. Se não passar, nada muda e os usuários nunca veem a release com problema.
  4. Trocar. O nginx recarrega com o slot novo como upstream. As requisições em andamento terminam no slot antigo.
  5. Avisar. O resultado vai para o Discord do time.

O que não pode ser blue-green

Rodar duas versões lado a lado é a parte fácil. O trabalho de design de verdade está nas peças que nunca podem rodar duas vezes, ou que precisam funcionar com as duas versões ao mesmo tempo.

  1. Migrations de banco

    As migrations seguem expand e contract: primeiro adiciona, e só remove depois que nenhuma versão no ar depende do formato antigo. Durante a troca, o código antigo e o novo rodam sobre o mesmo schema.

  2. Workers e rotinas agendadas

    Os workers de fila e os crons rodam como instância única e não são duplicados. As filas são pausadas por um endpoint durante a troca, para nenhum job ser processado duas vezes. As rotinas financeiras ficam num worker dedicado, então existe exatamente um escritor.

  3. Conexões com estado

    O gateway de mensagens mantém conexões de longa duração que só um processo pode ter por vez, então ele nunca roda duas vezes. Reinicia de forma graciosa em vez de usar blue-green.

    Trade-offAlguns segundos de reconexão nesse serviço, em troca de nunca ter dois processos disputando a mesma conexão.

Em volta do deploy

  • Backups diários do PostgreSQL no S3, com versionamento, regras de retenção e credenciais de privilégio mínimo.
  • Um contrato de health check único para os serviços da plataforma de IA. Um WhatsApp desconectado de um cliente nunca deixa o status da plataforma vermelho.
  • Dependabot e validação de pull request em todos os repositórios principais.

Resultado

Deploy deixou de ser um evento. Os cinco serviços em produção passam pelo mesmo processo, várias vezes por dia, em horário comercial, e uma release com problema para no health gate em vez de chegar aos usuários.

A frequência de deploys vem do histórico do GitHub Actions dos cinco serviços em produção. Detalhes dos servidores não são divulgados.