Lab local — WSL2 / Docker (sem VPS)¶

Objetivo: permitir que a equipe de suporte treine, valide scripts e teste apps web sem acesso a uma VPS de cliente.
Não substitui homologação com Issabel/PABX — telefonia real exige Linux VPS (ver Instalação completa).

1. O que funciona no lab¶

App	URL típica	Observação
Portal Orbitall	http://127.0.0.1:8099/	Hub, `/cti/`, `/licenca/`
Supervisor	http://127.0.0.1:8080/	Login PHP — requer SQL bootstrap/restore
MonitorOPS	http://127.0.0.1:9090/	Diagnóstico, ferramentas, `.env`
CTI Monitor API	Portal → `/cti/`	Sem AMI Issabel — grids vazios ou parciais
Lorentz CTI	portas 3000/8000/8090	TCP interno; AMI não conecta sem PBX
SQL Server	localhost:1433	Developer Edition no container
Base Histórica	127.0.0.1:8091	Se `basehistorica.zip` presente
Webphone	http://127.0.0.1:8081/	`--with-webphone`
Energy	http://127.0.0.1:8082/	`--with-energy`
Licença API	Portal → `/licenca/`	`--with-licenca` + `licenca.zip`
Omnichannel-System	http://127.0.0.1:8095/	Sobe com o lab se existir `../omnichannel-system`. Guia: 48

2. O que não funciona (limitações)¶

Item	Motivo
Issabel PBX	Docker hostnet — SIP/RTP/443 no host; instável ou inviável no WSL2
`deploy-all.sh`	Inclui Issabel — use `deploy-lab-local.sh`
`deploy-stack.sh`	Mesmo core Docker, sem Issabel — ver 25-guia-scripts-deploy.md
AMI / FullyBooted	CTI precisa do Asterisk no Issabel
SIP / WebRTC / filas	Fluxo telefônico completo
`validate-install.sh --external`	Testa IP público / Security Group AWS
*Scripts `open-aws-port-.sh`**	Só fazem sentido na EC2

Para PABX + CTI integrados, use VPS Linux de homologação (2 vCPU, 4 GB RAM, 40 GB).

3. Pré-requisitos¶

Windows + WSL2 (recomendado para suporte)¶

Windows 11/10 com WSL2 habilitado
Uma distro Linux no WSL (Debian ou Ubuntu 22.04)
Docker Engine + Compose — ver opções abaixo (Desktop não é obrigatório)
RAM WSL ≥ 6 GB — arquivo %UserProfile%\.wslconfig:

[wsl2]
memory=8GB
processors=4
swap=4GB

Reinicie WSL: wsl --shutdown (PowerShell).

Opção A — Docker CE dentro do WSL (leve, sem Desktop) ✅¶

Ideal quando o disco C: está apertado ou o Desktop foi desinstalado. O stack roda com o mesmo modelo da VPS: Engine + Compose no Linux.

# Qual distro é o padrão (*)?
wsl -l -v

No lab atual da equipe (Cursor / monorepo): distro padrão costuma ser Debian com Docker CE já instalado. Não use uma distro WSL chamada portainer como motor — isso é outra instalação; Portainer CE é um container em cima do Engine.

# Dentro do WSL (Debian ou Ubuntu)
sudo apt update
sudo apt install -y docker.io docker-compose-v2
sudo usermod -aG docker $USER
# feche e reabra o terminal WSL, depois:
docker info
cd /mnt/d/omnichannel/lorentz-vps-stack   # ajuste o path do monorepo
./scripts/deploy-lab-local.sh

Do PowerShell Windows, force a distro certa:

wsl -d Debian -e bash -lc 'docker info; cd /mnt/d/omnichannel/lorentz-vps-stack && ./scripts/deploy-lab-local.sh'

Item	Nota
Cursor terminal	Use a distro com Docker (ex.: Debian), não Ubuntu sem Engine
`wsl` sem `-d`	Segue a distro marcada com `*` em `wsl -l -v`
UI dos containers	Portainer CE no lab — seção 3.1

Opção B — Docker Desktop + integração WSL¶

Caminho mais simples se houver espaço em disco:

Instale Docker Desktop
Settings → Resources → WSL integration → ligue a distro do lab
docker info deve funcionar dentro do WSL

Linux nativo (VM ou desktop)¶

Docker Engine + Compose plugin
≥ 4 GB RAM livre, ≥ 25 GB disco
Mesmos scripts bash

3.1 Portainer CE no lab (opcional)¶

Portainer não substitui o Docker — é a interface web em cima do Engine. No lab (sem profile Compose da VPS):

# No WSL com Docker CE
docker volume create portainer_data
docker run -d --name portainer --restart=unless-stopped \
  -p 9000:9000 -p 9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

URL	Uso
http://localhost:9000	Setup / UI HTTP
https://localhost:9443	UI HTTPS (certificado próprio)

Timeout de segurança no 1º acesso (“New Portainer installation… timed out”): se não criar o admin em ~5 minutos, reinicie e complete na hora:

wsl -d Debian -e docker restart portainer

# logs
wsl -d Debian -e docker logs portainer --tail 50

Na VPS de cliente use o profile oficial: 31 — Instalar Portainer (./scripts/deploy-portainer.sh, container lorentz-portainer).

Artefatos¶

Escolha uma origem:

Origem	Conteúdo
Pacote suporte `dist/lorentz-deploy-*.tar.gz`	`net9.0.zip`, `supervisor.tar.gz`, stack
Monorepo	`lorentz-vps-stack/` + clone `supervisor-php` + `resources/net9.0.zip`

# Pacote suporte (após extrair)
cd ~/omnichannel/lorentz-vps-stack
./scripts/prepare-support-install.sh

# Monorepo dev
git clone .../lorentz-vps-stack ~/omnichannel/lorentz-vps-stack
git clone .../supervisor-php ~/omnichannel/supervisor
# Copie ou gere net9.0.zip em resources/

4. Deploy rápido¶

cd ~/omnichannel/lorentz-vps-stack

# Core: SQL + CTI + Supervisor + Portal + MonitorOPS + Omnichannel-System
./scripts/deploy-lab-local.sh

# Com todos os opcionais (webphone, energy, licenca)
./scripts/deploy-lab-local.sh --all-optional

# Parar lab (preserva volumes SQL)
./scripts/deploy-lab-local.sh --stop

O script:

Detecta WSL
Cria/ajusta .env (URLs 127.0.0.1, LORENTZ_LAB_MODE=1)
Extrai net9.0.zip se necessário
Roda check-pre-install.sh (falhas de Issabel são esperadas — ignore avisos de Issabel ausente)
Sobe stack sem Issabel
Exibe URLs e ./scripts/diagnose-stack.sh --brief

Primeira vez — banco de dados¶

Coloque LorentzCTI.bak em lorentz-vps-stack/resources/ (incluído no pacote de suporte). O deploy-lab-local.sh restaura automaticamente na primeira subida.

# Manual (se necessario)
cp /caminho/LorentzCTI.bak resources/
./scripts/init-sql-lab.sh --sync-mac
docker compose restart lorentz-cti supervisor

Sem o .bak, o script usa bootstrap SQL mínimo (apenas desenvolvimento) e avisa.

Validar:

./scripts/validate-install.sh          # local only
./scripts/diagnose-stack.sh --problems

5. Variáveis de ambiente¶

Use .env.lab.example como base:

cp .env.lab.example .env
nano .env

Ou deixe deploy-lab-local.sh patch automático de IPs de exemplo para 127.0.0.1.

Variável	Lab
`LORENTZ_LAB_MODE=1`	Marca instalação local
`VPS_PUBLIC_IP=127.0.0.1`	URLs do Portal
`MSSQL_BIND_IP=127.0.0.1`	SQL só local
`ISSABEL_DIR=/tmp/issabel-empty-lab`	Issabel não instalado

6. Matriz de testes sugerida (suporte)¶

Cenário	Como testar	Critério OK
Portal hub	http://127.0.0.1:8099/	Apps visíveis, links abrem
Supervisor login	http://127.0.0.1:8080/login.php	HTTP 200 após restore `LorentzCTI.bak`
MonitorOPS	http://127.0.0.1:9090/	Login admin, diagnóstico verde
CTI dashboard	Portal → CTI	Página carrega; API pode retornar vazio
Licença	Portal → Licença	Gera `.lic` se API ativa
Scripts deploy	`deploy-lab-local.sh --stop` + redeploy	Containers sobem de novo
Pacote dist	Extrair `.tar.gz` + `prepare-support-install.sh`	Mesmo fluxo lab

7. Troubleshooting lab¶

Docker daemon inacessível (WSL)¶

docker info

Sintoma	Ação
Opção A (CE no WSL)	`sudo service docker start` (ou `sudo systemctl start docker`); confira grupo `docker` e novo login
Opção B (Desktop)	Abra o Docker Desktop; Settings → Resources → WSL integration ON na distro do lab
`docker` só em outra distro	`wsl -d Debian` (ou a distro que tem o Engine) — Cursor deve abrir esse terminal
Distro WSL `portainer`	Ignore para o lab; use Portainer container na distro com Docker

Portainer — timeout no setup inicial¶

Mensagem: Your Portainer instance timed out for security purposes.

wsl -d Debian -e docker restart portainer
# Abra http://localhost:9000 e crie o admin imediatamente

SQL Server OOM / container reinicia¶

Aumente RAM WSL para 8 GB
Reduza MSSQL_MEMORY_LIMIT_MB=1536 no .env

`check-pre-install.sh` falha em Issabel¶

Esperado no lab. Use --skip-check se RAM/Docker OK:

./scripts/deploy-lab-local.sh --skip-check

Porta em conflito¶

ss -tlnp | grep -E ':8080|:8099|:9090'
# Ajuste PORTAL_HTTP_PORT, SUPERVISOR_HTTP_PORT no .env

CTI com "Authentication failed" nos logs¶

Normal sem Issabel. Não bloqueia teste de Portal/Supervisor.

Acesso do browser Windows às URLs WSL¶

Use http://127.0.0.1:8099/ — WSL2 encaminha localhost automaticamente.
Se falhar, use o IP WSL: ip addr show eth0 dentro do Ubuntu.

8. Lab vs homologação LAN vs VPS¶

Homologação acessível por outros PCs em 192.168.144.89: 47 — Homologação Windows 11 / WSL.

	Lab WSL	Homolog `192.168.144.89`	VPS homolog
Custo	Zero	Zero (máquina de suporte)	EC2 / KVM
Issabel	Não	Não	Sim
Acesso	`127.0.0.1` neste PC	LAN `192.168.144.89`	IP público
Treino suporte UI/scripts	Ideal	Ideal	Ideal
Teste SIP/WebRTC	Não	Não	Sim
Script de referência	`deploy-lab-local.sh`	`deploy-lab-local.sh`	`deploy-all.sh`

9. Scripts relacionados¶

Script	Uso no lab
`deploy-lab-local.sh`	Deploy principal
`diagnose-stack.sh`	Status up/down
`validate-install.sh`	Validação pós-deploy (sem `--external`)
`prepare-support-install.sh`	Pacote dist sem fontes
`deploy-licenca.sh`	Profile licenca
`deploy-webphone.sh`	Profile webphone

10. Histórico¶

Data	Notas
2026-07-12	Doc + script `deploy-lab-local.sh` + `.env.lab.example`
2026-08-03	Docker CE no WSL (sem Desktop); Portainer lab; distro padrão Debian / Cursor
2026-09-28	Atalho para homologação LAN em 47