VPS 4 Builder
77 lines
5.1 KiB
Markdown
77 lines
5.1 KiB
Markdown
# Pendências & Tarefas a Fazer — ScoreOdonto
|
||
|
||
> Backlog operacional/infra após as 6 etapas de CI/CD (16/jun/2026). Ordenado por prioridade.
|
||
> Contexto da infra em `arquitetura.md`; fluxo de deploy em `deploy.md`; verdade atual em `VERDADE-HOJE.md`.
|
||
|
||
---
|
||
|
||
## 🔴 P0 — Estrutural
|
||
|
||
### 1. Isolar os bancos DEV (dev parar de usar o banco de produção)
|
||
> **Estratégia decidida + plano completo em `BANCO-DEV-ESTRATEGIA.md`**: um único container `postgis/postgis` na VPS4 (rootless) com `*_ref` (template da VPS3) + `*_dev`. Resolve scoreodonto, RX e subdomínio (e futuros) numa instância só. O texto abaixo é o contexto original.
|
||
|
||
**Problema:** dev (VPS4) e produção (VPS1) apontam para o **mesmo** banco na VPS3 (scoreodonto, dental_images, subdominio). Qualquer teste em dev escreve no dado real. É a maior dívida estrutural restante.
|
||
|
||
**Bloqueador descoberto (16/jun/2026):** o role `scoreodonto_user` **não pode criar banco** (`CREATEDB=false`, `SUPER=false`) e **não há shell na VPS3** (`deploy@10.99.0.3` recusa a chave). → Precisa de **ação do operador com acesso superuser** ao Postgres da VPS3 (usuário `postgres`), OU conceder a permissão: `ALTER ROLE scoreodonto_user CREATEDB;`.
|
||
|
||
**Passos:**
|
||
1. **(operador/superuser na VPS3)** Criar o banco:
|
||
`CREATE DATABASE scoreodonto_dev OWNER scoreodonto_user;`
|
||
2. **Popular com cópia da produção** (dados realistas p/ dev):
|
||
- Já existe dump recente em `/home/deploy/backups/scoreodonto_*.dump` (VPS4, formato `-Fc`).
|
||
- Restaurar: `pg_restore -d "postgresql://scoreodonto_user:<senha>@10.99.0.3:5432/scoreodonto_dev" --no-owner /caminho/scoreodonto_*.dump`
|
||
(ou via container: `docker run --rm -v <dump>:/b.dump -e PGPASSWORD=… postgres:18 pg_restore -h 10.99.0.3 -U scoreodonto_user -d scoreodonto_dev --no-owner /b.dump`).
|
||
3. **Apontar SÓ o dev para `scoreodonto_dev`** (sem tocar na prod):
|
||
- No `docker-compose.yml`, parametrizar: `DATABASE_URL=…@10.99.0.3:5432/${SCOREODONTO_DB:-scoreodonto}?schema=public` (default mantém a prod intacta).
|
||
- Na VPS4, criar `.env` (gitignored, dev-only) com `SCOREODONTO_DB=scoreodonto_dev`.
|
||
- Rebuild + recreate do backend de dev.
|
||
4. **Verificar:** `dev.scoreodonto.com/api/version` sobe; conferir que escrita em dev cai em `scoreodonto_dev` e **não** em `scoreodonto` (contagens divergem após um teste).
|
||
5. **(privacidade)** Avaliar anonimizar dados sensíveis de pacientes no `scoreodonto_dev`.
|
||
|
||
**Ganho:** dev deixa de poder corromper o dado de produção; fim da “única rede de segurança é o backup”.
|
||
|
||
---
|
||
|
||
## 🟠 P1 — Segurança
|
||
|
||
### 2. Rotacionar o token do Gitea exposto no chat
|
||
O token usado nos `docker login` (VPS4 e VPS1) e na descoberta foi colado no chat → comprometido. **Revogar no Gitea** (Configurações → Aplicações) e gerar um novo. Os logins já estão no keystore do Docker; só re-logar quando o token for trocado.
|
||
|
||
### 3. Criar o secret `REGISTRY_TOKEN` no repo
|
||
Adicionar em `git.clube67.com` → repo → Settings → Actions → Secrets um token (escopo `write:package`/`read:package`). Hoje o workflow funciona com a credencial do host como fallback; o secret deixa o CI independente disso.
|
||
|
||
### 4. Tirar credenciais em texto puro do `docker-compose.yml`
|
||
O `DATABASE_URL` e `DRAGONFLY_URL` têm **senha em texto puro** versionada no repo. Mover para `.env`/secrets (e idealmente rotacionar as senhas). Dívida de segurança pré-existente.
|
||
|
||
---
|
||
|
||
## 🟡 P2 — Operacional / Cosmético
|
||
|
||
### 5. Retenção/limpeza de imagens no registry
|
||
O registry vai acumular imagens (`:vX.Y.Z`, `:<commit>`, `:latest`) a cada deploy. Definir política de retenção (ex.: manter N últimas + releases) — a VPS3 tem disco finito. Avaliar limpeza automática.
|
||
|
||
### 6. Limpar a árvore git suja da VPS1
|
||
O repo em `/home/deploy/stack/scoreodonto.com` na VPS1 está **sujo** (vários `.md` e `.dockerignore` deletados, HEAD antigo `19dbbae`). Não afeta o deploy (que usa imagem), mas convém reconciliar/limpar para não confundir.
|
||
|
||
### 7. Ruído de attestation no registry
|
||
O BuildKit publica manifests de *provenance/attestation* que aparecem como “tags” `sha256:…` no registry. Inócuo; desligar com `provenance=false`/`--provenance=false` no build se incomodar.
|
||
|
||
### 8. Padronizar o case da versão (V vs v)
|
||
A CI mostra `v1.0.14` (minúsculo, por `tr 'V' 'v'`); builds manuais mostram `V1.0.14`. Cosmético — alinhar para um padrão único.
|
||
|
||
### 9. Backup automatizado do banco
|
||
Hoje o `pg_dump` é manual (via container `postgres:18`). Agendar backup periódico do `scoreodonto` (e, após P0, do `scoreodonto_dev`) com retenção. Evolução: WAL archiving / PITR.
|
||
|
||
---
|
||
|
||
## 🔵 Futuro (visão de produto — fora do escopo de infra)
|
||
Itens herdados do mapa de produto, ainda não implementados:
|
||
- **Score Professional** (motor de pontuação) — não existe.
|
||
- **Estoque**, **Teleatendimento**.
|
||
- Entidade formal **Pessoa × Empresa**.
|
||
- Monitoramento/observabilidade (Grafana já existe na stack — integrar métricas do ScoreOdonto).
|
||
|
||
---
|
||
|
||
_Atualizar este arquivo conforme as pendências forem resolvidas. As 6 etapas de CI/CD (documentação, versão visível, registry, pipeline, deploy por tag) estão **concluídas** — ver `deploy.md`._
|