Implementação de Canary Deployments com Flagger e Prometheus

O desafio da estabilidade em sistemas distribuídos

Lançar novas versões de software em ambientes de produção modernos costuma ser um momento de tensão para equipes de engenharia. Na prática, isso significa que, mesmo com testes automatizados rigorosos, bugs sutis ou vazamentos de memória escapam para o ambiente real, afetando usuários finais. A arquitetura de microsserviços e o uso de Kubernetes, que é o sistema para gerenciar e escalar contêineres de software, multiplicam a complexidade das entregas.

Quando uma atualização falha, a reação tradicional costuma ser o resgate manual ou a reversão precipitada do sistema inteiro. Esse processo gera indisponibilidade e desgasta a confiança no ciclo de lançamento. Para resolver esse problema, a engenharia moderna adota estratégias de liberação progressiva, conhecidas como implantações canarinho, que testam o novo código em uma fração reduzida da base de usuários.

O conceito de Canary Deployments na prática

O termo canarinho remete aos antigos mineiros que levavam pássaros para detectar gases tóxicos nas minas antes que afetassem os humanos. Na computação, a ideia é idêntica: enviar uma pequena porcentagem do tráfego real para a versão nova do serviço enquanto a versão antiga atende ao restante. Na prática, se o novo código apresentar instabilidade, apenas um grupo minúsculo de usuários será afetado, contendo o dano instantaneamente.

Contudo, monitorar essa transição manualmente é inviável em sistemas com milhares de requisições por segundo. É aqui que entram ferramentas de automação baseadas em observabilidade. Em vez de confiar em olhares humanos fixos em painéis, a infraestrutura precisa coletar dados de telemetria em tempo real e tomar decisões autônomas sobre a saúde do serviço em execução.

Flagger e Prometheus: os guardiões da telemetria

O Flagger é um operador para Kubernetes, um software que roda dentro do aglomerado de servidores para automatizar o ciclo de vida das liberações canarinho. Ele funciona integrando-se a malhas de serviço ou controladores de entrada para manipular o tráfego de forma cirúrgica. Em essência, o Flagger atua como um maestro que ajusta os ponteiros de tráfego com base em regras estritas de desempenho.

Para saber se o sistema está saudável, o Flagger consulta o Prometheus, que é um sistema de monitoramento e banco de dados focado em coletar métricas numéricas de aplicações e servidores. O Prometheus armazena indicadores vitais, como a taxa de erros HTTP e a latência das requisições. O Flagger cruza esses dados com limites pré-definidos para decidir se a versão nova merece ganhar mais espaço ou ser descartada.

Arquitetura do fluxo de liberação progressiva

Quando um desenvolvedor atualiza a imagem de um contêiner no repositório, o sistema de integração contínua aplica a mudança no cluster. O Flagger detecta a alteração e automaticamente cria objetos secundários no Kubernetes, incluindo uma versão primária estável e a versão canarinho propriamente dita. Nesse momento, o tráfego ainda aponta inteiramente para o código antigo.

Em seguida, o operador inicia o ciclo de testes, incrementando o tráfego direcionado à versão canarinho em etapas controladas, geralmente de dez em dez por cento. A cada intervalo de tempo, o Flagger pergunta ao Prometheus se a taxa de erros continua abaixo de um limite aceitável, como um por cento. Se a métrica estourar o limite, o processo é abortado e o tráfego volta para a base segura.

Configuração passo a passo com Custom Resources

Para colocar essa lógica em funcionamento no Kubernetes, utilizamos recursos personalizados que definem o comportamento do Flagger. Abaixo está um exemplo de configuração que monitora a taxa de erro e a latência de um microsserviço web:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: meu-servico
  namespace: producao
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: meu-servico
  service:
    port: 80
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - api.exemplo.com
  analysis:
    interval: 30s
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 30s
    - name: request-duration
      thresholdRange:
        max: 500
      interval: 30s

Neste manifesto, configuramos um intervalo de trinta segundos para cada verificação. O Flagger aumenta o peso do tráfego canarinho em dez por cento a cada ciclo, até atingir o limite máximo de cinquenta por cento. Caso a taxa de sucesso caia abaixo de noventa e nove por cento ou a latência ultrapasse quinhentos milissegundos, o mecanismo executa o descarte automático da versão.

Considerações operacionais e conclusão

Implementar entregas canarinho baseadas em telemetria elimina o fator humano e a intuição dos processos de lançamento, substituindo-os por dados objetivos. Na prática, isso significa que as equipes ganham velocidade sem abrir mão da segurança operacional. O Flagger e o Prometheus formam uma dupla robusta que automatiza a vigilância e protege a experiência do usuário final contra regressões inesperadas em produção.

Em suma, a adoção dessa arquitetura transforma o deploy de um evento estressante e manual em uma rotina transparente e resiliente. Ao confiar em métricas reais para guiar a promoção de código, as organizações constroem sistemas capazes de se autoproteger e manter alta disponibilidade sob qualquer circunstância.