# Deploy (Servidor Ubuntu) — LineGestao API + Front-end

Este guia consolida os passos para subir **back-end (API)** e **front-end** no seu servidor, usando Docker/Compose, com foco no cenário descrito (Ubuntu + usuário `deploy`).

> **Pré-requisitos**
> - Você já executou os passos 1–6 (SSH, updates, criação do usuário, Docker/Compose e UFW).
> - Você tem acesso ao repositório da API **e** ao repositório do front-end.

---

## 1) Estrutura de pastas recomendada

O `docker compose` do projeto da API referencia o front-end via caminho relativo. Mantenha as pastas como **irmãs**:

```
/home/deploy/apps/
├─ line-gestao-api
└─ line-gestao-frontend
```

Assim o compose consegue resolver algo como `../line-gestao-frontend`.

---

## 2) Clonar os repositórios no servidor

Como usuário `deploy`:

```bash
mkdir -p ~/apps
cd ~/apps

# API
git clone <URL_DO_REPO_DA_API> line-gestao-api

# Front-end
git clone <URL_DO_REPO_DO_FRONTEND> line-gestao-frontend
```

Se não puder usar Git, faça upload por SCP mantendo as pastas irmãs.

---

## 3) Criar o arquivo `.env` de produção

No servidor, dentro da pasta da API, crie/edite o `.env`:

```bash
cd ~/apps/line-gestao-api
nano .env
```

Exemplo (ajuste para o seu ambiente):

```
# Backend
ASPNETCORE_ENVIRONMENT=Production
JWT_KEY=<CHAVE_FORTE>

# Seed de admin (usado no startup)
SEED_ADMIN_EMAIL=admin@seu-dominio.com
SEED_ADMIN_PASSWORD=<SENHA_FORTE>

# Banco
POSTGRES_PASSWORD=<SENHA_FORTE>

# Front-end
FRONTEND_PUBLIC_URL=https://seu-dominio.com
```

> **Importante:** não comite o `.env` no Git.

---

## 4) Subir a stack com Docker Compose

### Alternativa principal (com domínio + HTTPS automático via Caddy)

Agora que o domínio está apontando para o servidor, use `docker-compose.domain.yml` para publicar em **HTTPS** com certificado automático (Let's Encrypt).

1. Ajuste o `.env` na pasta da API:

```env
DOMAIN=linegestao.inglinesystems.com.br
ACME_EMAIL=seu-email@dominio.com
FRONTEND_PUBLIC_URL=https://linegestao.inglinesystems.com.br
APP_USE_HTTPS_REDIRECTION=false
```

2. Libere portas públicas no firewall (uma vez):

```bash
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
```

3. Suba stack com Caddy:

```bash
cd ~/apps/line-gestao-api
docker compose -f docker-compose.domain.yml up -d --build
```

4. Valide certificado e API em HTTPS:

```bash
curl -Iv https://linegestao.inglinesystems.com.br/health
```

Resultado esperado:
- status `HTTP/2 200`
- certificado emitido para `linegestao.inglinesystems.com.br`

> Importante: no primeiro boot o Caddy pode levar alguns segundos para obter o certificado. Se falhar, confira se DNS já propagou e se as portas 80/443 estão acessíveis.


### Erro comum: `DOMAIN is required`

Se aparecer este erro ao subir `docker-compose.domain.yml`, o `.env` da API está sem a variável `DOMAIN`.

Corrija assim no servidor:

```bash
cd ~/apps/line-gestao-api
cp -n .env.example .env

# confirme variáveis mínimas
grep -E '^(DOMAIN|ACME_EMAIL|FRONTEND_PUBLIC_URL|JWT_KEY|POSTGRES_PASSWORD)=' .env

# se DOMAIN não aparecer, adicione
echo 'DOMAIN=linegestao.inglinesystems.com.br' >> .env
```

Depois suba novamente:

```bash
docker compose -f docker-compose.domain.yml up -d --build --remove-orphans
```

Comandos úteis de diagnóstico:

```bash
docker compose -f docker-compose.domain.yml logs -f caddy
docker compose -f docker-compose.domain.yml logs -f api
```

### Alternativa A (provisória e mais rápida): sem Caddy, expondo API direto

Se você ainda não tem acesso ao DNS/domínio no Wix, use o arquivo `docker-compose.prod.yml` deste repositório para publicar só a API (porta `8080`) e o banco.

```bash
cd ~/apps/line-gestao-api

docker compose -f docker-compose.prod.yml up -d --build
curl -i http://localhost:8080/health
```

Teste externo (do seu PC), trocando pelo IP público do servidor:

```bash
curl -i http://76.13.231.13:8080/health
```

> Se o UFW estiver ativo, libere a porta temporariamente: `sudo ufw allow 8080/tcp`.

### Stack completa (quando domínio/DNS estiver pronto)

```bash
cd ~/apps/line-gestao-api

docker compose up -d --build
```

Verificar containers e logs:

```bash
docker compose ps

docker compose logs -f --tail=200
```

---

## 5) Validação rápida

- API respondendo:

```bash
curl -I http://SEU_SERVIDOR:8080
```

- Logs do backend:

```bash
docker compose -f docker-compose.prod.yml logs api --tail=200
```

- Login admin:
  - Use `SEED_ADMIN_EMAIL` e `SEED_ADMIN_PASSWORD` do `.env`.

### Próximo passo após `HTTP 200` no `/health`

Se você já recebeu `HTTP/1.1 200 OK` em `http://localhost:8080/health` **e** no IP público (`http://SEU_IP:8080/health`), o back-end está pronto para testes funcionais.

Checklist recomendado:

1. Confirmar documentação da API:

```bash
curl -I http://SEU_IP:8080/swagger
```

2. Testar autenticação (via Swagger/UI ou cliente HTTP) com o admin seed.
3. Criar um registro real do seu fluxo principal (ex.: cliente/chamado/ordem) e validar leitura/listagem.
4. Verificar logs enquanto testa:

```bash
docker compose -f docker-compose.prod.yml logs -f api
```

---

## 5.1) Como testar o front-end agora (sem DNS)

Sem Wix/DNS, você ainda consegue testar o front-end por IP público. O essencial é apontar o front para a API externa:

- API base URL: `http://SEU_IP:8080`

Se o front for Vite/React (exemplo comum), configure algo como:

```env
VITE_API_URL=http://SEU_IP:8080
```

Depois gere e publique o front da forma que o repositório dele definir (build estático + servidor web/container).

Teste final esperado no navegador:

1. Abrir o front por IP (porta do front).
2. Fazer login com o admin seed.
3. Executar o fluxo principal da aplicação sem erro de CORS ou 401 inesperado.

> Se houver erro de CORS, ajuste `FRONTEND_PUBLIC_URL` no `.env` da API para a URL exata usada no navegador (incluindo porta), e recrie o container da API.

## 5.2) Passo a passo (copiar e colar) para subir o front no servidor

> Objetivo: abrir o front no navegador usando IP público, consumindo a API em `http://SEU_IP:8080`.

No servidor (SSH), como usuário `deploy`:

```bash
cd ~/apps/line-gestao-frontend

# 1) Atualiza código do front
git fetch --all --prune
git pull --ff-only origin <SUA_BRANCH_FRONT>

# 2) Configura URL da API para build de produção (Vite)
cat > .env.production << 'EOF'
VITE_API_URL=http://SEU_IP:8080
EOF

# 3) Build do front
npm ci
npm run build

# 4) Publica build estático do front em container Nginx (porta 4173)
docker rm -f linegestao-frontend 2>/dev/null || true
docker run -d \
  --name linegestao-frontend \
  --restart unless-stopped \
  -p 4173:80 \
  -v "$PWD/dist:/usr/share/nginx/html:ro" \
  nginx:alpine
```

Agora teste:

```bash
# no servidor
curl -I http://localhost:4173

# no seu computador
# http://SEU_IP:4173
```

Se a porta 4173 não abrir externamente, libere no firewall:

```bash
sudo ufw allow 4173/tcp
```

### Checklist final no navegador

1. Abrir `http://SEU_IP:4173`.
2. Fazer login com o usuário admin seed da API.
3. Navegar no fluxo principal (cadastro/listagem/edição) e confirmar persistência.
4. Se aparecer erro de CORS, setar `FRONTEND_PUBLIC_URL=http://SEU_IP:4173` no `.env` da API e recriar o backend:

```bash
cd ~/apps/line-gestao-api
docker compose -f docker-compose.prod.yml up -d --build
```

---

## 6) HTTPS (domínio público)

Você pode colocar **Nginx/Caddy** no host ou **Traefik** via Docker.

### Opção A — Traefik (recomendado em stack Docker)

- Traefik cuida do TLS/Let’s Encrypt.
- Exponha apenas **80/443**.
- API + Front ficam internos.

### Opção B — Nginx/Caddy no host

- Instala o Nginx/Caddy diretamente no VPS.
- Faz proxy para o container do front e da API.

> Se quiser, indique se prefere **subdomínios** (ex.: `api.seu-dominio.com` e `www.seu-dominio.com`) ou **mesmo domínio** (`/api` e `/`), para eu te passar o `docker-compose.prod.yml` com labels/rotas prontas.

---

## 7) Subir automaticamente após reboot (systemd)

Crie o serviço:

```bash
sudo nano /etc/systemd/system/linegestao.service
```

Conteúdo (ajuste o path se necessário):

```
[Unit]
Description=LineGestao Docker Compose
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/home/deploy/apps/line-gestao-api
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target
```

Ativar:

```bash
sudo systemctl daemon-reload
sudo systemctl enable linegestao
sudo systemctl start linegestao
sudo systemctl status linegestao
```

---

## 8) Boas práticas (produção)

- **Não exponha** Postgres (porta 5432) publicamente.
- Tenha rotina de **backup**:

```bash
docker exec -t <container_db> pg_dump -U <user> <db> > backup.sql
```

- Acompanhe logs:

```bash
docker compose logs -f --tail=200
```


## 5.3) Front-end + Back-end no mesmo servidor (com domínio)

Sim, é possível e esse é o fluxo recomendado quando os repositórios estão em pastas irmãs.

1. Build do front:

```bash
cd ~/apps/line-gestao-frontend

git fetch --all --prune
git pull --ff-only origin <SUA_BRANCH_FRONT>

cat > .env.production << 'EOF'
VITE_API_URL=https://linegestao.inglinesystems.com.br
EOF

npm ci
npm run build
```

2. Subir API + Caddy com HTTPS:

```bash
cd ~/apps/line-gestao-api
docker compose -f docker-compose.domain.yml up -d --build --remove-orphans
```

3. Testar no navegador:
- Front: `https://linegestao.inglinesystems.com.br`
- API health: `https://linegestao.inglinesystems.com.br/health`