355 lines
8.1 KiB
Markdown
355 lines
8.1 KiB
Markdown
# 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.
|
||
|
||
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
|
||
```
|