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).
79 lines
3.7 KiB
Markdown
79 lines
3.7 KiB
Markdown
# B2BCall — Operação
|
|
|
|
## Comandos do dia a dia
|
|
|
|
| Tarefa | Comando |
|
|
|---|---|
|
|
| Ver status de tudo | `bash scripts/healthcheck.sh` |
|
|
| Ver logs de um serviço | `docker compose logs -f api` (troque `api` pelo serviço) |
|
|
| Reiniciar um serviço | `docker compose restart api` |
|
|
| Aplicar atualização de código | `sudo ./scripts/update.sh` |
|
|
| Backup manual | `sudo ./scripts/backup.sh` |
|
|
| Restaurar backup | `sudo ./scripts/restore.sh backups/postgres-<ts>.dump` |
|
|
| Console do Asterisk | `docker exec -it b2bcall-asterisk asterisk -rvvv` |
|
|
| Ver regras de firewall ativas | `nft list table inet b2bcall_fw` |
|
|
|
|
## Atualização (`scripts/update.sh`)
|
|
|
|
1. `git pull --ff-only` (se for um clone git).
|
|
2. `pnpm install --frozen-lockfile`.
|
|
3. `prisma migrate deploy` contra o Postgres (via `127.0.0.1:5432`, fora dos
|
|
containers).
|
|
4. `docker compose build` — rebuilda só as imagens cujo contexto mudou
|
|
(cache do Docker layer a layer).
|
|
5. `docker compose up -d` — recria containers com imagem nova.
|
|
6. `scripts/healthcheck.sh`.
|
|
|
|
Não há downtime zero: durante o rebuild/restart de `api`/`frontend`/`nginx`
|
|
há uma janela curta de indisponibilidade (segundos). O Asterisk e as
|
|
chamadas em andamento não são afetados a menos que a migration exija
|
|
mudança incompatível em tabelas usadas pelo Realtime (raro — revisar a
|
|
migration antes de rodar em produção com campanhas ativas).
|
|
|
|
## Rotina recomendada de produção
|
|
|
|
- **Backup diário** via cron (`docs/BACKUP_RESTORE.md`).
|
|
- **Monitoramento**: apontar Prometheus para `http://api:3000/api/metrics`
|
|
de dentro da rede Docker (`b2bcall-net`) — o endpoint exige uma sessão
|
|
autenticada (permissão `monitoring.view`) e não é exposto via Nginx, então
|
|
um scraper externo precisaria de uma integração dedicada (fora do escopo
|
|
atual; hoje o uso pretendido é observabilidade interna/manual).
|
|
- **Alertas mínimos recomendados**: `b2bcall_calls_abandoned_total` /
|
|
`b2bcall_calls_total` acima do limiar de compliance (ver
|
|
`GET /api/compliance/indicators`, que já calcula isso), containers não
|
|
saudáveis (`docker compose ps`), espaço em disco (dumps + logs do
|
|
Asterisk).
|
|
- **Rotação de logs do Asterisk**: `/var/log/asterisk` dentro do volume
|
|
`asterisk-log` cresce indefinidamente sem `logrotate` configurado — não
|
|
incluído nesta fase (ver `TODO.md`, limitação conhecida).
|
|
|
|
## Escalando além do laboratório atual
|
|
|
|
O ambiente original (1.9 GiB RAM / 2 vCPU) é suficiente para desenvolvimento
|
|
e para o modo `DIALER_SIMULATION=true`, não para volume real de discagem
|
|
(`docs/ARCHITECTURE.md` §1). Para produção real:
|
|
|
|
1. Aumentar para pelo menos 4 vCPU / 8 GiB RAM.
|
|
2. Revisar `mem_limit` de cada serviço em `docker-compose.yml` (hoje
|
|
conservador para caber em 1.9 GiB).
|
|
3. Considerar mover Postgres/Redis para fora do mesmo host do Asterisk se o
|
|
volume de CDR/CEL crescer muito (arquitetura já separa os dois
|
|
logicamente — schema `asterisk` dedicado — o que facilita migrar depois).
|
|
4. Colocar OpenSIPS na frente do Asterisk para múltiplos troncos/roteamento
|
|
avançado (não implementado nesta fase — ver `docs/OPENSIPS.md`).
|
|
|
|
## HTTPS
|
|
|
|
Não configurado nesta fase (a rede é privada, sem IP público — seção 5).
|
|
Para expor com TLS:
|
|
|
|
1. Obter certificado (Let's Encrypt via DNS challenge, já que não há IP
|
|
público para HTTP-01, ou certificado interno/self-signed para uso só na
|
|
LAN).
|
|
2. Editar `infrastructure/nginx/nginx.conf`: adicionar bloco
|
|
`listen 443 ssl;` com `ssl_certificate`/`ssl_certificate_key`, e um
|
|
bloco `listen 80` que só redireciona para 443.
|
|
3. Publicar a porta 443 em `docker-compose.yml` (serviço `nginx`).
|
|
4. Atualizar `infrastructure/nftables/` se necessário (443 já não é
|
|
bloqueado por padrão, só os serviços administrativos do Asterisk são).
|