Blue Green Deployment na Prática

A Topologia dos Ambientes Gêmeos: Blue vs. Green

No desenvolvimento de sistemas web de alta performance ou ao gerenciar a evolução de produtos SaaS complexos, depender de atualizações baseadas em substituições diretas de arquivos em disco (*In-place Deployments*) expõe a corporação a severos prejuízos comerciais. Se o processo de boot da linguagem falhar por quebras lógicas de tipos de variáveis ou estouros de memórias, o sistema web sai do ar, paralisando a captura de leads qualificados em landing pages e interrompendo faturamentos contábeis.

A topologia elástica do Blue-Green Deployment neutraliza esse engessamento técnico separando fisicamente o ciclo de vida das runtimes do software através de dois blocos lógicos de hardware idênticos na nuvem:

• O Bloco Blue (Ativo/V1): É a cerca estável produtiva de faturamentos vigente. Ele hospeda os contêineres Docker estáveis, os caches em memórias RAM (**Redis**) e consome a porta de tráfego mestre da aplicação, sustentando os canais lícitos de vendas online.
• O Bloco Green (Inativo/V2): É a cerca ociosa temporária. Durante o ciclo de deploy avançado, a esteira de CD realiza o build e a injeção do novo código de forma totalmente opaca e oculta para a internet pública. Ele serve como o laboratório físico real de runtime para testes de fumaça (*Smoke Tests*).

O Coração da Virada: Configurando Roteamento Dinâmico no Nginx

O chaveamento de redes sem picos de indisponibilidades (*Zero-Downtime*) assenta-se sobre a capacidade do proxy de borda reverso e balanceador de carga em redirecionar fluxos Server-to-Server alterando apenas arquivos de apontamentos leves, sem disparar recargas pesadas que limpam as sessões de hardware de runtime.

O design de elite executa essa manobra configurando o **Nginx** de forma estruturada, utilizando a inclusão de arquivos de mapeamentos de variáveis estáticas lógicas:

# Arquivo Principal de Bordas: /etc/nginx/sites-available/stackflow-proxy.conf
upstream backend_blue {
    server 10.0.1.10:8080; # Endereço IP privado do Cluster Blue na VPC
    server 10.0.1.11:8080;
}

upstream backend_green {
    server 10.0.2.10:8080; # Endereço IP privado do Cluster Green na VPC
    server 10.0.2.11:8080;
}

# Inclusão do ponteiro dinâmico que dita a cor ativa (Gera isolamento de arquivos)
include /etc/nginx/conf.d/cor_ativa.map;

server {
    listen 443 ssl http2;
    server_name api.stackflow.com.br;

    # Hardening de Criptografias Fortes em Trânsito (TLS 1.3)
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    location / {
        # Roteia de forma elástica consumindo a variável declarada no mapa externo
        proxy_pass http://$target_env;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_timeout 15s;
    }
}

O segredo da agilidade do SRE reside no arquivo complementar de mapeamento /etc/nginx/conf.d/cor_ativa.map. Para apontar as redes públicas para a versão antiga Blue, o arquivo simplesmente declara a string: split_clients $remote_addr $target_env { default backend_blue; }.

Quando a esteira de CD chancela a saúde das Warm Starts do ambiente Green V2, um script automatizado Server-to-Server reescreve atomicamente esse arquivo em disco rígido trocando a string para backend_green e dispara o comando **nginx -s reload**. O Kernel do Linux chaveia as conexões TCP remanescentes de forma linear imediata, com toques zerados em mídias físicas e sem quedas de sockets.

A Orquestração do Banco de Dados: O Padrão Expand and Contract

Chavear as runtimes do backend via proxies de bordas é simplificado. Contudo, o verdadeiro engessamento e o maior gargalo de engenharia de software reside na camada persistente de dados: o **Banco de Dados Relacional SQL (OLTP)** de produção (PostgreSQL, MySQL), visto que ambas as cercas Blue e Green consomem de forma simultânea paralela a mesma instância de dados mestre.

Se a nova versão V2 exige fatiar ou alterar o tipo primitivo de uma coluna operacional e a esteira roda uma Database Migration tradicional destrutiva, as instâncias Blue V1 que continuam ativas recebendo tráfego nas sub-redes privadas sofrem picos de incidentes operacionais de TI por conflitos de schemas lógicos. A engenharia sênior quebra esse acoplamento aplicando de forma mandatória o padrão de projeto **Expand and Contract (Expandir e Contrair)**:

1. A Fase de Expansão (Expand Phase): A migration **nunca altera ou remove componentes vigentes**. Se uma chave de e-mail precisa mudar de nome, injeta-se a nova coluna aceitando nulos. O código backend da V2 nasce com a inteligência de **gravar duplicado em ambas as colunas**, mas continua lendo a antiga, garantindo a *Retrocompatibilidade (Backward Compatibility)* absoluta.
2. A Fase de Transição (Backfill): Um job assíncrono em segundo plano ou barramento de fila (Horizon/RabbitMQ) varre as tabelas do banco relacional copiando os dados históricos textuais das strings antigas preenchendo as colunas novas, sem travar picos de IOPS em discos.
3. A Fase de Contração (Contract Phase): Concluída a virada mestre de tráfego do Nginx e após o completo desligamento e expurgo de todas as instâncias Blue V1 das sub-redes, dispara-se uma nova migration de limpeza para **deletar e expurgar a coluna obsoleta** do disco, higienizando as tabelas (Autovacuum), otimizando faturamentos cloud de armazenamentos (FinOps).

Estratégias de FinOps e Automação de Infraestrutura elástica

Manter duas infraestruturas elásticas completas de hardware de produção rodando de forma ininterrompida em paralelo na nuvem pública sabota os balanços financeiros de Revenue Operations (RevOps) e viola premissas de **FinOps (Eficiência Financeira Cloud)** devido ao desperdício de capitais com servidores ociosos.

Times ágeis maduros resolvem o passivo de custos integrando ferramentas declarativas IaC (**Terraform**) aos pipelines de automações contínuas:

Segurança da Informação, DevSecOps e Perímetros da LGPD por Código

Centralizar, cruzar e relacionar grandes volumes de dados lógicos contendo Informações Pessoais Identificáveis (PII) de clientes (Nomes, e-mails corporativos, CPFs, faturamentos cadastrais de marcas) através de múltiplos ambientes paralelos síncronos de chaveamentos de tráfegos sem perímetros severos de segurança da informação cria graves riscos que violam as sanções da LGPD no Brasil. Como a empresa herda responsabilidades jurídicas solidárias civis na nuvem, o conceito de *Privacy por Design* deve capitanear os manifestos.

A esteira de DevSecOps deve consolidar três linhas de defesas de Hardening ativas no Blue-Green Deployment:

• Cofres de Segredos Digitais Isolados (No Clear Text Secrets): Chaves de APIs privadas de CRMs ou senhas de conexões de bancos operacionais **nunca devem constar gravadas textualmente em texto limpo nos arquivos de manifestos do Git** ou em variáveis estáticas de imagens de contêineres Docker. Aloque os segredos em cofres digitais elásticos (AWS Secrets Manager ou HashiCorp Vault). O pipeline CD colhe as chaves de formas Server-to-Server via chaves autenticadas do IAM e as injeta exclusivamente em variáveis de memórias RAM temporárias de runtime das instâncias, isolando as sub-redes, aplicando o privilégio mínimo.
• Isolamento em Sub-redes Privadas (VPC Zero-Trust): Ambas as cercas de hardware Blue e Green devem residir totalmente ocultas e invisíveis para a internet pública, confinadas em sub-redes opacas trancadas dentro de uma **VPC Privada**. O tráfego público de usuários externos deve ser barrado de fábrica na velocidade de hardware pelo firewall de aplicação (**WAF**) acoplado à frente do Nginx, mitigando de fábrica tentativas de injeções lógicas de SQL ou scripts piratas do OWASP Top 10 antes de atingir o coração do software.
• Trilhas de Logs de Auditoria Imutáveis e OpenTelemetry: Todo chaveamento de rotas de redes na borda do Nginx, volumetrias transacionais por ambientes ou alterações de permissões de deploys de chaves executadas pelas esteiras de CI/CD deve catalogar metadados analíticos detalhados consistentes e hashes de rastreabilidades com carimbos de data/hora (Timestamp) universais. Direcionar os logs de execuções automaticamente fora dos servidores de desenvolvimentos para barramentos externos imutáveis indexados pelas ferramentas do **OpenTelemetry, Prometheus e Grafana** confere controle analítico absoluto à alta liderança e fornece provas jurídicas materiais irrefutáveis de governança técnica em fiscalizações regulatórias da ANPD (Direito ao Esquecimento).