# 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 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.

---

## 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
```