B2BCall Bootstrap
80e72881b2
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).
93 lines
3.5 KiB
Markdown
93 lines
3.5 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
git clone <url-do-repositorio> /opt/b2bcall
|
|
cd /opt/b2bcall
|
|
sudo ./scripts/install.sh
|
|
```
|
|
|
|
O script (`scripts/install.sh`) faz, em ordem:
|
|
|
|
1. Verifica que está rodando como root.
|
|
2. Instala dependências de sistema (git, curl, openssl, Node.js 24 LTS via
|
|
NodeSource, pnpm via corepack).
|
|
3. Instala Docker Engine + Compose plugin (repositório oficial Docker,
|
|
detecta o codename da distro automaticamente).
|
|
4. 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.
|
|
5. Instala as regras de firewall (`infrastructure/nftables/`) — protege
|
|
AMI/ARI/SIP contra a LAN, nunca bloqueia SSH.
|
|
6. Aplica `vm.overcommit_memory=1` (recomendado pelo Redis).
|
|
7. `pnpm install` no monorepo.
|
|
8. `docker compose build` (compila Asterisk do fonte — a etapa mais
|
|
demorada, ~5-10 minutos dependendo do hardware).
|
|
9. Sobe Postgres e Redis, aguarda ficarem saudáveis.
|
|
10. Aplica migrations do Prisma e roda o seed (permissões, perfis,
|
|
bootstrap do `super_admin`).
|
|
11. Sobe Asterisk e os demais serviços (`docker compose up -d`).
|
|
12. Roda `scripts/healthcheck.sh`.
|
|
13. Imprime a URL de acesso e o caminho do `FIRST_LOGIN.txt`.
|
|
|
|
## Primeiro acesso
|
|
|
|
```bash
|
|
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**:
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
sudo ./scripts/update.sh
|
|
```
|
|
|
|
Ver `docs/OPERATIONS.md` para detalhes.
|