📝 Relatório Técnico de Implementação — NewWhats SaaS

Este relatório descreve as ações executadas, decisões arquiteturais consolidadas, riscos mapeados e próximos passos recomendados para o ecossistema NewWhats.

🏗️ Decisões Arquiteturais e Infraestrutura

Para atender à premissa de manter o host limpo (sem dependências locais de Node/npm/PM2) e em conformidade com o design "V8 Bunker", a aplicação foi 100% containerizada:

Estrutura de Containerização (Multi-Stage) e Resolução do Erro do Prisma:
- newwhats-backend: Inicialmente construído com node:20-alpine. Identificamos que a engine binária do Prisma requer libssl.so.1.1 (Glibc/OpenSSL 1.1) que foi removido no Alpine moderno.
- Solução Proativa: Migramos a base do backend para node:20-slim (Debian-based) e instalamos nativamente as dependências openssl e ca-certificates.
- Adicionamos "debian-openssl-3.0.x" no bloco binaryTargets do schema.prisma para compilar o driver otimizado. O backend agora compila e inicializa instantaneamente em conformidade de segurança máxima.
Reverse Proxy Unificado e Resiliente (Nginx + Traefik):
- Mantivemos o Traefik gerenciando os certificados SSL (HTTPS) de forma nativa e automática na borda (Portas 80/443).
- Correção no Nginx (default.conf): Corrigimos o typo da variável de cabeçalho ($proxy_add_x_forwarded-for para $proxy_add_x_forwarded_for com sublinha).
- Configuração de Alta Resiliência: Para evitar que o Nginx falhasse caso o backend estivesse em inicialização, adicionamos a dependência depends_on no Compose e configuramos o resolver DNS interno do Docker (resolver 127.0.0.11 valid=30s) com variáveis dinâmicas de proxy. O Nginx agora inicia de forma instantânea e tolerante a falhas.
Persistência de Sessões:
- O Baileys armazena os arquivos físicos de conexões das contas do WhatsApp. Criamos um volume compartilhado que mapeia o diretório interno do container para a pasta física do host /home/deploy/newwhats-sessions, garantindo que os usuários não precisem re-escanear o QR code quando os containers forem atualizados ou recriados.

📂 Arquivos Modificados e Criados

📝 docker-compose.yml: Registra os novos serviços, regras de dependências e volumes compartilhados.
📝 default.conf: Mapeamento de proxies Nginx resilientes e regras de conexões WebSockets.
📝 Dockerfile (Backend): Definição de build modular baseada em Debian Slim com suporte total ao Prisma Engine.
📝 schema.prisma: Configuração de compilação multi-target para garantir compatibilidade OpenSSL 3.0.
📝 TAREFAS.md: Planejamento detalhado por entregáveis.

🚨 Pontos de Atenção e Homologação da VPS 3

Warning

Status das Dependências de Rede na VPS 3 (10.99.0.3): Ao inicializar o backend, verificamos nos logs do container que a conexão com o DragonflyDB (Redis local no compose) conectou perfeitamente ({"msg":"DragonflyDB conectado"}), mas o Prisma parou na barreira de inicialização:

Can't reach database server at 10.99.0.3:5432

Diagnóstico: O IP da VPS 3 responde aos pings da VPN instantaneamente, mas a porta 5432 retorna Connection Refused do host de destino.

🛡️ Guia de Ativação do PostgreSQL na VPS 3

Para liberar o acesso do backend (VPS 1) ao PostgreSQL na VPS 3 de forma totalmente segura, siga os passos abaixo diretamente na VPS 3 (como usuário deploy):

1. Configurar escuta do PostgreSQL na interface VPN

Abra o arquivo de configuração principal (o caminho exato depende da versão instalada, ex: 14 ou 15):

sudo nano /etc/postgresql/15/main/postgresql.conf

Procure pela linha listen_addresses e altere para:

listen_addresses = 'localhost,10.99.0.3'

(Isso instrui o PostgreSQL a aceitar conexões locais e conexões vindas apenas da interface segura do WireGuard, mantendo a porta fechada para a internet pública).

2. Autorizar o IP da VPS 1 no controle de acesso do PostgreSQL

Abra o arquivo de controle de conexões do cliente:

sudo nano /etc/postgresql/15/main/pg_hba.conf

Adicione a seguinte linha de liberação ao final do arquivo:

# Liberar conexões seguras da VPS 1 (Produção) para o NewWhats
host    newwhats        newwhats        10.99.0.1/32            scram-sha-256

(Substitua scram-sha-256 por md5 se o seu banco estiver configurado com criptografia legado).

3. Reiniciar o serviço do PostgreSQL

Aplique as novas configurações recarregando o serviço:

sudo systemctl restart postgresql

4. Validar as regras de Firewall (nftables) na VPS 3

Se a VPS 3 usar nftables (como indicado no layout "V8 Bunker"), verifique se as regras atuais permitem o tráfego de entrada na porta 5432 vindo de 10.99.0.1. Para listar e validar as regras atuais na VPS 3:

sudo nft list ruleset

Certifique-se de que há uma regra de aceitação similar a esta na tabela de entrada da VPN:

ip saddr 10.99.0.1 tcp dport 5432 accept

⏭️ Próximos Passos

Liberar PostgreSQL na VPS 3: Execute os passos acima na VPS 3 para abrir o canal seguro de conexão.
Atualização Automática: Assim que a porta 5432 estiver liberada, o container clube67-newwhats-backend-1 (que está configurado para tentar se reconectar automaticamente) se conectará instantaneamente, executará as rotinas de inicialização e o painel em clube67.com estará 100% no ar!

5.8 KiB Raw Blame History