fix(proxy): app não perde a rede do NPM numa atualização - #733
fix(proxy): app não perde a rede do NPM numa atualização#733satomiflavio wants to merge 1 commit into
Conversation
Incidente real em 2026-09-11: uma instalação atrás de Nginx Proxy Manager tinha a rede do `app` plugada à mão (`docker network connect`). A primeira recriação do contêiner (deploy, `update.sh`) perdeu essa conexão e o domínio voltou a responder 502, com o app `healthy` — o healthcheck é TCP interno e não sabe nada de roteamento. docker-compose.npm.yml (novo) faz pro NPM o que docker-compose.traefik.yml já fazia pro Traefik: fixa o `app` na rede/IP que o Proxy Host espera e desliga o Caddy por profile. docker-compose.yml (WAHA local) entra na mesma rede compartilhada, já que nesta VPS o dashboard do WAHA também sai pelo NPM. Faltava o fio até o kit: REVERSE_PROXY=npm agora é um terceiro valor de primeira classe em dc()/dc_files() (install.sh e _common.sh, gêmeas), com guarda de rede ausente em garantir_rede_do_proxy (mesmo cuidado que o Traefik já tinha) e sem o bug de reativar o Caddy por engano que o force-recreate por nome já causava pro Traefik — sem isso REVERSE_PROXY=npm silenciosamente caía no branch do Caddy em ambos os pontos, reproduzindo o incidente na primeira atualização. Testado com sabotagem: revertida a mudança em _common.sh/update.sh, 4 dos 8 casos novos de test-validators.sh caíram nos pontos exatos (dc_files, guarda de rede, integração de rede sumida, guarda do Caddy), confirmando que os testes vigiam o comportamento e não só a presença do símbolo. Suíte restaurada e verde (bash hostgator-setup-kit/test-validators.sh + os 6 demais scripts de tests/shell/, que compõem pnpm test:shell). Configuração inicial (REVERSE_PROXY=npm, PROXY_NETWORK_NAME, PROXY_NETWORK_APP_IP) continua manual — NPM não fala por labels como o Traefik — documentada no cabeçalho de docker-compose.npm.yml. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Ja8SghdefMR1UqtT3TePw
|
Someone is attempting to deploy a commit to the rafael-maudibrasil's projects Team on Vercel. A member of the Team first needs to authorize it. |
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 7 changed file(s). No missing scanner-evidence signal was detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy review recommended (neutral) Detected 1 PR taxonomy bucket(s): CI/CD Recommendation. Scanned 7 changed file(s). Roadmap taxonomy buckets: CI/CD RecommendationCI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work. Signals:
Paths:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 7 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 7 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
Recebido, @satomiflavio — obrigado por isto. Duas coisas que vão parecer erro seu e não são:
Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem |
Problema
Instalações que ficam atrás de um Nginx Proxy Manager (em vez do Caddy do
próprio kit ou de um Traefik) precisam plugar o contêiner
appna rede doNPM manualmente (
docker network connect). Isso se perde na primeiraatualização:
update.shrecria oapp, a conexão manual some, e o domíniovolta a responder 502 — mesmo com o contêiner
healthy(o healthcheck é umprobe TCP interno, não sabe nada de roteamento). Aconteceu numa instalação
real em 2026-09-11.
Correção
docker-compose.npm.yml(novo): fixa oappna rede/IP que o Proxy Hostdo NPM espera, do mesmo jeito que
docker-compose.traefik.ymljá faz parao Traefik; desliga o Caddy por profile.
REVERSE_PROXY=npmentra como terceiro valor de primeira classe emdc()/dc_files()(install.she_common.sh).garantir_rede_do_proxyganha a guarda para NPM: se a rede sumiu (ex.:docker network prune), a atualização para com uma mensagem explicando oque fazer, em vez de travar no erro opaco do Docker.
hostgator-setup-kit/test-validators.sh(já plugado empnpm test:shell), cobrindo o caso de rede ausente e o de nunca recriar oCaddy por engano.
Prova
Simulei uma atualização real (
docker compose -f docker-compose.prod.yml -f docker-compose.npm.yml up -d --force-recreate app) numa instalação com essaconfiguração. Depois de recriado, o contêiner permaneceu automaticamente na
rede do NPM, no mesmo IP que o Proxy Host espera — sem nenhuma reconexão
manual — e ficou
healthy.Fragmento de release em
.changes/proxy-npm-sobrevive-atualizacao.md(
capacidade_nova).🤖 Generated with Claude Code
https://claude.ai/code/session_01TuEmS372yStRXYvvaGFqpY