50 lines
3.6 KiB
Markdown
50 lines
3.6 KiB
Markdown
# Relatório de Diagnóstico e Pontos de Dor (Pain Points)
|
|
|
|
Este documento sumariza os problemas arquiteturais e técnicos identificados durante a tentativa de estabilizar o stack `nginx-pathfinder-proxy`. O objetivo é fornecer um contexto claro para um futuro Agente de IA simplificar a solução.
|
|
|
|
## 1. Arquitetura Excessivamente Complexa (Split Container)
|
|
Atualmente, temos dois containers NGINX separados:
|
|
1. **Frontend (`modsecurity`)**: Recebe a internet, faz WAF, termina SSL.
|
|
2. **Backend (`nginx-proxy`)**: Recebe do WAF, faz roteamento, gerencia certificados (Certbot), roda scripts.
|
|
|
|
**Problemas Causados:**
|
|
- **Inferno de Permissões (Permission Hell):** O Backend (onde roda o Certbot) gera certificados no volume compartilhado como `root`. O Frontend tenta ler esses arquivos e falha com `Permission denied` porque roda com outro UID/GID. Tentar corrigir com `chmod` é frágil e inseguro.
|
|
- **Configuração Duplicada:** É preciso configurar o Nginx duas vezes. Uma no Frontend (para saber onde estão os certs) e uma no Backend (para saber como tratar a requisição na porta 8080).
|
|
- **SSL "Ping-Pong":** O Backend gerencia a renovação, mas o Frontend é quem *usa* o certificado. Isso exige reload sincronizado em dois containers diferentes.
|
|
|
|
## 2. Problema do "Ovo e a Galinha" (SSL Bootstrap)
|
|
- O NGINX **não sobe** se o arquivo de certificado não existir.
|
|
- O Certbot **não gera** o certificado se o NGINX não estiver rodando (para responder o desafio HTTP-01).
|
|
- **Solução Atual (Gambiarra):** Criamos um script complexo (`pre-flight.sh` + `renew_ssl.sh`) que gera certificados falsos (self-signed) só para o NGINX subir, e depois tenta baixar os reais. Isso adiciona muita lógica propensa a falhas.
|
|
|
|
## 3. Fragilidade de Deploy (Portainer / Docker)
|
|
- **Mount Error:** O Portainer falha ao tentar montar arquivos de configuração (`modsec_conf/...`) que ainda não foram baixados pelo git no host.
|
|
- **Solução Atual:** Tivemos que "assar" (bake) as configurações dentro da imagem Docker (`COPY conf.d ...`). Isso tira a agilidade de alterar uma config no git e dar deploy rápido; agora exige rebuild da imagem.
|
|
|
|
## 4. Scripts de Automação Frágeis
|
|
- O script `pre-flight.sh` tenta fazer `git clone/pull` dentro do container. Isso gera erros de "Resource busy" quando tenta limpar pastas montadas via volume.
|
|
- Lógica de `sed/grep` para ler arquivos `.conf` e achar domínios é suscetível a erros de sintaxe no arquivo de config.
|
|
|
|
---
|
|
|
|
# Recomendação de Simplificação (Para o Próximo Agente)
|
|
|
|
### Opção A: Single "Super" Container (Recomendada)
|
|
Unificar tudo em um único container.
|
|
- **Base:** Usar a imagem oficial com ModSecurity já compilado (ou compilar num multi-stage build).
|
|
- **Benefício:** Resolve problemas de permissão (mesmo processo lê e escreve). Resolve problema de setup (um único serviço). Remove complexidade de rede (sem proxy pass interno desnecessário).
|
|
|
|
### Opção B: Caddy Server (Radical)
|
|
Substituir NGINX + Certbot por **Caddy**.
|
|
- **Benefício:** Caddy tem HTTPS automático (resolve o problema do Ovo/Galinha nativamente).
|
|
- **WAF:** Existe plugin de WAF para Caddy (Coraza), mas exige validação se atende os requisitos de segurança do Oestepan.
|
|
|
|
### Opção C: NGINX Proxy Manager (GUI)
|
|
Usar uma solução pronta como NGINX Proxy Manager.
|
|
- Tem interface web.
|
|
- Gerencia SSL sozinho.
|
|
- Pode ser difícil integrar ModSecurity customizado.
|
|
|
|
### Resumo do Pedido de Refatoração
|
|
> "Simplificar a infraestrutura eliminando a separação Frontend/Backend. Criar um container único que faça WAF + Proxy + SSL Management, eliminando scripts complexos de bootstrap e problemas de permissão de volume."
|