From 002b9acee8e7f7e0e664128db4abb3163d62ba22 Mon Sep 17 00:00:00 2001 From: VPS 4 Builder Date: Tue, 16 Jun 2026 06:47:24 +0200 Subject: [PATCH] =?UTF-8?q?chore:=20remove=20docs=20de=20scoreodonto=20(mo?= =?UTF-8?q?vidos=20p/=20scoreodonto.com/documenta=C3=A7=C3=A3o/)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fonte única agora vive no repo scoreodonto.com, versionado pelo Gitea. Co-Authored-By: Claude Opus 4.8 --- scoreodonto/arquitetura.md | 55 --------- scoreodonto/deploy.md | 245 ------------------------------------- 2 files changed, 300 deletions(-) delete mode 100644 scoreodonto/arquitetura.md delete mode 100644 scoreodonto/deploy.md diff --git a/scoreodonto/arquitetura.md b/scoreodonto/arquitetura.md deleted file mode 100644 index 79c792c..0000000 --- a/scoreodonto/arquitetura.md +++ /dev/null @@ -1,55 +0,0 @@ -# 🦷 Arquitetura ScoreOdonto CRM (Multi-Tenant) - -Este documento dita as regras exclusivas e as portas da arquitetura do **ScoreOdonto CRM**. -**Nunca** misture essas configurações com as do Clube67. - -## 🚀 Stack Tecnológica e Portas de Rede - -- **Frontend:** React + Vite + TypeScript + Tailwind - - Porta de Produção/Dev: `3013` -- **Backend:** Node.js + pg (Nativo) - - Porta de Produção/Dev: `8018` - - > [!IMPORTANT] - > **NÃO UTILIZE ORM (Prisma/Sequelize)**. Toda a persistência deve ser feita via driver nativo `pg` para máxima performance e controle de queries. -- **Banco de Dados (VPS 3):** PostgreSQL 18 - - Porta Padrão: `5432` - - Banco de Dados Isolado: `scoreodonto` -- **Cache (VPS 3):** DragonflyDB - - Porta Padrão: `6379` - - Índice Isolado: `/1` (exclusivo para ScoreOdonto) -- **Proxy Reverso (VPS 1):** Nginx / Traefik - - Domínio: `scoreodonto.com` - -## 🔄 Fluxo de Deploy Contínuo e Versionamento (+1) -O webhook do ScoreOdonto roda de forma isolada na VPS 4. -- **Webhook Listener Port (VPS 4):** `9002` -- O webhook escuta na porta 9002 e dispara o script de build/deploy exclusivo (`deploy-prod-scoreodonto.sh`). - -### 📦 Regra de Incremento de Versão (Host-Side Bump) -Diferente do Clube67, o versionamento do ScoreOdonto ocorre no **Host (VPS 4)** antes do processo de rsync/build. - -1. O script `update-version.js` está localizado em `/home/deploy/stack/scoreodonto.com/update-version.js`. -2. Este script é executado pelo pipeline de deploy (`deploy-prod-scoreodonto.sh`). -3. O script incrementa o `version.json`, gera o `deploys.json` e realiza um commit automático no Git com a tag `[version-bump]`. - -> [!WARNING] -> **NÃO ADICIONE O UPDATE-VERSION AO PACKAGE.JSON** -> No ScoreOdonto, o arquivo `frontend/package.json` deve conter apenas `"build": "vite build"`. -> Adicionar `node ../update-version.js &&` ao script de build dentro do Docker fará com que a versão seja incrementada em um ambiente efêmero e não persista no Git, resultando em versões congeladas ou duplicadas na interface. - -### 🐳 Arquitetura de Container (Stateless Build) -Como a versão já vem incrementada e persistida do Host via rsync, o Docker apenas compila o que recebe: - -1. O **Build Context** no `docker-compose.yml` aponta para a raiz do projeto (`context: .`). -2. O `Dockerfile` do frontend realiza o `vite build` de forma limpa. - -## 🤖 Fluxo de Auto-Cura (Self-Healing) com Grafana/Gitea -Para automatizar a geração de Issues no repositório `ruicesar/scoreodonto.com` quando ocorrerem falhas em produção (VPS 1): - -1. **Grafana (Painel Central):** Regras de alerta configuradas com a tag `repo="scoreodonto.com"`. -2. **Gitea-Bridge (VPS 1):** Escuta na porta **9091** e faz o POST na API do Gitea. - -> [!IMPORTANT] -> **Diferenciação de Portas:** -> * **9002:** Webhook de Deploy (VPS 4). -> * **9091:** Bridge de Auto-Cura (VPS 1). diff --git a/scoreodonto/deploy.md b/scoreodonto/deploy.md deleted file mode 100644 index 3c173e3..0000000 --- a/scoreodonto/deploy.md +++ /dev/null @@ -1,245 +0,0 @@ -# 🚀 Deploy ScoreOdonto — Guia Completo (VPS 4 → VPS 1) - -Este documento detalha o processo de deploy contínuo do ScoreOdonto e o sistema de versionamento automático. - ---- - -## 🔁 Visão Geral do Pipeline - -``` -Developer (VPS 4) - └─► git push origin main - └─► Gitea Webhook → POST http://10.99.0.4:9002/webhook?token=... - └─► listener-scoreodonto.js (porta 9002, VPS 4) - └─► deploy-prod-scoreodonto.sh - ├─► git pull (VPS 4) - ├─► rsync → VPS 1 (10.99.0.1) - └─► ssh VPS 1 → docker compose up -d --build - └─► update-version.js (auto-bump patch) - └─► vite build → nginx:alpine -``` - ---- - -## 📦 Versionamento do Sistema - -### Arquivo de versão -``` -frontend/constants.ts -``` -```ts -export const APP_VERSION = 'V1.0.6'; -``` - -### Como funciona o auto-incremento - -A cada `docker compose up -d --build`, o script `update-version.js` (na raiz do projeto) é chamado automaticamente pelo comando de build do frontend: - -```json -// frontend/package.json -"scripts": { - "build": "node ../update-version.js && vite build" -} -``` - -O script incrementa o **patch** (terceiro número) da versão: -- `V1.0.5` → `V1.0.6` → `V1.0.7` → ... - -> [!WARNING] -> O incremento ocorre **dentro do container Docker durante o build**. Os arquivos no repositório Git não são modificados automaticamente. A nova versão aparece na interface em produção, mas o `constants.ts` no Git permanece com o valor anterior ao build. - -### Tabela de tipos de versão - -| Tipo | Exemplo | Quando usar | Como fazer | -|------|---------|-------------|------------| -| **Patch** (automático) | `V1.0.5 → V1.0.6` | Cada deploy/build | Automático — `update-version.js` cuida | -| **Minor** (manual) | `V1.0.x → V1.1.0` | Nova feature significativa ou sprint | Editar `constants.ts`, zerar patch, commitar | -| **Major** (manual) | `V1.x.x → V2.0.0` | Rewrite, mudança arquitetural grande | Editar `constants.ts`, zerar minor e patch, commitar | - -### Bumpar versão Minor ou Major manualmente - -```bash -# 1. Editar o arquivo diretamente -nano /home/deploy/stack/scoreodonto.com/frontend/constants.ts -# Alterar: export const APP_VERSION = 'V1.1.0'; - -# 2. Commitar -cd /home/deploy/stack/scoreodonto.com -git add frontend/constants.ts -git commit -m "chore(version): bump para V1.1.0" -git push origin main -# → webhook dispara o deploy automaticamente -``` - ---- - -## 🤖 Webhook — Configuração - -| Parâmetro | Valor | -|-----------|-------| -| URL | `http://10.99.0.4:9002/webhook?token=scoreodonto_deploy_token_9002` | -| Método | `POST` | -| Eventos | Push na branch `main` | -| Listener | `/home/deploy/instrucoes/scoreodonto/listener-scoreodonto.js` | -| Deploy script | `/home/deploy/instrucoes/scoreodonto/deploy-prod-scoreodonto.sh` | - -### Verificar se o listener está ativo - -```bash -ps aux | grep listener-scoreodonto -# Deve aparecer: node /home/deploy/instrucoes/scoreodonto/listener-scoreodonto.js -``` - -### Reiniciar o listener (se parou) - -```bash -pkill -f listener-scoreodonto || true -nohup node /home/deploy/instrucoes/scoreodonto/listener-scoreodonto.js \ - > /tmp/scoreodonto-webhook.log 2>&1 & -echo $! > /tmp/scoreodonto-webhook.pid -``` - ---- - -## 🛠️ Deploy Manual (sem webhook) - -Use quando o webhook não está disponível ou para forçar um rebuild imediato: - -```bash -# Na VPS 4 -bash /home/deploy/instrucoes/scoreodonto/deploy-prod-scoreodonto.sh -``` - -O script executa: -1. `git pull origin main` — garante código atualizado na VPS 4 -2. `rsync` — sincroniza arquivos para VPS 1 (`10.99.0.1`), excluindo `node_modules`, `.env` e `.git` -3. `docker compose up -d --build` — reconstrói e reinicia os containers na VPS 1 - ---- - -## 🐳 Arquitetura Docker (Produção) - -### Frontend -``` -Dockerfile: frontend/Dockerfile -Build context: . (raiz do projeto) -``` -```dockerfile -# Stage 1: Build -FROM node:20-alpine AS builder -WORKDIR /app -COPY update-version.js . # ← script de versionamento vem da raiz -COPY frontend/package*.json frontend/ -WORKDIR /app/frontend -RUN npm install -COPY frontend/ . -RUN npm run build # → chama update-version.js + vite build - -# Stage 2: Serve -FROM nginx:alpine -COPY --from=builder /app/frontend/dist /usr/share/nginx/html -EXPOSE 3013 -``` - -### Backend -``` -Dockerfile: backend/Dockerfile -Porta: 8018 -Runtime: Node.js 20 -``` - -### Nginx (Proxy) -``` -Porta externa: 8020 -Traefik labels: scoreodonto.com / www.scoreodonto.com → HTTPS (Let's Encrypt) -``` - ---- - -## 🔍 Verificação Pós-Deploy - -```bash -# 1. Checar containers na VPS 1 -ssh deploy@10.99.0.1 "docker ps | grep scoreodonto" - -# 2. Checar versão em produção -curl -s https://scoreodonto.com | grep -o 'V[0-9]*\.[0-9]*\.[0-9]*' | head -1 - -# 3. Ver logs do último build -ssh deploy@10.99.0.1 "docker logs scoreodontocom-scoreodonto-frontend-1 --tail 30" - -# 4. Ver logs do backend -ssh deploy@10.99.0.1 "docker logs scoreodontocom-scoreodonto-backend-1 --tail 30" -``` - ---- - -## ⚠️ Troubleshooting - -| Problema | Diagnóstico | Solução | -|----------|-------------|---------| -| Webhook não dispara | `ps aux | grep listener` | Reiniciar o listener (ver acima) | -| Versão não atualiza na UI | Versão incrementa no container, não no git | Normal — a versão no git é a base; o build incrementa | -| `rsync` falha | `ssh deploy@10.99.0.1 echo ok` | Checar chave SSH e VPN WireGuard | -| Docker build falha | `docker logs` na VPS 1 | Ver logs do container; checar `npm install` | -| Frontend em branco | nginx config / dist vazia | Verificar se `vite build` completou sem erro | -| nginx não sobe, porta 8020 ocupada | `sudo ss -tlnp \| grep 8020` | Ver seção abaixo — docker-proxy zumbi | - ---- - -## 🔒 Alerta de Segurança — Docker Duplo (Rootless + Root) - -> [!CAUTION] -> A VPS 1 usa **Docker Rootless**. O daemon root (`docker.service`) está **desabilitado intencionalmente**. Nunca o reative. - -### Por que o daemon root é perigoso aqui - -O usuário `deploy` tem acesso `sudo`. Se o `docker.service` (root) estiver ativo e `deploy` estiver no grupo `docker`, qualquer `docker compose up` sem `DOCKER_HOST` cria containers como root — paralelos aos rootless, invisíveis ao `docker ps` normal, e inacessíveis ao Traefik (que monitora a rede rootless). - -### Sintoma: porta 8020 ocupada após `docker rm -f` - -Quando um container nginx é `force-remove`d enquanto o daemon root está ativo, o processo `docker-proxy` root pode ficar preso na porta: - -```bash -# Diagnóstico -sudo ss -tlnp | grep 8020 -# Se aparecer docker-proxy com PID root → daemon root estava ativo - -# Solução de emergência -sudo kill -cd ~/stack/scoreodonto.com -DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock docker compose rm -sf nginx -DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock docker compose up -d nginx -``` - -### Estado correto da VPS 1 - -```bash -# Verificar que o daemon root está morto -sudo systemctl status docker # deve mostrar: inactive (dead) - -# Verificar que deploy não está no grupo docker -groups deploy # não deve conter "docker" - -# Verificar que rootless está respondendo -DOCKER_HOST=unix:///run/user/1000/docker.sock docker ps | grep scoreodonto -``` - ---- - -## 📌 Comandos Git Rápidos (fluxo diário) - -```bash -cd /home/deploy/stack/scoreodonto.com - -# Ver estado -git status - -# Commitar e enviar (dispara deploy automaticamente) -git add -p # adicionar seletivamente -git commit -m "feat: descrição" # mensagem em português -git push origin main # → webhook → deploy automático -``` - -> [!TIP] -> Quando trabalhando com Claude Code (worktrees), o merge para `main` acontece ao final da sessão. O push para `main` é quem efetivamente dispara o deploy — não o commit em si.