Files

B2BCall Bootstrap 80e72881b2 feat: Fase 9/10 — métricas, scripts operacionais, callback/wrap-up e aceite final

Fase 9 (segurança e produção):
- GET /api/metrics: endpoint Prometheus com métricas reais (chamadas,
  agentes, filas, CPS por campanha), protegido por permissão
- scripts/backup.sh, restore.sh, healthcheck.sh, install.sh, update.sh —
  testados contra o ambiente real (backup.sh e healthcheck.sh rodados de
  verdade; install.sh/update.sh validados por inspeção, ambiente atual já
  provisionado)
- POST /api/agent-console/dispose: aplica disposição de chamada de verdade
  (lacuna deixada aberta desde a Fase 6), com ações CALLBACK (agenda
  retorno) e DO_NOT_CALL (suprime automaticamente)
- apps/dialer-worker/src/callback-sweep.ts: reativa leads com callback
  vencido; GET /api/callbacks para consulta
- apps/dialer-worker/src/wrap-up-sweep.ts: transição automática
  WRAP_UP -> AVAILABLE + despausa real na fila do Asterisk. Exigiu corrigir
  main.ts para conectar ao AMI mesmo em DIALER_SIMULATION=true
  (DIALER_SIMULATION deve impedir só originação de chamada, não ações
  administrativas de fila)
- nftables revisado (sem alterações necessárias)
- Documentação completa: INSTALL, OPERATIONS, BACKUP_RESTORE, SECURITY,
  DATABASE, API, ASTERISK, OPENSIPS (não implementado, motivo
  documentado), TROUBLESHOOTING
- README.md e CHANGELOG.md reescritos

Fase 10 (testes e aceite):
- Quality gate completo executado: build/typecheck (7 workspaces), lint,
  46 testes unitários, docker compose config/ps, healthcheck — tudo verde
- Aceite de segurança (seção 92): 13 itens verificados ao vivo contra o
  sistema real, não só por inspeção de código
- Aceite Asterisk (seção 93): os 5 comandos executados e documentados,
  comunicação API->AMI->Asterisk validada
- docs/RELATORIO_FINAL.md: relatório final no formato da seção 96

Todos os fixtures de teste desta fase foram removidos/desativados ao
final. Credenciais de acesso entregues separadamente em CREDENCIAIS.txt
(fora do git, nunca versionado).

2026-08-27 19:16:14 -03:00

3.5 KiB

Raw Blame History

B2BCall — Instalação

Requisitos

Debian 13 (trixie) limpo, acesso root.
Mínimo para dev/testes/simulação: 2 vCPU, 2 GiB RAM, 20 GiB disco.
Recomendado para produção real com volume de discagem: 4 vCPU, 8 GiB RAM (ver docs/ARCHITECTURE.md §1 — o ambiente original de desenvolvimento deste projeto tinha só 1.9 GiB e isso limitou decisões de arquitetura, como resource limits conservadores por container).
Rede: um IP privado para o servidor; troncos SIP/OpenSIPS acessíveis por IP privado (o Asterisk nunca tem IP público — seção 5).

Instalação automatizada

git clone <url-do-repositorio> /opt/b2bcall
cd /opt/b2bcall
sudo ./scripts/install.sh

O script (scripts/install.sh) faz, em ordem:

Verifica que está rodando como root.
Instala dependências de sistema (git, curl, openssl, Node.js 24 LTS via NodeSource, pnpm via corepack).
Instala Docker Engine + Compose plugin (repositório oficial Docker, detecta o codename da distro automaticamente).
Gera .env a partir de .env.example com segredos aleatórios fortes (scripts/generate-secrets.sh) — só na primeira instalação, nunca sobrescreve um .env existente.
Instala as regras de firewall (infrastructure/nftables/) — protege AMI/ARI/SIP contra a LAN, nunca bloqueia SSH.
Aplica vm.overcommit_memory=1 (recomendado pelo Redis).
pnpm install no monorepo.
docker compose build (compila Asterisk do fonte — a etapa mais demorada, ~5-10 minutos dependendo do hardware).
Sobe Postgres e Redis, aguarda ficarem saudáveis.
Aplica migrations do Prisma e roda o seed (permissões, perfis, bootstrap do super_admin).
Sobe Asterisk e os demais serviços (docker compose up -d).
Roda scripts/healthcheck.sh.
Imprime a URL de acesso e o caminho do FIRST_LOGIN.txt.

Primeiro acesso

cat FIRST_LOGIN.txt

Contém e-mail e senha do super_admin, gerados aleatoriamente (agente.md seção 70) — nunca uma senha padrão. O primeiro login exige troca de senha (mustChangePassword: true).

Remova o arquivo do servidor depois do primeiro acesso:

shred -u FIRST_LOGIN.txt   # ou: rm -f FIRST_LOGIN.txt

Acesso

Interface web: http://<ip-do-servidor>/
API: http://<ip-do-servidor>/api (Swagger em /api/docs se SWAGGER_ENABLED=true)

Nenhuma outra porta deve estar acessível pela LAN além de 80 (e 443 quando HTTPS for configurado — ver docs/OPERATIONS.md).

Instalação manual (passo a passo, se preferir não usar o script)

Ver o conteúdo de scripts/install.sh — cada etapa pode ser executada isoladamente. Pontos que merecem atenção especial se for fazer manualmente:

Ordem de subida: Postgres/Redis saudáveis → migrations → Asterisk → demais serviços. Subir tudo de uma vez com docker compose up -d também funciona (o depends_on: condition: service_healthy do docker-compose.yml já orquestra isso), mas as migrations/seed do Prisma precisam rodar manualmente contra o Postgres antes da API funcionar de verdade (a API não roda migrations automaticamente no boot — decisão deliberada para nunca alterar schema de produção sem um passo explícito).
DATABASE_URL para comandos rodados do host (fora dos containers): use 127.0.0.1 como host, não postgres — ver docs/ARCHITECTURE.md §3.2.1.

Atualizando uma instalação existente

sudo ./scripts/update.sh

Ver docs/OPERATIONS.md para detalhes.

3.5 KiB Raw Blame History