docs: renomeia terminologia "staging" -> "dev" em todo o ecossistema
O "staging" nunca foi implementado (sem banco *_staging nem container ativo em nenhum projeto). Padroniza para "dev" (VPS4 = desenvolvimento) em docs de arquitetura, doutrina, protocolo de deploy e configs de VPN (comentários). Renomeia: protocolo_deploy_staging.md -> protocolo_deploy_dev.md; nginx_wildcard_staging.conf -> nginx_wildcard_dev.conf. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
VPS 4 Builder
@@ -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:
|
||||
|
||||
+2
-2
@@ -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:
|
||||
|
||||
@@ -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/<nome-do-projeto>/` 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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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`).
|
||||
|
||||
---
|
||||
|
||||
@@ -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`):
|
||||
|
||||
|
||||
Reference in New Issue
Block a user