diff --git a/TAREFAS_SWARM.md b/TAREFAS_SWARM.md index 9d7945d..528eabf 100644 --- a/TAREFAS_SWARM.md +++ b/TAREFAS_SWARM.md @@ -7,8 +7,8 @@ Este arquivo registra o progresso da automação multi-VPS. - [x] **1.2 Configurar Dispatcher (VPS 3)**: Script de recepção de Webhooks. - [x] **1.3 Integrar com Gitea**: Configurar Webhook nativo do Gitea para o Dispatcher. -## 🔵 Fase 2: Automação de Staging -- [x] **2.1 Wildcard Proxy (VPS 1)**: Configurar `*.staging.clube67.com`. +## 🔵 Fase 2: Automação de Dev +- [x] **2.1 Wildcard Proxy (VPS 1)**: Configurar `*.dev.clube67.com`. - [x] **2.2 Roteamento de Porta**: Mapeamento dinâmico Subdomínio -> Porta na VPS 4 (Portas `8081` e `8082`). ## 🟡 Fase 3: Listeners e Agentes @@ -18,8 +18,8 @@ Este arquivo registra o progresso da automação multi-VPS. ## 🛡️ Fase 4: Governança SecOps & Homologação em Duas Etapas - [x] **4.1 Filtro de Rótulo SecOps (VPS 4)**: Listener configurado para ignorar issues que não possuam a etiqueta `Autônomo`. -- [x] **4.2 Isolamento de Deploy (VPS 4)**: Compilação local e implantação em Staging para `mercado.clube67.com` (porta `8081`) e `scoreodonto.com` (porta `8082`). -- [x] **4.3 Script de Promoção (VPS 4)**: Criação de scripts `deploy-to-prod.sh` para promoção manual ultra-segura Staging ➔ Produção na VPS 1. +- [x] **4.2 Isolamento de Deploy (VPS 4)**: Compilação local e implantação em Dev para `mercado.clube67.com` (porta `8081`) e `scoreodonto.com` (porta `8082`). +- [x] **4.3 Script de Promoção (VPS 4)**: Criação de scripts `deploy-to-prod.sh` para promoção manual ultra-segura Dev ➔ Produção na VPS 1. --- *Última atualização: 18/05/2026 - Agente Antigravity* diff --git a/VPS-0.1/wg0.conf b/VPS-0.1/wg0.conf index c0881d6..fa3a199 100644 --- a/VPS-0.1/wg0.conf +++ b/VPS-0.1/wg0.conf @@ -25,7 +25,7 @@ AllowedIPs = 10.99.0.10/32 PublicKey = S40JqovA4F8oH8aieWsDvNEv1yw5Juwu1wb4zHjQ8Ww= AllowedIPs = 10.99.0.3/32 -# Peer 3: VPS 4 (Desenvolvimento / Staging) +# Peer 3: VPS 4 (Desenvolvimento / Dev) [Peer] PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0= AllowedIPs = 10.99.0.4/32 diff --git a/VPS-0.4/README.md b/VPS-0.4/README.md index 819e362..f43a630 100644 --- a/VPS-0.4/README.md +++ b/VPS-0.4/README.md @@ -1,4 +1,4 @@ -# 🧪 Configuração de Rede Segura (VPN WireGuard) - VPS 4 (Desenvolvimento / Staging) +# 🧪 Configuração de Rede Segura (VPN WireGuard) - VPS 4 (Desenvolvimento / Dev) Este diretório contém os arquivos de configuração necessários para que a **VPS 4** (`10.99.0.4`) entre na rede privada criptografada do **Clube67** de forma totalmente segura. @@ -7,7 +7,7 @@ Este diretório contém os arquivos de configuração necessários para que a ** ## 🗺️ Visão de Conexão da VPS 4 ```mermaid graph LR - VPS4["🧪 VPS 4 (Staging)
IP: 10.99.0.4"] + VPS4["🧪 VPS 4 (Dev)
IP: 10.99.0.4"] VPS1["🖥️ VPS 1 (Hub Central)
IP: 10.99.0.1"] VPS3["🗄️ VPS 3 (Banco de Dados)
IP: 10.99.0.3"] @@ -37,7 +37,7 @@ Antes de ativar a conexão na VPS 4, o servidor central (**VPS 1**) precisa auto 3. Adicione o seguinte bloco de peer ao final do arquivo: ```ini [Peer] - # VPS 4 (Desenvolvimento / Staging) + # VPS 4 (Desenvolvimento / Dev) PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0= AllowedIPs = 10.99.0.4/32 PersistentKeepalive = 25 diff --git a/VPS-0.4/hub_peer_vps4.conf b/VPS-0.4/hub_peer_vps4.conf index 278f853..46f95d1 100644 --- a/VPS-0.4/hub_peer_vps4.conf +++ b/VPS-0.4/hub_peer_vps4.conf @@ -2,7 +2,7 @@ # Adicione este bloco ao final do arquivo para autorizar a conexão da VPS 4 [Peer] -# VPS 4 (Desenvolvimento / Staging) +# VPS 4 (Desenvolvimento / Dev) PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0= AllowedIPs = 10.99.0.4/32 PersistentKeepalive = 25 diff --git a/VPS-0.4/wg0.conf b/VPS-0.4/wg0.conf index 75ab51c..c1ad6cb 100644 --- a/VPS-0.4/wg0.conf +++ b/VPS-0.4/wg0.conf @@ -1,4 +1,4 @@ -# /etc/wireguard/wg0.conf - VPS 4 (Desenvolvimento / Staging) +# /etc/wireguard/wg0.conf - VPS 4 (Desenvolvimento / Dev) # Configuração de Cliente VPN WireGuard # IP Atribuído: 10.99.0.4 diff --git a/arquitetura.md b/arquitetura.md index 4a69e49..03703df 100644 --- a/arquitetura.md +++ b/arquitetura.md @@ -2,6 +2,16 @@ Este documento descreve detalhadamente a arquitetura de servidores e rede privada projetada para garantir **alta performance, isolamento de riscos, segurança de dados e facilidade de escalonamento**. +> [!NOTE] +> **Status das VPSs Ativas (Atualizado em 22/05/2026):** +> Atualmente, a infraestrutura conta com **3 VPSs ativas** em produção/homologação: +> 1. **VPS 1** (Produção - Gateway / Traefik / Apps) - IP: `10.99.0.1` +> 2. **VPS 3** (Banco de Dados Appliance) - IP: `10.99.0.3` +> 3. **VPS 4** (Laboratório / Dev / Builds) - IP: `10.99.0.4` +> +> A **VPS 5** (CRM WhatsApp / newwhats) está planejada e encontra-se **inativa temporariamente** na malha física atual. Todo o tráfego e serviços destinados a ela estão no aguardo de sua ativação futura. + + --- ## 🗺️ Visão Geral da Topologia (Rede VPN WireGuard) @@ -18,7 +28,7 @@ graph TD subgraph "Rede Privada VPN (10.99.0.0/24)" VPS1["🖥️ VPS 1 (Produção)
IP: 10.99.0.1
(Traefik / Apps)"] VPS3["🗄️ VPS 3 (Banco de Dados)
IP: 10.99.0.3
(PostgreSQL Dedicado)"] - VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Staging / Builds)"] + VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Dev / Builds)"] VPS5["💬 VPS 5 (CRM WhatsApp)
IP: 10.99.0.5
(Bots / APIs)"] end @@ -77,22 +87,24 @@ graph TD --- -### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging) -* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento. +### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev) +* **Função Principal**: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento. * **IP Privado VPN**: `10.99.0.4` * **Políticas do Firewall (UFW)**: * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN. * **Portas de teste (ex: 3002, 8080)**: **Bloqueadas publicamente** ou atreladas apenas ao IP privado da VPN para acesso exclusivo dos desenvolvedores autorizados. * **Tecnologias**: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container). * **Vantagens de Segurança & Performance**: - * **Replicação Streaming Real-Time (Staging)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal. + * **Replicação Streaming Real-Time (Dev)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal. * **Isolamento de Riscos**: Compilações de código (`npm run build`, `docker build`) e testes pesados de carga rodam aqui e consomem CPU sem comprometer os servidores de produção e banco de dados. * **Ambiente Espelho**: Homologação idêntica à produção para validações precisas antes de aplicar modificações em produção. --- -### 💬 4. VPS 5: Servidor de Aplicação Proprietária (newwhats) +### 💬 4. VPS 5: Servidor de Aplicação Proprietária (newwhats) [INATIVA TEMPORARIAMENTE] * **Função Principal**: Hospedar o backend e workers da plataforma proprietária **newwhats** (Backend Express com Socket.IO, Workers do Temporal e broker NATS). +* **Status Atual**: Planejada e em preparação para implantação. Inativa temporariamente na infraestrutura física. + * **IP Privado VPN**: `10.99.0.5` * **Políticas do Firewall (UFW)**: * **Portas de Integração Web**: Liberadas apenas para os Webhooks e requisições públicas de Socket.IO mapeadas via gateway. @@ -197,6 +209,9 @@ graph TD * **Tráfego de Borda**: O Traefik na VPS 1 encaminha o tráfego HTTP/HTTPS e conexões persistentes do Socket.IO diretamente para a VPS 5 (`10.99.0.5`) pela interface de túnel criptografado, mantendo as portas da VPS 5 públicas totalmente fechadas. * **Persistência de Negócio (Prisma + Knex)**: Ambas as ORMs/Query Builders centralizadas na VPS 5 apontam diretamente para o IP interno `10.99.0.3:5432` da VPS 3. * **Cache e Estados Rápidos**: O DragonflyDB na VPS 3 atende instantaneamente às solicitações de sessões e QR codes da VPS 5 via `10.99.0.3:6379`, provendo tempos de resposta na faixa de microssegundos sem concorrência local de CPU. + > [!TIP] + > **Sugestão de Evolução Futura (DragonflyDB)**: Atualmente, o DragonflyDB roda de forma nativa (bare-metal) no host da VPS 3. Para manter a VPS 3 focada única e exclusivamente no PostgreSQL nativo e evitar concorrência de RAM/CPU, recomenda-se que no futuro (assim que a VPS 5 estiver operacional) o DragonflyDB seja movido e executado na própria VPS 5 (ou no mesmo host que consumir o cache localmente), eliminando a latência de tráfego de rede interna para estados rápidos. + * **Workflows Assíncronos**: O Temporal Server processa o agendamento de tarefas e status de reputação na VPS 3, enquanto o **Temporal Worker** na VPS 5 consome e executa as atividades pesadas locais da aplicação. --- @@ -205,15 +220,15 @@ graph TD A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN. * **O Problema de Movimentação Lateral**: - Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados. + Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados. * **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**: ```text # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas: - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL) [ACEITAR] - Permitir VPS 5 (CRM) -> Porta 5432 (PostgreSQL) [ACEITAR] - - Permitir VPS 4 (Staging) -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR] - - Permitir VPS 4 (Staging) -> VPS 3 (Produção - Outras portas / serviços) [BLOQUEAR] + - Permitir VPS 4 (Dev) -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR] + - Permitir VPS 4 (Dev) -> VPS 3 (Produção - Outras portas / serviços) [BLOQUEAR] ``` * **🌐 DNS e Acesso Seguro à Internet no WireGuard**: diff --git a/clube67/arquitetura.md b/clube67/arquitetura.md index a36389f..f09e477 100644 --- a/clube67/arquitetura.md +++ b/clube67/arquitetura.md @@ -23,7 +23,7 @@ graph TD subgraph "Rede Privada VPN (10.99.0.0/24)" VPS1["🖥️ VPS 1 (Produção)
IP: 10.99.0.1
(Traefik / Apps)"] VPS3["🗄️ VPS 3 (Banco de Dados)
IP: 10.99.0.3
(PostgreSQL Dedicado)"] - VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Staging / Builds)"] + VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Dev / Builds)"] VPS5["💬 VPS 5 (CRM WhatsApp)
IP: 10.99.0.5
(Bots / APIs)"] end @@ -82,8 +82,8 @@ graph TD --- -### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging) -* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento. +### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev) +* **Função Principal**: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento. * **IP Privado VPN**: `10.99.0.4` * **Políticas do Firewall (UFW)**: * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN. @@ -208,14 +208,14 @@ graph TD A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN. * **O Problema de Movimentação Lateral**: - Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3). + Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3). * **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**: ```text # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas: - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL) [ACEITAR] - Permitir VPS 5 (CRM) -> Porta 5432 (PostgreSQL) [ACEITAR] - - Permitir VPS 4 (Staging) -> VPS 3 (Produção) [BLOQUEAR] + - Permitir VPS 4 (Dev) -> VPS 3 (Produção) [BLOQUEAR] ``` --- diff --git a/clube67/newwhats.local/arquitetura.md b/clube67/newwhats.local/arquitetura.md index c2114ba..739dc84 100644 --- a/clube67/newwhats.local/arquitetura.md +++ b/clube67/newwhats.local/arquitetura.md @@ -18,7 +18,7 @@ graph TD subgraph "Rede Privada VPN (10.99.0.0/24)" VPS1["🖥️ VPS 1 (Produção)
IP: 10.99.0.1
(Traefik / Apps)"] VPS3["🗄️ VPS 3 (Banco de Dados)
IP: 10.99.0.3
(PostgreSQL Dedicado)"] - VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Staging / Builds)"] + VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Dev / Builds)"] VPS5["💬 VPS 5 (CRM WhatsApp)
IP: 10.99.0.5
(Bots / APIs)"] end @@ -77,15 +77,15 @@ graph TD --- -### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging) -* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento. +### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev) +* **Função Principal**: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento. * **IP Privado VPN**: `10.99.0.4` * **Políticas do Firewall (UFW)**: * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN. * **Portas de teste (ex: 3002, 8080)**: **Bloqueadas publicamente** ou atreladas apenas ao IP privado da VPN para acesso exclusivo dos desenvolvedores autorizados. * **Tecnologias**: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container). * **Vantagens de Segurança & Performance**: - * **Replicação Streaming Real-Time (Staging)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal. + * **Replicação Streaming Real-Time (Dev)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal. * **Isolamento de Riscos**: Compilações de código (`npm run build`, `docker build`) e testes pesados de carga rodam aqui e consomem CPU sem comprometer os servidores de produção e banco de dados. * **Ambiente Espelho**: Homologação idêntica à produção para validações precisas antes de aplicar modificações em produção. @@ -205,15 +205,15 @@ graph TD A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN. * **O Problema de Movimentação Lateral**: - Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados. + Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados. * **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**: ```text # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas: - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL) [ACEITAR] - Permitir VPS 5 (CRM) -> Porta 5432 (PostgreSQL) [ACEITAR] - - Permitir VPS 4 (Staging) -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR] - - Permitir VPS 4 (Staging) -> VPS 3 (Produção - Outras portas / serviços) [BLOQUEAR] + - Permitir VPS 4 (Dev) -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR] + - Permitir VPS 4 (Dev) -> VPS 3 (Produção - Outras portas / serviços) [BLOQUEAR] ``` --- diff --git a/global/antigravity.md b/global/antigravity.md index fdbc2bb..039e0c2 100644 --- a/global/antigravity.md +++ b/global/antigravity.md @@ -4,8 +4,8 @@ ## 🎯 Seus Objetivos Unificados: 1. **Desenvolvimento e Correção**: Criar e corrigir códigos e scripts exclusivamente na VPS 4. -2. **Validação em Staging (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Staging na VPS 4 (`staging.{projeto}.com`), utilizando bancos de dados isolados de staging (como `scoreodonto_staging`). Pular esta homologação é proibido. -3. **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em staging, realizar a promoção limpa via scripts para a VPS 1. +2. **Validação em Dev (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Dev na VPS 4 (`dev.{projeto}.com`), utilizando bancos de dados isolados de dev (como `scoreodonto_dev`). Pular esta homologação é proibido. +3. **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em dev, realizar a promoção limpa via scripts para a VPS 1. 4. **Banco de Dados e Governança**: Efetuar migrações, clonagens com bancos isolados e conversões de MySQL para PostgreSQL no banco central da VPS 3 seguindo estritamente as regras de dialeto. ## 🛠️ Modus Operandi Geral: diff --git a/global/claude.md b/global/claude.md index 1b83c21..6eab39f 100644 --- a/global/claude.md +++ b/global/claude.md @@ -4,8 +4,8 @@ ## 🎯 Seus Objetivos Unificados: 1. **Desenvolvimento e Correção**: Criar e corrigir códigos e scripts exclusivamente na VPS 4. -2. **Validação em Staging (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Staging na VPS 4 (`staging.{projeto}.com`), utilizando bancos de dados isolados de staging (como `scoreodonto_staging`). Pular esta homologação é proibido. -3. **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em staging, realizar a promoção limpa via scripts para a VPS 1. +2. **Validação em Dev (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Dev na VPS 4 (`dev.{projeto}.com`), utilizando bancos de dados isolados de dev (como `scoreodonto_dev`). Pular esta homologação é proibido. +3. **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em dev, realizar a promoção limpa via scripts para a VPS 1. 4. **Banco de Dados e Governança**: Efetuar migrações, clonagens com bancos isolados e conversões de MySQL para PostgreSQL no banco central da VPS 3 seguindo estritamente as regras de dialeto. ## 🛠️ Modus Operandi Geral: diff --git a/global/doutrina_agentes.md b/global/doutrina_agentes.md index c71017b..05d2280 100644 --- a/global/doutrina_agentes.md +++ b/global/doutrina_agentes.md @@ -5,10 +5,10 @@ Este documento define a consciência situacional obrigatória para todos os agen ## 📍 Identificação de Localização Antes de qualquer ação, identifique seu IP interno: - **10.99.0.1 (VPS 1 - PRODUÇÃO)**: Ambiente CRÍTICO. Rodando Traefik e Nginx. - - *Regra*: Apenas deploys homologados em Staging. Nunca mexa na infraestrutura de rede. + - *Regra*: Apenas deploys homologados em Dev. Nunca mexa na infraestrutura de rede. - **10.99.0.3 (VPS 3 - CÉREBRO)**: Onde reside o Gitea, Postgres e DragonflyDB. - *Regra*: Proteja os dados. Backups antes de qualquer alteração de schema. -- **10.99.0.4 (VPS 4 - LABORATÓRIO)**: Desenvolvimento e Staging. +- **10.99.0.4 (VPS 4 - LABORATÓRIO)**: Desenvolvimento e Dev. - *Regra*: Liberdade para testar, criar e quebrar containers. É o local de nascimento do código. ## 🔐 Segurança e VPN @@ -25,7 +25,7 @@ Todo arquivo `.vps_identity` deve conter exatamente a seguinte estrutura: "vps_id": 4, "vps_name": "VPS-4-LABORATORIO", "ip_vpn": "10.99.0.4", - "role": "Desenvolvimento, Builds e Staging", + "role": "Desenvolvimento, Builds e Dev", "danger_level": "BAIXO - Liberdade para testar e recriar" } ``` @@ -34,7 +34,7 @@ Todo arquivo `.vps_identity` deve conter exatamente a seguinte estrutura: 1. **Verificação Obrigatória**: Toda execução de script ou agente deve prioritariamente ler e interpretar o arquivo `/home/deploy/.vps_identity` para calibrar o seu escopo de atuação. 2. **Respeito ao Danger Level (Nível de Perigo)**: - **Nível de Perigo ALTO** (ex: VPS 1, VPS 3): Agentes **NÃO PODEM** rodar comandos experimentais, mutações não homologadas de bancos de dados ou reinstalar dependências críticas sem backups nítidos e aprovação explícita. - - **Nível de Perigo BAIXO** (ex: VPS 4): O agente possui total autonomia para realizar testes, compilar códigos, reinstalar pacotes e reiniciar contêineres Docker de staging. + - **Nível de Perigo BAIXO** (ex: VPS 4): O agente possui total autonomia para realizar testes, compilar códigos, reinstalar pacotes e reiniciar contêineres Docker de dev. 3. **Resiliência (Fallback)**: Caso o arquivo `.vps_identity` não exista ou esteja ilegível, o agente deve fazer o fallback dinâmico (buscando o IP `10.99.x.x` via `hostname -I`) e assumir o perfil de segurança mais restritivo por padrão. ## 🚫 NUNCA... @@ -52,7 +52,7 @@ Sempre que um novo projeto for criado no ecossistema Swarm, os agentes **não pr > 1. Você **NÃO DEVE** criar Webhooks via API no repositório individual para evitar conflitos. > 2. Você **DEVE** garantir a criação do arquivo `.vps_identity` apropriado nas VPSs correspondentes. > 3. Você **DEVE** estruturar o `docker-compose.yml` do projeto sob a pasta `/home/deploy/stack//` seguindo o padrão rootless. -> 4. **Exposição de Portas (VPS 4)**: Contêineres na VPS 4 não devem mapear a porta `80` ou `443` diretamente no Host físico, para evitar conflitos com múltiplos projetos de staging. Use redes internas ou labels (Docker Overlay) para que a **VPS 1 (Traefik)** faça o encaminhamento do tráfego. +> 4. **Exposição de Portas (VPS 4)**: Contêineres na VPS 4 não devem mapear a porta `80` ou `443` diretamente no Host físico, para evitar conflitos com múltiplos projetos de dev. Use redes internas ou labels (Docker Overlay) para que a **VPS 1 (Traefik)** faça o encaminhamento do tráfego. > 5. **Bancos de Dados**: É terminantemente **proibido** subir contêineres de Banco de Dados (`postgres`, `mysql`, etc) localmente nos projetos da VPS 4. Todos os serviços devem obrigatoriamente apontar para a VPS 3 (10.99.0.3). ## 🗣️ Comunicação @@ -70,8 +70,8 @@ Os seguintes diretórios são de infraestrutura e serviços críticos ativos e * * 📁 `/home/deploy/stack/soc/`: Rotinas de CrowdSec, firewall e auditoria de segurança ativa. ### 🖥️ VPS 4 - Laboratório (10.99.0.4) -Os seguintes diretórios dentro de `/home/deploy/stack/` contêm contêineres de desenvolvimento e staging ativos e **DEVEM SER ESTRITAMENTE PRESERVADOS** na VPS 4: -* 📁 `scoreodonto.com/`: Aplicação e contêineres de staging do ecossistema ScoreOdonto. +Os seguintes diretórios dentro de `/home/deploy/stack/` contêm contêineres de desenvolvimento e dev ativos e **DEVEM SER ESTRITAMENTE PRESERVADOS** na VPS 4: +* 📁 `scoreodonto.com/`: Aplicação e contêineres de dev do ecossistema ScoreOdonto. * 📁 `subdominio.clube67.com/`: Branding, front-end e back-end do Gerenciador de Subdomínios. * 📁 `self-healing/`: Rotinas e scripts locais de auto-recuperação de serviços. * 📁 `webhook-listener/`: Ouvinte de webhooks de GitOps (porta `9000`) para deploys automatizados. @@ -120,7 +120,7 @@ Em vez de criar Webhooks de push repetitivos para cada repositório das aplicaç Para mantermos o ecossistema no estado da arte de DevOps, utilizamos os seguintes recursos globais do Gitea: * 📁 **Gitea Organizations (Organizações - ex: clube67)**: Agrupa todos os repositórios sob um único tenant corporativo, permitindo gerenciar permissões de equipes (Teams) e IAs de uma única vez para todos os projetos. * 🔑 **Personal Access Tokens (PAT - Nível de Usuário)**: Criação de um Token de Acesso único do usuário administrador injetado na RAM dos agentes, dando autorização de API para ler issues, wikis e logs de todos os repositórios atuais e futuros de forma centralizada. -* 🏷️ **Rótulos Padrão (Global Labels)**: Padronização de etiquetas de Issues (ex: `bug-self-healing`, `deploy-staging`, `security-incident`, `Autônomo`) herdadas automaticamente por qualquer novo repositório, agilizando a triagem de erros. +* 🏷️ **Rótulos Padrão (Global Labels)**: Padronização de etiquetas de Issues (ex: `bug-self-healing`, `deploy-dev`, `security-incident`, `Autônomo`) herdadas automaticamente por qualquer novo repositório, agilizando a triagem de erros. --- diff --git a/global/protocolo_deploy_staging.md b/global/protocolo_deploy_dev.md similarity index 82% rename from global/protocolo_deploy_staging.md rename to global/protocolo_deploy_dev.md index 65e046a..131ffbd 100644 --- a/global/protocolo_deploy_staging.md +++ b/global/protocolo_deploy_dev.md @@ -1,26 +1,26 @@ -# 🚀 Protocolo de Deploy, Staging e Governança Swarm +# 🚀 Protocolo de Deploy, Dev e Governança Swarm -Este documento define o fluxo obrigatório para garantir a integridade dos ambientes de Staging e Produção, além de normatizar a governança das Issues e Wikis no Gitea. +Este documento define o fluxo obrigatório para garantir a integridade dos ambientes de Dev e Produção, além de normatizar a governança das Issues e Wikis no Gitea. --- -## 🏗️ 1. A Estrutura de Ambientes e Roteamento de Staging +## 🏗️ 1. A Estrutura de Ambientes e Roteamento de Dev -1. **Desenvolvimento e Staging (VPS 4 - IP 10.99.0.4)**: +1. **Desenvolvimento e Dev (VPS 4 - IP 10.99.0.4)**: * Ambiente de **Nível de Perigo BAIXO**. * Todo build local, compilação de frontends e contêineres de testes rodam isolados aqui. - * **Regra Universal de Domínios de Staging**: Para qualquer domínio (seja subdomínio sob `clube67.com` ou domínio próprio de clientes), o domínio de staging é formado obrigatoriamente adicionando o prefixo **`staging.`** à frente do domínio principal. - * **Tabela de Roteamento e Bancos de Staging (VPS 4)**: - * **Porta `8081`**: Mercado (Domínio: `staging.mercado.clube67.com` | Banco de Dados: `mercado_staging`) - * **Porta `8082`**: ScoreOdonto (Domínio: `staging.scoreodonto.com` | Banco de Dados: `scoreodonto_staging`) - * **Porta `8083`**: NewWhats (Domínio: `staging.newwhats.clube67.com` | Banco de Dados: `newwhats_staging`) + * **Regra Universal de Domínios de Dev**: Para qualquer domínio (seja subdomínio sob `clube67.com` ou domínio próprio de clientes), o domínio de dev é formado obrigatoriamente adicionando o prefixo **`dev.`** à frente do domínio principal. + * **Tabela de Roteamento e Bancos de Dev (VPS 4)**: + * **Porta `8081`**: Mercado (Domínio: `dev.mercado.clube67.com` | Banco de Dados: `mercado_dev`) + * **Porta `8082`**: ScoreOdonto (Domínio: `dev.scoreodonto.com` | Banco de Dados: `scoreodonto` — ⚠️ **o MESMO da produção**, não há banco de dev isolado). Ver `scoreodonto/DEPLOY-PRODUCAO.md`. + * **Porta `8083`**: NewWhats (Domínio: `dev.newwhats.clube67.com` | Banco de Dados: `newwhats_dev`) * **Obrigatoriedade de Homologação (Domínio Coringa)**: - * O subdomínio `staging.` atua como o ambiente **coringa e obrigatório** de homologação. - * ⚠️ **É TERMINANTEMENTE PROIBIDO** realizar qualquer deploy ou sincronização direta da VPS 4 (Staging/Desenvolvimento) para a VPS 1 (Produção) sem que as alterações tenham sido previamente implantadas no contêiner de Staging da VPS 4, apontando para o seu respectivo banco de staging (ex: `scoreodonto_staging`), e exaustivamente testadas. + * O subdomínio `dev.` atua como o ambiente **coringa e obrigatório** de homologação. + * ⚠️ **É TERMINANTEMENTE PROIBIDO** realizar qualquer deploy ou sincronização direta da VPS 4 (Dev/Desenvolvimento) para a VPS 1 (Produção) sem que as alterações tenham sido previamente implantadas no contêiner de Dev da VPS 4, apontando para o seu respectivo banco de dev (ex: `mercado_dev`), e exaustivamente testadas. * Esta homologação prévia é o único escudo que evita downtime e bugs para os usuários finais no contêiner de produção. 2. **Produção (VPS 1 - IP 10.99.0.1)**: * Ambiente **CRÍTICO - Nível de Perigo ALTO**. - * Apenas artefatos homologados e estáveis de staging são despachados para cá. + * Apenas artefatos homologados e estáveis de dev são despachados para cá. --- @@ -32,7 +32,7 @@ A VPS 1 (Produção) é uma máquina reservada estritamente para a execução le 1. ❌ **É EXPRESSAMENTE PROIBIDO rodar `npm run build`, `yarn build`, `docker build`, `next build` ou qualquer script de compilação, empacotamento, empacotadores (bundlers) ou transpilação (TypeScript/Babel) diretamente na VPS 1.** 2. 🚀 **Onde o Build DEVE Ocorrer?** - Todo e qualquer processo de compilação, build, empacotamento e geração de contêineres deve ocorrer **exclusivamente na VPS 4 (Staging/Laboratório)**. + Todo e qualquer processo de compilação, build, empacotamento e geração de contêineres deve ocorrer **exclusivamente na VPS 4 (Dev/Laboratório)**. 3. 📦 **Como os artefatos chegam na VPS 1?** O deploy na VPS 1 deve ser realizado unicamente por importação de artefatos já pré-compilados: - **Artefatos Estáticos / Bundles**: O código é compilado na VPS 4 (gerando a pasta `/dist` ou `/build` compactada). O pacote compactado é transferido via rede interna (SCP/Rsync) para a VPS 1, que apenas descompacta e roda os arquivos estáticos, sem realizar nenhuma compilação local. @@ -56,18 +56,18 @@ Para permitir a colaboração fluida entre as VPSs e agentes sem causar conflito --- -## 📋 3. Fluxo de Homologação em Duas Etapas (Staging ➔ Produção) +## 📋 3. Fluxo de Homologação em Duas Etapas (Dev ➔ Produção) -### 🔄 Passo 1: Deploy Automático em Staging (VPS 4) +### 🔄 Passo 1: Deploy Automático em Dev (VPS 4) * Ao realizar um `git push` no repositório do projeto, o webhook do Gitea dispara a compilação local na VPS 4. -* O contêiner de Staging é iniciado e exposto localmente sob o subdomínio `staging.mercado.clube67.com` (ou similar) na porta correspondente para homologação. +* O contêiner de Dev é iniciado e exposto localmente sob o subdomínio `dev.mercado.clube67.com` (ou similar) na porta correspondente para homologação. * **Nenhum dado é despachado para a VPS 1 neste momento.** ### 🏁 Passo 2: Validação e Smoke Test -* O humano (ou a IA assistente) acessa a URL de staging na VPS 4, realiza testes completos e valida as novas funcionalidades. +* O humano (ou a IA assistente) acessa a URL de dev na VPS 4, realiza testes completos e valida as novas funcionalidades. ### 🚚 Passo 3: Promoção Manual para Produção (VPS 1) -* Somente após validação completa em Staging, executa-se o script de promoção manual `deploy-to-prod.sh`. +* Somente após validação completa em Dev, executa-se o script de promoção manual `deploy-to-prod.sh`. * Esse script sincroniza os arquivos compilados da VPS 4 para a VPS 1 via `rsync` de forma limpa, reiniciando os contêineres na VPS 1 em menos de 10 segundos. --- @@ -111,7 +111,7 @@ Sempre que um domínio ou subdomínio for clonado para dar origem a um novo ambi * Criar um banco exclusivo (`CREATE DATABASE {nome_clone};`). * Criar um usuário exclusivo com senha aleatória e segura (`CREATE USER {user_clone} WITH PASSWORD '{senha}';`). * Nunca reaproveite credenciais ou usuários existentes de outros tenants. -* 📁 **Nomenclatura Consistente**: O nome do banco de dados, usuário, contêiner e volumes no disco devem seguir um padrão idêntico ao do novo subdomínio/domínio (ex: se o projeto `staging.scoreodonto.com` tiver a duplicação do banco solicitada, deve usar banco `scoreodonto_staging`). +* 📁 **Nomenclatura Consistente**: O nome do banco de dados, usuário, contêiner e volumes no disco devem seguir um padrão idêntico ao do novo subdomínio/domínio (ex: se o projeto `dev.mercado.clube67.com` tiver a duplicação do banco solicitada, deve usar banco `mercado_dev`). --- diff --git a/global/seguranca_deploy_user.md b/global/seguranca_deploy_user.md index 966b820..f46a423 100644 --- a/global/seguranca_deploy_user.md +++ b/global/seguranca_deploy_user.md @@ -196,7 +196,7 @@ fi ## 🛡️ Pilar 6: Micro-segmentação de Rede e Firewall Restritivo (SecOps) -Para evitar a movimentação lateral caso qualquer VPS de staging (como a VPS 4) seja comprometida, a **VPS 3 (Cérebro)** possui uma política rígida de firewall (UFW) baseada no **Princípio do Menor Privilégio a Nível de Rede**. +Para evitar a movimentação lateral caso qualquer VPS de dev (como a VPS 4) seja comprometida, a **VPS 3 (Cérebro)** possui uma política rígida de firewall (UFW) baseada no **Princípio do Menor Privilégio a Nível de Rede**. ### Configuração do Firewall da VPS 3 (`wg0`): diff --git a/templates/nginx_wildcard_staging.conf b/templates/nginx_wildcard_dev.conf similarity index 78% rename from templates/nginx_wildcard_staging.conf rename to templates/nginx_wildcard_dev.conf index a4477d6..44a731b 100644 --- a/templates/nginx_wildcard_staging.conf +++ b/templates/nginx_wildcard_dev.conf @@ -1,7 +1,7 @@ -# 🏗️ Template Nginx Wildcard para Staging (VPS 1) +# 🏗️ Template Nginx Wildcard para Dev (VPS 1) # Este mapeamento associa o subdomínio à porta na VPS 4 -map $project_slug $staging_port { +map $project_slug $dev_port { mercado 8081; scoreodonto 8082; newwhats 8083; @@ -10,7 +10,7 @@ map $project_slug $staging_port { server { listen 80; - server_name ~^(?.+)\.staging\.clube67\.com$; + server_name ~^(?.+)\.dev\.clube67\.com$; # Redirecionamento para HTTPS return 301 https://$host$request_uri; @@ -18,7 +18,7 @@ server { server { listen 443 ssl; - server_name ~^(?.+)\.staging\.clube67\.com$; + server_name ~^(?.+)\.dev\.clube67\.com$; # Certificados SSL (Substituir pelos caminhos reais do Let's Encrypt Wildcard) ssl_certificate /etc/letsencrypt/live/clube67.com/fullchain.pem; @@ -26,7 +26,7 @@ server { location / { # Encaminha o tráfego via VPN para a VPS 4 - proxy_pass http://10.99.0.4:$staging_port; + proxy_pass http://10.99.0.4:$dev_port; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; diff --git a/vpn-setup.md b/vpn-setup.md index 2a66f98..6c7f9bf 100644 --- a/vpn-setup.md +++ b/vpn-setup.md @@ -145,7 +145,7 @@ Definimos o **`MTU = 1360`** (ou `1280` para máxima resiliência) em todos os a ``` *Reinicie o serviço:* `sudo systemctl restart wg-quick@wg0` -3. **Nas VPSs 4 e 5 (Staging e CRM - REQUER APLICAR):** +3. **Nas VPSs 4 e 5 (Dev e CRM - REQUER APLICAR):** Repita o mesmo procedimento adicionando `MTU = 1360` sob `[Interface]` em seus respectivos `/etc/wireguard/wg0.conf` e reinicie a interface. > [!TIP] diff --git a/vps3-banco-tuning.md b/vps3-banco-tuning.md index 69be270..48aaf4c 100644 --- a/vps3-banco-tuning.md +++ b/vps3-banco-tuning.md @@ -96,7 +96,7 @@ host newwhats newwhats_user 10.99.0.5/32 scram-sha-25 # 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal host temporal temporal_user 10.99.0.5/32 scram-sha-256 -# 4. Permitir conexões de replicação da VPS 4 (Staging/Replica) +# 4. Permitir conexões de replicação da VPS 4 (Dev/Replica) host replication replicator 10.99.0.4/32 scram-sha-256 # 5. Bloqueio preventivo total para qualquer outro IP ou usuário @@ -200,7 +200,7 @@ host facebook_db facebook_user 10.99.0.1/32 scram-sha-25 # 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3) host newwhats newwhats_user 10.99.0.5/32 scram-sha-256 -# 5. Permitir conexões de replicação da VPS 4 (Staging/Replica) +# 5. Permitir conexões de replicação da VPS 4 (Dev/Replica) host replication replicator 10.99.0.4/32 scram-sha-256 # 6. BLOQUEIO PADRÃO TOTAL (Zero-Trust)