APRENDER. PRATICAR. EVOLUIR.Separar candidato, processo ativo e resultado
A experiência começa com o grupo de retirada a apontar apenas para A. O runner altera o ficheiro para B e executa nginx -t com o prefixo e configuração isolados. O comando termina com zero, mas o pedido seguinte ainda chega a A porque o sinal de reload não foi enviado. Esta observação torna concreta a diferença entre candidato válido e alteração aplicada. Num plano de mudança, guarda qual ficheiro foi validado, a ação de aplicação e a evidência de que o processo ativo usa o destino esperado.
Construir uma observação de transição
Antes de aplicar a mudança, o runner inicia um pedido longo que A mantém pendente através de um evento de sincronização. Depois envia HUP apenas ao master criado para este laboratório e faz novos pedidos até observar B. Nesse instante, verifica que o pedido antigo ainda não terminou. Só então liberta A e confirma que o pedido antigo termina com 200 e corpo A. A sequência mostra dois resultados necessários: os pedidos novos alcançam o destino novo e o trabalho anterior consegue concluir no destino de origem.
Transformar a observação em critério de retirada
Para um relatório longo numa janela de fim de semana, um health check verde em B não autoriza por si a paragem de A. Identifica pedidos pendentes, responsáveis e tempo disponível. Se o trabalho não termina, define quem decide esperar, interromper ou reconciliar uma repetição, considerando efeitos e impacto. O laboratório liberta voluntariamente um pedido e não testa um pedido infinito nem estabelece o prazo de negócio. Também não valida draining de HAProxy, Kubernetes ou AWS. Cada plataforma precisa de critérios e observações próprios para a transição real.
Descrever com rigor uma validação negativa
O último candidato acrescenta uma diretiva inexistente. nginx -t falha e o runner não envia HUP; um novo pedido continua a receber B. O resultado prova que a validação impediu a tentativa de aplicação no procedimento usado. Não prova rollback automático de um reload executado, porque esse reload não ocorreu. A distinção importa num relatório de mudança: indica a etapa em que houve falha e quais ações foram realmente realizadas. Uma descrição rigorosa ajuda a equipa seguinte a reproduzir a barreira e a não assumir controlos que não foram exercitados.
Conservar uma reprodução com âmbito explícito
A evidência guarda a versão, opções de compilação, configurações, comandos, eventos, logs e hash do runner. A aquisição usa o arquivo no endereço HTTPS oficial; o checksum calculado identifica os bytes recebidos, sem verificação independente de checksum ou assinatura PGP. A build local exclui TLS, rewrite e gzip, e não foi instalada como serviço do sistema. O ensaio usa portas efémeras em loopback e elimina os diretórios temporários. Para reproduzir noutro ambiente, fornece o binário e os metadados próprios, mantendo essa separação entre configuração e recursos locais.
Fechar a mudança com duas provas operacionais
No handover fictício, apresenta primeiro a prova de encaminhamento novo e depois a conclusão do pedido antigo. Acrescenta os limites: um worker, HTTP local, servidores sintéticos, nenhum teste de carga ou serviço de produção. Se a aceitação real exige autenticação, TLS, autorização ou conteúdo de relatório, acrescenta testes representativos desses requisitos antes de declarar a mudança concluída. O resumo desta aula é simples: validar prepara a aplicação, aplicar altera o processo e aceitar exige observar o resultado funcional e o trabalho que ainda dependia da configuração anterior.
# From the project root; provide your local binary and build record
python3 content/labs/lb-upstream/run.py --nginx /path/to/nginx --build-metadata /path/to/build.json --output /tmp/lb-evidence.json
# gracefulReload: beforeSignalBackend A; newConnectionBackend B
# oldRequestPendingWhenBObserved true; oldRequestCompletion A
# invalidCandidate: validation failed, reloadSignalSent falseCaso fictício: um relatório continua em A durante a mudança para B. A equipa confirma novos pedidos em B, espera a conclusão acordada do relatório e só depois retira A.
Armadilhas comuns
Tratar nginx -t como reload, desligar o backend antigo após um único 200 novo, ou chamar rollback a um candidato que nunca foi aplicado.
Tópicos relacionados: Health checks e prontidão · Retries, limites e origem do cliente · Retirada, release e operação
A mudança só tem evidência suficiente quando o destino novo funciona e o trabalho antigo recebeu o tratamento previsto. Regista ações executadas e limites da prova.
Referência: Controlling NGINX · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior