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)
# Reinício leve (mesma imagem, mesma config)dockercomposerestartlorentz-ctisupervisor
# Recriar após mudança de .env renderizado./scripts/render-config.sh
dockercomposeup-d--force-recreatelorentz-ctisupervisor
# Rebuild completo de um serviçodockercomposeup-d--buildlorentz-portal
# Stack inteiro após stop-stack./scripts/deploy-stack.sh
Evitedeploy-all.sh para “só reiniciar um app” — é lento (Issabel + prerequisites) e desnecessário.
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