Guia — scripts de deploy (`deploy-all`, `deploy-stack`, etc.)¶

Quando usar cada script, o que sobe automaticamente e o comportamento do docker compose up.

1. Resposta direta: `deploy-all.sh` remonta tudo ou só o que está off?¶

Não é um script “ligar só o que caiu”.
O deploy-all.sh executa o fluxo completo de instalação/atualização na VPS: pré-requisitos, checklist, configs, Issabel e stack Docker core.

Pergunta	Resposta
Sobe só containers parados?	Não exclusivamente — garante que o ambiente core exista e esteja alinhado com config/imagem atual
Reinicia tudo sempre?	Não — containers já rodando sem mudança de config/imagem em geral permanecem (`docker compose up -d` é idempotente)
Reconstrói imagens?	Sim — `deploy-stack.sh` usa `docker compose up -d --build`
Recria containers?	Se a imagem ou a definição do serviço mudou
Roda Issabel de novo?	Sim — chama `deploy-issabel.sh` (pode ser pesado mesmo com Issabel já instalado)

2. Ordem real do `deploy-all.sh`¶

./scripts/deploy-all.sh

#	Script	Sempre?	Notas
1	`install-host-prerequisites.sh`	Sim	Docker, swap, ferramentas
2	`check-pre-install.sh`	Sim	Aborta se houver FALHA
3	`render-config.sh`	Sim	INI, att_config, portal.apps.json
4	`deploy-issabel.sh`	Sim	PBX hostnet; ISO na 1ª vez; tema/webmail condicionais
5	`deploy-stack.sh`	Sim	`docker compose up -d --build` (serviços sem profile)
6	`validate-install.sh`	Sim	Não aborta o deploy (`\|\| true`)

O README antigo citava deploy-portal.sh à parte — o Portal já entra no passo 5 (lorentz-portal no compose principal).

3. Comportamento do `docker compose up -d --build`¶

Usado em deploy-stack.sh (e em vários deploys modulares):

Situação	Comportamento típico
Container ausente ou parado	Cria e inicia
Container rodando, sem mudanças	Mantém (não reinicia à toa)
`--build` e imagem alterada	Rebuild → tende a recriar containers daquela imagem
`.env`, `docker-compose.yml`, volumes	Compose pode recriar serviços afetados

Rodar deploy-all.sh ou deploy-stack.sh de novo costuma ser seguro (idempotente), mas não é no-op se houve atualização de zip, .env ou rebuild.

4. O que sobe em cada script¶

`deploy-stack.sh` — stack Docker core (sem Issabel)¶

docker compose up -d --build   # sem --profile

Serviço	Container	Profile
SQL Server	`lorentz-sqlserver`	—
Lorentz CTI	`lorentz-cti`	—
Base Histórica	`lorentz-basehistorica`	—
Supervisor	`lorentz-supervisor`	—
Portal Orbitall	`lorentz-portal`	—
MonitorOPS	`lorentz-monitor`	—

Não sobe no `deploy-all` / `deploy-stack` (profiles)¶

App	Script dedicado	Profile Compose
Webphone	`./scripts/deploy-webphone.sh`	`webphone`
Lorentz Energy	`./scripts/deploy-lorentz-energy.sh`	`energy`
Licença API	`./scripts/deploy-licenca.sh`	`licenca`
Portainer	`./scripts/deploy-portainer.sh`	`portainer`

Omnichannel-System — compose separado (não é profile)¶

Laravel em ../omnichannel-system/docker-compose.vps.yml, porta 8095.

Ambiente	Comando
Lab / homologação	`./scripts/deploy-lab-local.sh` (incluso) ou `./scripts/deploy-omnichannel.sh --lab`
VPS	`./scripts/deploy-all.sh` (incluso) ou `./scripts/deploy-omnichannel.sh --vps`

Guia: 48-omnichannel-system-integrado.md. Sem a pasta do clone, o legado segue e o script só avisa.

Issabel — compose separado (`ISSABEL_DIR`)¶

Gerenciado por deploy-issabel.sh, não pelo docker-compose.yml principal.

Lab local — sem Issabel¶

./scripts/deploy-lab-local.sh — ver 24-lab-local-wsl-docker.md.

5. Quando usar qual script¶

Objetivo	Comando recomendado
Primeira instalação VPS (cliente novo)	`./scripts/check-pre-install.sh` → `./scripts/deploy-all.sh`
Issabel já OK, só stack Docker	`./scripts/render-config.sh` → `./scripts/deploy-stack.sh`
Atualizou `net9.0.zip`	`extract-lorentz-cti-publish.sh` → `render-config.sh` → `docker compose up -d --build lorentz-cti`
Atualizou Supervisor PHP (volume)	`docker compose restart supervisor`
Um serviço caiu	`docker compose start <serviço>` ou `docker compose restart <serviço>`
Ver on/off + soluções	`./scripts/diagnose-stack.sh --brief`
Pós-deploy / saúde	`./scripts/validate-install.sh` (VPS: `--external`)
Treino sem VPS	`./scripts/deploy-lab-local.sh` (inclui Omnichannel-System se o clone existir)
Só o Laravel (8095)	`./scripts/deploy-omnichannel.sh --lab` ou `--vps`
Parar stack Lorentz (preserva volumes)	`./scripts/stop-stack.sh`
Subir de novo após stop	`./scripts/deploy-stack.sh` (não precisa `deploy-all`)

6. Checklist vs validação¶

Script	Momento	VPS	Lab WSL
`check-pre-install.sh`	Antes do deploy	Obrigatório	Opcional (`deploy-lab-local`; `--skip-check` se só avisos Issabel)
`validate-install.sh`	Depois do deploy	Sim (`--external` na VPS)	Sim (sem `--external`)
`diagnose-stack.sh`	Stack rodando	Diário	Diário

7. Reinício e recriação forçada¶

# Reinício leve (mesma imagem, mesma config)
docker compose restart lorentz-cti supervisor

# Recriar após mudança de .env renderizado
./scripts/render-config.sh
docker compose up -d --force-recreate lorentz-cti supervisor

# Rebuild completo de um serviço
docker compose up -d --build lorentz-portal

# Stack inteiro após stop-stack
./scripts/deploy-stack.sh

Evite deploy-all.sh para “só reiniciar um app” — é lento (Issabel + prerequisites) e desnecessário.

8. MonitorOPS vs linha de comando¶

Ação	CLI	MonitorOPS (:9090)
Status containers	`diagnose-stack.sh`	Visão Geral → Serviços
Ligar/parar um serviço	`docker compose start/stop`	Botões por serviço
Diagnóstico + runbooks	`diagnose-stack.sh --problems`	Diagnóstico automático
Bootstrap SQL	`restore-sql-bak.sh`	Ferramentas

Profiles (licenca, webphone) podem exigir script dedicado ou --profile no compose ao iniciar pelo Monitor.

9. Fluxograma resumido¶

flowchart TD
    A[VPS nova ou reinstalação completa?] -->|Sim| B[check-pre-install.sh]
    B --> C[deploy-all.sh]
    A -->|Não| D{O que precisa?}
    D -->|Só Docker core| E[render-config + deploy-stack.sh]
    D -->|Um serviço off| F[diagnose-stack.sh]
    F --> G[compose start/restart serviço]
    D -->|Opcional webphone/energy/licenca| H[deploy-*.sh dedicado]
    D -->|Lab sem Issabel| I[deploy-lab-local.sh]
    C --> J[validate-install.sh]
    E --> J

10. Documentos relacionados¶

Doc	Conteúdo
13-maquina-nova-stack-aws-cli.md	VPS nova passo a passo
15-distribuicao-equipe-suporte.md	Pacote dist + suporte
24-lab-local-wsl-docker.md	Lab WSL
27-instalar-app-opcional-energy.md	Instalar Lorentz Energy (passo a passo)
11-operacao-e-manutencao.md	Operação diária
Instalação completa	Guia completo suporte

11. Histórico¶

Data	Notas
2026-07-12	Guia criado — esclarece deploy-all vs deploy-stack vs restart pontual

Guia — scripts de deploy (deploy-all, deploy-stack, etc.)¶

1. Resposta direta: deploy-all.sh remonta tudo ou só o que está off?¶

2. Ordem real do deploy-all.sh¶

3. Comportamento do docker compose up -d --build¶