rede5/infracloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: add BookStack API token and domain details

Browse source
This commit is contained in:
Tiago Ribeiro 2026-02-23 17:24:53 -03:00
parent 31c1b00bee
commit 8c896cf2f2
9 changed files with 131 additions and 726 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
CONNECTIONS.md
View file

@ -8,11 +8,10 @@ Documento de referencia rapida para conexao aos servicos e servidores.
| Arquivo | Tipo | Servico |
|---------|------|---------|
| `lh-zeus` | Chave SSH privada | Redbull, Vim |
| `civo` | Chave SSH privada | Echo |
| `civo` | Chave SSH privada | Redbull, Echo |
| `github` | Chave SSH privada | GitHub |
| `ic-ad` | Chave SSH privada | Azure DevOps |
| `forgejo-gohorsejobs` | Chave SSH privada | Forgejo |
| `forgejo-token` | Token | Forgejo API |
| `cloudflare-token` | Token | Cloudflare API |
| `coolify-redbull-token` | Token | Coolify API |
| `github-token` | Token | GitHub PAT |
@ -88,20 +87,13 @@ ssh -p 18863 admin@db-60604.dc-us-1.absamcloud.com
| Propriedade | Valor |
|-------------|-------|
| Email | yamamoto@rede5.com.br |
| Email | `<email>` |
| Token | `~/.ssh/cloudflare-token` |
### Zones
| Zone | Zone ID |
|------|---------|
| gohorsejobs.com | `5e7e9286849525abf7f30b451b7964ac` |
| rede5.com.br | `7eb6587a2c867bb9743719a8fabcd455` |
```bash
export CF_AUTH_EMAIL="yamamoto@rede5.com.br"
export CF_AUTH_EMAIL="<email>"
export CF_AUTH_KEY=$(cat ~/.ssh/cloudflare-token)
export CF_ZONE_ID="5e7e9286849525abf7f30b451b7964ac"
export CF_ZONE_ID="<zone_id>"
# Listar DNS records
curl -s -H "X-Auth-Email: $CF_AUTH_EMAIL" -H "X-Auth-Key: $CF_AUTH_KEY" \
@ -206,7 +198,6 @@ curl -s -X POST -H "access-token: $ABSAM_ACCESS_TOKEN" \
|-------------|-------|
| URL | https://pipe.gohorsejobs.com |
| Token | `~/.ssh/forgejo-token` |
| Usuario | yamamoto |
**Acesso:** API apenas (SSH nao configurado)
@ -220,7 +211,7 @@ curl -H "Authorization: token $TOKEN" "https://pipe.gohorsejobs.com/api/v1/user"
curl -H "Authorization: token $TOKEN" "https://pipe.gohorsejobs.com/api/v1/user/repos"
# Clone via HTTPS
git clone https://yamamoto:$TOKEN@pipe.gohorsejobs.com/<repo>
git clone https://<usuario>:$TOKEN@pipe.gohorsejobs.com/<repo>
```
---
@ -229,8 +220,8 @@ git clone https://yamamoto:$TOKEN@pipe.gohorsejobs.com/<repo>
| Propriedade | Valor |
|-------------|-------|
| Server | everest.mxrouting.net |
| Username | net5cloud |
| Server | <server> |
| Username | <username> |
| API Key | `~/.ssh/mxroute-api-key` |
```bash
@ -238,14 +229,14 @@ API_KEY=$(grep "API-Key" ~/.ssh/mxroute-api-key | cut -d' ' -f2)
# Listar dominios
curl -X GET "https://api.mxroute.com/domains" \
-H "X-Server: everest.mxrouting.net" \
-H "X-Username: net5cloud" \
-H "X-Server: <server>" \
-H "X-Username: <username>" \
-H "X-API-Key: $API_KEY"
# Listar contas de email
curl -X GET "https://api.mxroute.com/accounts/<dominio>" \
-H "X-Server: everest.mxrouting.net" \
-H "X-Username: net5cloud" \
-H "X-Server: <server>" \
-H "X-Username: <username>" \
-H "X-API-Key: $API_KEY"
```
@ -259,7 +250,7 @@ Criar/editar `~/.ssh/config`:
Host redbull
HostName 185.194.141.70
User root
IdentityFile ~/.ssh/lh-zeus
IdentityFile ~/.ssh/civo
IdentitiesOnly yes
Host echo
@ -268,12 +259,6 @@ Host echo
IdentityFile ~/.ssh/civo
IdentitiesOnly yes
Host vim
HostName 38.19.201.52
User root
IdentityFile ~/.ssh/lh-zeus
IdentitiesOnly yes
Host absam-db
HostName db-60604.dc-us-1.absamcloud.com
User admin
@ -287,7 +272,6 @@ Apos configurar:
```bash
ssh redbull
ssh echo
ssh vim
ssh absam-db
```

1
OBJECT-STORAGE.md
View file

@ -19,6 +19,7 @@ Servicos de armazenamento de objetos para backup e credenciais.
|-------------|-------|
| Endpoint | https://eu-west-1.euronodes.com |
| Region | eu-west-1 |
| Buckets | rede5, vault |
| Arquivo | `~/.ssh/euronodes-object-storage` |
---

4
README.md
View file

@ -16,7 +16,7 @@ infracloud/
└── vps/ # Virtual Private Servers
├── redbull/ # Coolify DEV (185.194.141.70)
├── echo/ # Dokku PROD (152.53.120.181)
├── vim/ # Dokku PROD (38.19.201.52)
└── absam-db/ # Cloud Database (Absam.io)
```
@ -26,7 +26,7 @@ infracloud/
|----------|-----|------------|--------------|
| Redbull | 185.194.141.70 | Coolify v4 | [vps/redbull](./vps/redbull/) |
| Echo | 152.53.120.181 | Dokku | [vps/echo](./vps/echo/) |
| Vim | 38.19.201.52 | Dokku | [vps/vim](./vps/vim/) |
| Absam DB | db-60604.dc-us-1.absamcloud.com:11985 | PostgreSQL 17 | [vps/absam-db](./vps/absam-db/) |
## Projetos

101
inventcloud/invista/nexus/OPERATIONS.md
View file

@ -4,6 +4,107 @@ Registro de operacoes e incidentes na infraestrutura.
---
## 2026-02-23 - Investigacao: Acesso Publico MFE e Decisao de Arquitetura
### Contexto
Investigar como expor o MFE (mfe-user) publicamente para acesso via browser.
O API Gateway MFE provisionado anteriormente e PRIVATE (IP 10.110.198.250), sem IP publico.
### Descoberta 1: Como os Microservicos (ms-user, ms-poc) funcionam
```
Browser
-> DNS ms-user.dev.invista.com.br = 137.131.236.202 (A record, Cloudflare, PROXIED=false)
-> ingress-nginx-external-controller (LB publico OKE, IP 137.131.236.202)
-> Ingress rule (hostname match)
-> Service -> Pod (no cluster OKE)
```
A pipeline dos MSs:
1. Build + Push imagem pro OCIR
2. Deploy via ArgoCD no OKE
3. Template `cd/cloudflare-dns.yml` (repo `azure-pipelines-templates`, branch `feature/cd-deploy-oci-oke`):
- Pega IP do `ingress-nginx-external-controller` via kubectl
- Usa `CLOUDFLARE_API_TOKEN` (Variable Group `oci-terraform`) para chamar API Cloudflare
- Cria/atualiza registro A na zona `invista.com.br`
**IPs relevantes:**
- Ingress NGINX External: `137.131.236.202` (publico)
- Ingress NGINX Internal: `10.110.143.54` (privado)
### Descoberta 2: SRV-TUNNEL e Cloudflare Access
O dominio `crivo-dev.invista.com.br` resolve para IPs Cloudflare (104.26.6.132 etc.) e redireciona para `invistacloud.cloudflareaccess.com` (autenticacao).
```
Browser -> Cloudflare (proxy, IPs publicos)
-> Cloudflare Access (autenticacao)
-> Cloudflare Tunnel (cloudflared)
-> SRV-TUNNEL (10.6.0.145, OCI instance RUNNING)
-> LB Test_Crivo_Dev (10.8.4.127)
```
| Componente | Detalhe |
|-----------|---------|
| Cloudflare Account | `invistacloud` (sem acesso disponivel) |
| SRV-TUNNEL | OCID: `ocid1.instance.oc1.sa-saopaulo-1.antxeljrsks3ylic7eg7dezyq4rojzt7wvupizviezu2isazb6y6yncl2aza` |
| SRV-TUNNEL IP | 10.6.0.145 (privado, sem IP publico) |
| LB Test_Crivo_Dev | 10.8.4.127, VCN-Shared (10.8.0.0/16) |
### Descoberta 3: Template cloudflare-dns.yml
Encontrado no repo `azure-pipelines-templates`, branch `feature/cd-deploy-oci-oke`:
| Arquivo | Funcao |
|---------|--------|
| `cd/cloudflare-dns.yml` | Template Azure DevOps - pega IP do ingress, chama script |
| `cd/scripts/update_cloudflare_dns.sh` | Script bash - busca zone ID, cria/atualiza registro A via API Cloudflare |
O script:
1. Busca Zone ID de `invista.com.br` via API Cloudflare
2. Verifica se registro ja existe
3. Cria (POST) ou atualiza (PUT) registro A com TTL 60s
4. Usa `CLOUDFLARE_API_TOKEN` do Variable Group
### Problema: MFE nao tem IP publico
| | ms-user/ms-poc | mfe-user |
|--|---------------|----------|
| Onde roda | Pod no cluster OKE | Arquivos estaticos no bucket |
| Entrada | Ingress NGINX External (IP publico) | API Gateway PRIVATE (IP privado) |
| IP publico | 137.131.236.202 | Nenhum |
O MFE nao roda no cluster, roda no Object Storage via API Gateway.
Nao e possivel usar o mesmo ingress-nginx que os MSs usam.
### Decisao: API Gateway PUBLIC
**Solucao adotada**: Recriar o API Gateway como **PUBLIC** (em vez de PRIVATE).
O API Gateway PUBLIC recebe um IP publico da OCI, e o DNS pode apontar direto.
```
Browser
-> DNS mfe-user-dev.invista.com.br = <IP publico do API GW> (A record, Cloudflare)
-> API Gateway PUBLIC (IP publico, OCI)
-> Object Storage (bucket nexus-mfe-user-development)
-> index.html / assets Angular SPA
```
Vantagens:
- Mesmo padrao de DNS dos MSs (Cloudflare API + A record)
- Nao depende do Cloudflare Tunnel (conta invistacloud sem acesso)
- Nao precisa de VCN peering nem LB intermediario
### Acoes pendentes
1. Alterar Terraform: `endpoint_type = "PUBLIC"` no modulo api_gateway_mfe
2. Rodar pipeline para reprovisionar o API Gateway
3. Obter novo IP publico
4. Criar pipeline/script para configurar DNS via `CLOUDFLARE_API_TOKEN`
---
## 2026-02-23 - API Gateway MFE: Terraform, Pipeline, Rede e LB
### Contexto

20
vps/redbull/services_inventory.md
View file

@ -46,12 +46,20 @@ Este documento apresenta o inventario completo de servicos hospedados no servido
## Tabela de Serviços (Coolify Services)
| Serviço | UUID | Status |
|---------|------|:------:|
| **BookStack** | `ogs4okgoosk48cswoo0s4k84` | ✅ Running |
| **Vaultwarden** | `h8wg0gogw44swosgk8wgc8cs` | ✅ Healthy |
| **forgejo** | `zskgc8sck4w8g8w0o4w44o40` | ❌ Exited |
| **supabase** | `hk0ogck8w0co0skc0c8g0ss0` | ❌ Exited |
| Serviço | UUID | Domínio | Status |
|---------|------|---------|:------:|
| **BookStack** | `ogs4okgoosk48cswoo0s4k84` | docs.rede5.com.br | ✅ Running |
| **Vaultwarden** | `h8wg0gogw44swosgk8wgc8cs` | vault.rede5.com.br | ✅ Healthy |
| **forgejo** | `zskgc8sck4w8g8w0o4w44o40` | - | ❌ Exited |
| **supabase** | `hk0ogck8w0co0skc0c8g0ss0` | - | ❌ Exited |
### BookStack API
| Propriedade | Valor |
|-------------|-------|
| URL | https://docs.rede5.com.br |
| Token | `~/.ssh/bookstack-token` (Token ID:Token Secret) |
| DB | MariaDB 10.11 (bookstackapp) |
## Webhooks GitHub

76
vps/vim/README.md
View file

@ -1,76 +0,0 @@
# Vim - Servidor de Produção
Este repositório contém a documentação técnica e os guias de operação para o servidor Vim, uma VPS dedicada ao deployment de aplicações utilizando a plataforma Dokku.
## Visão Geral
O servidor Vim é uma infraestrutura de produção que hospeda múltiplas aplicações web, seguindo uma arquitetura baseada em contêineres. A plataforma Dokku serve como camada de gerenciamento de aplicações, similar a um Heroku self-hosted, permitindo deploys rápidos através de Git pushes. O Nginx atua como proxy reverso, roteando o tráfego baseado em domínios para as aplicações corretas.
Este servidor complementa a infraestrutura existente do projeto Infracloud, que já inclui o servidor Apolo com Kubernetes (K3s). Enquanto o Apolo foi projetado para cargas de trabalho que se beneficiam de orquestração complexa e alta disponibilidade, o Vim foca em simplicidade e deploy rápido para aplicações que não necessitam de escala massiva.
## Especificações do Servidor
| Recurso | Especificação |
|---------|---------------|
| **Plataforma** | VPS com Ubuntu/Debian |
| **Orquestrador** | Dokku (PaaS self-hosted) |
| **Container Runtime** | Docker |
| **Proxy Reverso** | Nginx |
| **Bancos de Dados** | PostgreSQL 17 e 18.1 (gerenciados) |
| **Cache** | Redis |
## Projetos Hospedados
O servidor Vim atualmente hospeda três projetos principais:
- **GoHorse**: Ecossistema completo com backend, frontend, backoffice, seeder e jobs processor
- **Sextando**: Plataforma com API e frontend separados
- **Agno Orquestrador**: Serviço de orquestração dedicado
## Documentação
A documentação completa está organizada nos seguintes arquivos:
- [Arquitetura do Sistema](./architecture.md): Diagrama detalhado e descrição dos componentes
- [Inventário de Serviços](./services_inventory.md): Tabela completa de apps, bancos, portas e domínios
- [Guia de Deploy](./deployment_guide.md): Instruções passo a passo para deployment e manutenção
## Quick Start para Deploy
```bash
# Adicionar remote Dokku
git remote add dokku dokku@vim.rede5.com.br:nome-do-app
# Fazer deploy
git push dokku main:master
```
Consulte o [deployment_guide.md](./deployment_guide.md) para instruções detalhadas.
## Estrutura de Diretórios
```
vim/
├── README.md # Este arquivo
├── architecture.md # Arquitetura detalhada do sistema
├── services_inventory.md # Inventário completo de serviços
└── deployment_guide.md # Guia de deploy e manutenção
```
## Boas Práticas
Sempre siga estas práticas ao fazer deploy no servidor Vim:
1. **Variáveis de Ambiente**: Configure todas as variáveis necessárias antes do deploy
2. **Bancos de Dados**: Utilize os bancos existentes (postgres-main ou agno-db) ou crie novos conforme necessidade
3. **SSL**: Para domínios de produção, habilite HTTPS
4. **Logs**: Monitore os logs após cada deploy
5. **Testes**: Teste a aplicação em staging antes de fazer deploy em produção
## Suporte
Para dúvidas ou problemas com deployment, consulte:
1. [deployment_guide.md](./deployment_guide.md) - Seção de troubleshooting
2. [services_inventory.md](./services_inventory.md) - Verificar configuração atual
3. Architecture - Entender como os componentes interagem

124
vps/vim/architecture.md
View file

@ -1,124 +0,0 @@
# Arquitetura do Sistema Vim
Este documento descreve a arquitetura detalhada dos serviços hospedados no servidor Vim, que utiliza Dokku como plataforma de deploy PaaS (Platform as a Service) self-hosted.
## Visão Geral da Arquitetura
O servidor Vim opera como uma plataforma de hospedagem de aplicações baseada em contêineres, utilizando o Dokku como camada de abstração sobre o Docker. Esta arquitetura permite o deploy rápido de aplicações diversas sem a complexidade de um cluster Kubernetes completo, sendo ideal para projetos de médio porte e equipes que precisam de simplicidade na gestão de deploys.
A infraestrutura é composta por três camadas principais: a camada de proxy reverso (Nginx), a camada de aplicação (Dokku com Docker) e a camada de dados (PostgreSQL gerenciado pelo Dokku). O Nginx atua como ponto de entrada para todo o tráfego HTTP/HTTPS, direcionando as requisições para os apps corretos baseando-se no domínio solicitado. O Dokku gerencia os contêineres das aplicações, criando automaticamente imagens Docker a partir do código fonte pushado via Git e expondo as aplicações em portas internas que o Nginx redireciona.
## Diagrama de Arquitetura
```mermaid
flowchart TB
subgraph Internet ["Internet"]
direction LR
Users1((Usuários))
Devs((Desenvolvedores))
end
subgraph Vim ["Servidor Vim"]
subgraph Proxy ["Proxy Reverso"]
Nginx[Nginx<br/>Ports: 80, 443]
end
subgraph Dokku ["Plataforma Dokku"]
DCore[Dokku Core<br/>Dokku<br/>Docker<br/>Buildpacks]
subgraph Apps ["Aplicações Hospedadas"]
direction LR
GoHorseBE[GoHorse<br/>Backend]
GoHorseFE[GoHorse<br/>Frontend]
GoHorseBO[GoHorse<br/>Backoffice]
GoHorseSD[GoHorse<br/>Seeder]
GoHorseJobs[GoHorse<br/>Jobs]
Sextando[API<br/>Sextando]
SextandoFE[Frontend<br/>Sextando]
Agno[Agno<br/>Orquestrador]
end
end
subgraph Databases ["Bancos de Dados"]
PGMain[(PostgreSQL<br/>Main)]
PGAgno[(PostgreSQL<br/>Agno-DB)]
end
subgraph Cache ["Camada de Cache"]
Redis[(Redis)]
end
subgraph Storage ["Armazenamento"]
Volumes[Volumes<br/>Docker]
end
end
Internet -->|HTTPS/443| Nginx
Devs -->|Git Push| Nginx
Nginx -->|Route by Host| DCore
DCore --> GoHorseBE
DCore --> GoHorseFE
DCore --> GoHorseBO
DCore --> GoHorseSD
DCore --> GoHorseJobs
DCore --> Sextando
DCore --> SextandoFE
DCore --> Agno
GoHorseBE --> PGMain
GoHorseJobs --> PGMain
Sextando --> PGMain
Agno --> PGAgno
GoHorseJobs --> Redis
GoHorseBE --> Volumes
GoHorseFE --> Volumes
Sextando --> Volumes
SextandoFE --> Volumes
```
## Descrição dos Componentes
### Camada de Proxy Reverso
O Nginx funciona como proxy reverso principal, escutando nas portas 80 (HTTP) e 443 (HTTPS). Ele recebe todas as requisições externas e as direciona para os apps corretos baseando-se no cabeçalho Host da requisição. O Nginx também é responsável por terminar o TLS para as conexões HTTPS, fornecendo certificados SSL para os domínios configurados. Esta camada é crítica para a segurança e performance das aplicações, pois concentra o tráfego e permite configuraçõescentralizadas de cache, compressão e balanceamento de carga.
A configuração do Nginx para o Dokku utiliza mapeamento dinâmico de portas. Quando um app é criado no Dokku, ele recebe uma porta aleatória alta (greater than 10000), e o Dokku configura automaticamente o Nginx para rotear o tráfego do domínio configurado para essa porta específica. Este sistema permite que múltiplas aplicações coexistam no mesmo servidor sem conflitos de portas.
### Plataforma Dokku
O Dokku é a peça central da infraestrutura, funcionando como um mini PaaS similar ao Heroku. Ele automatiza o processo de deployment de aplicações, desde o recebimento do código via Git até a disponibilização do container rodando. O Dokku utiliza buildpacks para detectar automaticamente a linguagem de programação da aplicação e escolher o processo de build adequado, suportando Node.js, Python, Go, Ruby, Java, PHP e outras linguagens.
Cada aplicação no Dokku roda em seu próprio container isolado, com variáveis de ambiente configuráveis e links para serviços externos como bancos de dados PostgreSQL e Redis. O Dokku também gerencia automaticamente a reconstrução de containers quando novas versões são pushadas, facilitando significativamente o fluxo de CI/CD.
### Aplicações Hospedadas
O ecossistema do servidor Vim é composto por três projetos principais: GoHorse, Sextando e Agno Orquestrador. Cada um destes projetos segue uma arquitetura de microservices com frontend, backend e eventualmente serviços auxiliares como seeders e jobs.
O GoHorse é o ecossistema mais completo, composto por cinco aplicações distintas. O backend (gohorse-backend) expõe a API principal na porta 5000 e conecta-se ao PostgreSQL main para persistência de dados. O frontend (gohorse-frontend) é a interface web principal доступна na porta 3000. O backoffice (gohorse-backoffice) é a área administrativa disponível na porta 3001. O seeder (gohorse-seeder) é um serviço auxiliar que popula o banco de dados com dados iniciais ou de teste. O gohorsejobs é um serviço de processamento de tarefas assíncronas que utiliza Redis para gerenciamento de filas.
O projeto Sextando também segue uma arquitetura similar, com uma API backend e um frontend separado. Ambos os componentes estão configurados com SSL e acessível via domínios próprios. O Agno Orquestrador é um serviço especializado que utiliza seu próprio banco de dados PostgreSQL (agno-db) isolado do banco principal.
### Camada de Dados
O servidor utiliza PostgreSQL 17 como banco de dados principal, gerenciado pelo plugin Dokku Postgres. O banco "postgres-main" é compartilhado entre as aplicações GoHorse e Sextando, permitindo que cada aplicação tenha seu próprio schema dentro do mesmo banco. Esta abordagem é eficiente em termos de recursos, mas requer cuidado com a nomeação de tabelas para evitar conflitos entre os projetos.
Existe também um banco dedicado "agno-db" rodando PostgreSQL 18.1, utilizado exclusivamente pelo serviço Agno Orquestrador. Esta separação é intencional para isolar os dados de aplicações críticas e permitir diferentes configurações de backup e manutenção para cada serviço.
### Camada de Cache
O Redis é utilizado principalmente pelo serviço GoHorse Jobs para gerenciamento de filas de tarefas assíncronas. O Redis fornece persistência opcional e é configurado com um limite de memória de 128MB, o que é suficiente para o volume atual de jobs processados. A utilização do Redis permite que tarefas pesadas sejam processadas em background sem impactar a responsividade das APIs principais.
## Fluxo de Dados
O fluxo de uma requisição típica começa quando um usuário acessa um domínio configurado, como "gohorsejobs.dokku.rede5.com.br". A requisição chega ao servidor na porta 443 (HTTPS) e é recibida pelo Nginx. O Nginx verifica o domínio solicitado e faz proxy_pass para a porta interna onde o container Dokku está escutando. O container processa a requisição, eventualmente consultando o PostgreSQL ou Redis, e retorna a resposta que segue o caminho inverso até o usuário.
Para deploys, o fluxo começa quando um desenvolvedor faz "git push dokku main" para o repositório Git do projeto. O Dokku recebe o push, detecta a linguagem da aplicação via buildpack, executa o build appropriate (npm install e build para Node.js, por exemplo), cria uma nova imagem Docker e substitui o container antigo pelo novo. Após alguns segundos, a nova versão está disponível em produção.
## Considerações de Segurança
A arquitetura atual implementa várias camadas de segurança. O isolamento de containers garante que cada aplicação tenha seu próprio ambiente isolado, impedindo que falhas de segurança em uma aplicação comprometam as outras. O Nginx como proxy reverso permite configuração centralizada de TLS e cabeçalhos de segurança. As variáveis de ambiente sensíveis (como senhas de banco) são armazenadas no contexto do Dokku e não são expostas nos containers.
Recomenda-se futuramente implementar variáveis de ambiente sensíveis através do plugin Dokku Docker Options e considerar a adição de um WAF (Web Application Firewall) para proteção contra ataques comuns como SQL injection e XSS.

393
vps/vim/deployment_guide.md
View file

@ -1,393 +0,0 @@
# Guia de Deploy e Manutenção - Vim
Este guia descreve o processo completo para implantar, atualizar e manter serviços no servidor Vim utilizando a plataforma Dokku.
## Visão Geral da Plataforma
O servidor Vim utiliza o Dokku como plataforma de deploy PaaS (Platform as a Service) self-hosted. O Dokku é uma ferramenta open-source que transforma um servidor Linux em um PaaS similar ao Heroku, permitindo o deploy de aplicações através de Git pushes. A plataforma utiliza o Docker para isolar as aplicações e o Nginx como proxy reverso para roteamento de tráfego baseado em domínios.
Esta arquitetura foi escolhida por oferecer um equilíbrio entre simplicidade e funcionalidade. Diferente de um cluster Kubernetes completo, o Dokku não requer conhecimento avançado de contêineres e permite que desenvolvedores façam deploys apenas com conhecimento de Git. A plataforma detecta automaticamente a linguagem de programação da aplicação (Node.js, Go, Python, etc.) através de buildpacks e configura o ambiente de execução apropriado.
## Pré-requisitos
Antes de fazer deploy no servidor Vim, certifique-se de ter os seguintes pré-requisitos atendidos:
Primeiro, você precisa de acesso SSH ao servidor com chave SSH configurada. A chave pública deve estar autorizada no arquivo `~/.ssh/authorized_keys` do servidor. Sem isso, você não conseguirá fazer o push do código. Segundo, você precisa do Dokku client instalado localmente. Em sistemas Debian/Ubuntu, instale com `sudo apt-get install dokku`. Terceiro, você precisa ter o Git instalado em sua máquina de desenvolvimento. E quarto, o repositório da aplicação deve ter um Dockerfile ou um dos buildpacks suportados (Node.js, Go, Python, Ruby, Java, PHP, Gradle, .NET Core).
## Estrutura de Repositórios
Cada projeto deve seguir uma estrutura específica para funcionar corretamente no Dokku. O repositório precisa ter um arquivo de configuração apropriado para a linguagem utilizada. Para Node.js, é necessário ter um `package.json` com scripts de start definidos. Para Go, o `go.mod` é essencial. O Dokku detecta automaticamente a linguagem e aplica o buildpack correto.
Abaixo está um exemplo de `package.json` otimizado para Dokku:
```json
{
"name": "gohorse-backend",
"version": "1.0.0",
"main": "dist/index.js",
"scripts": {
"start": "node dist/index.js",
"build": "tsc",
"dev": "nodemon src/index.ts"
},
"dependencies": {
"express": "^4.18.2",
"pg": "^8.11.0"
},
"devDependencies": {
"typescript": "^5.0.0",
"@types/node": "^20.0.0"
}
}
```
Para aplicações Go, o `go.mod` deve seguir este formato:
```go
module github.com/sua-empresa/gohorse-backend
go 1.21
require (
github.com/gin-gonic/gin v1.9.1
github.com/lib/pq v1.10.9
)
```
## Fazendo o Primeiro Deploy
O processo de deploy no Dokku é simples e segue o fluxo similar ao Heroku. Primeiro, você precisa adicionar o remote do Dokku ao seu repositório Git local. No diretório do seu projeto, execute o comando para adicionar o remote Dokku, substituindo o nome do app e o usuário:
```bash
git remote add dokku dokku@vim.rede5.com.br:gohorse-backend
```
Este comando configura o remote "dokku" apontando para o servidor Vim. Note que o nome após os dois pontos deve corresponder exatamente ao nome do app que você criou no Dokku. Se o app se chamar "gohorse-backend", você deve usar "gohorse-backend" no remote.
Se o app ainda não existe no Dokku, você pode criá-lo diretamente com o push:
```bash
git push dokku main:master
```
Quando o Dokku recebe o primeiro push para um app que não existe, ele automaticamente cria o app e inicia o processo de deploy. Se preferir criar o app manualmente antes do primeiro deploy, você pode SSH no servidor e executar:
```bash
dokku apps:create gohorse-backend
```
## Configurando Variáveis de Ambiente
As variáveis de ambiente são essenciais para o funcionamento correto das aplicações. No Dokku, você pode definir variáveis de ambiente tanto pelo servidor quanto através de arquivos `.env`. Para definir uma variável de ambiente pelo terminal, primeiro faça SSH no servidor:
```bash
ssh root@vim.rede5.com.br
```
Então, defina a variável para o app específico:
```bash
dokku config:set gohorse-backend DATABASE_URL=postgres://user:password@host:5432/dbname
dokku config:set gohorse-backend NODE_ENV=production
dokku config:set gohorse-backend PORT=5000
```
Para ver todas as variáveis de um app:
```bash
dokku config gohorse-backend
```
Para desenvolvimento local, crie um arquivo `.env` na raiz do projeto (que deve estar no `.gitignore`):
```
DATABASE_URL=postgres://postgres:password@localhost:5432/gohorse_dev
NODE_ENV=development
PORT=5000
```
Em aplicações Node.js, utilize a biblioteca `dotenv` para carregar essas variáveis:
```typescript
import dotenv from 'dotenv';
dotenv.config();
const port = process.env.PORT || 3000;
const dbUrl = process.env.DATABASE_URL;
```
## Configurando Bancos de Dados PostgreSQL
O servidor Vim possui dois bancos de dados PostgreSQL gerenciados pelo Dokku: o `postgres-main` (versão 17) e o `agno-db` (versão 18.1). Para conectar uma aplicação a um banco de dados, você deve criar um link entre o serviço e o app.
Para criar o link (isso automaticamente define a variável DATABASE_URL):
```bash
dokku postgres:link postgres-main gohorse-backend
```
Para desvincular:
```bash
dokku postgres:unlink postgres-main gohorse-backend
```
Para criar um novo banco de dados:
```bash
dokku postgres:create meu-novo-banco
dokku postgres:link meu-novo-banco minha-app
```
Para verificar informações do banco:
```bash
dokku postgres:info postgres-main
dokku postgres:list
```
## Configurando Domínios e SSL
O Dokku permite configurar domínios customizados para cada aplicação. Para adicionar um domínio:
```bash
dokku domains:set gohorse-backend gohorse.dokku.rede5.com.br
```
Para habilitar HTTPS com Let's Encrypt (plugin instalado):
```bash
dokku letsencrypt:enable gohorse-backend
```
Para renewal automático de certificados:
```bash
dokku letsencrypt:auto-renew gohorse-backend
```
Sem o plugin Let's Encrypt, você pode configurar SSL manualmente através do Nginx ou usando certificados propios. O Nginx do servidor Vim está configurado para aceitar conexões HTTPS nas portas 80 e 443, então você pode também gerenciar certificados manualmente se preferir.
## Mapeamento de Portas
O Dokku expõe automaticamente as aplicações em portas dinâmicas. Por padrão, ele usa a variável PORT definida no ambiente do container. Para configurar o mapeamento de portas explicitamente:
```bash
dokku ports:set gohorse-backend http:80:5000
```
Este comando mapeia a porta 80 do host para a porta 5000 do container. Para múltiplas portas (HTTP e HTTPS):
```bash
dokku ports:set gohorse-backend http:80:8080 https:443:8080
```
## Comandos de Deploy
### Deploy Padrão
Para fazer o deploy de uma nova versão, basta fazer push para o remote Dokku:
```bash
git push dokku main:master
```
O Dokku mostrará o progresso do build e informará quando o deploy estiver completo. Você pode acompanhar os logs do deploy em tempo real.
### Rollback
Se algo der errado após o deploy, você pode fazer rollback para a versão anterior:
```bash
dokku releases:rollback gohorse-backend
```
Para ver o histórico de releases:
```bash
dokku releases gohorse-backend
```
### Deploy com Build Especial
Se você precisa fazer build local e apenas enviar a imagem:
```bash
docker build -t dokku/gohorse-backend:latest .
docker push dokku/gohorse-backend:latest
dokku deploy gohorse-backend
```
## Gerenciando Serviços
### Verificar Status
Para ver o status de uma aplicação:
```bash
dokku apps:info gohorse-backend
```
Para ver os logs em tempo real:
```bash
dokku logs gohorse-backend -t
```
Para ver logs de uma quantidade específica de linhas:
```bash
dokku logs gohorse-backend -n 100
```
### Reiniciar Aplicação
```bash
dokku ps:restart gohorse-backend
```
### Parar e Iniciar
```bash
dokku ps:stop gohorse-backend
dokku ps:start gohorse-backend
```
### Escalar Aplicação
O Dokku suporta múltiplas instâncias de um app (apenas para Dockerfiles):
```bash
dokku ps:scale gohorse-backend=2
```
## Configurando Persistent Storage
Se sua aplicação precisa de armazenamento persistente (uploads, arquivos, etc.), você pode configurar volumes:
```bash
dokku storage:mount gohorse-backend /var/lib/dokku/gohorse-backend/uploads:/app/uploads
```
O primeiro caminho é no host (servidor) e o segundo é dentro do container. Após adicionar um mount, reinicie o app:
```bash
dokku ps:restart gohorse-backend
```
Para listar mounts:
```bash
dokku storage:list gohorse-backend
```
## Troubleshooting
### Aplicação Não Inicia
Se o container não inicia, verifique os logs:
```bash
dokku logs gohorse-backend
```
Erros comuns incluem: variável PORT incorreta (o Dokku define automaticamente a variável PORT baseado no Dockerfile ou Procfile), dependências faltando no package.json ou go.mod, e banco de dados não vinculado corretamente.
### Erro de Build
Se o build falha, verifique a saída do comando git push. Erros comuns incluem: versão do Node/Go não compatível, memória insuficiente durante o build (pode precisar de swap), e dependências privadas não acessíveis.
### Problemas de Conexão com Banco
Se a aplicação não conecta ao banco: verifique se o link foi criado corretamente com `dokku postgres:info postgres-main`, confirme que a variável DATABASE_URL está correta com `dokku config gohorse-backend`, e verifique se o banco está rodando com `dokku postgres:status postgres-main`.
### Container em Estado de Crash
Se o container está constantemente reiniciando:
```bash
dokku logs gohorse-backend --num 50
```
Pode ser necessário ajustar a configuração de healthcheck ou verificar se há erros de inicialização no código.
## Checklist de Boas Práticas
Antes de fazer deploy para produção, siga esta checklist:
Garanta que o arquivo Procfile ou Dockerfile esteja correto e defina o comando de start apropriado. Para Node.js com package.json, o Dokku detecta automaticamente. Para outros casos, crie um Procfile:
```
web: npm start
worker: npm run worker
```
Confirme que todas as variáveis de ambiente necessárias estão configuradas no Dokku. O banco de dados está linkado corretamente. Os domínios estão configurados e DNS está apontando para o servidor. Os certificados SSL estão válidos (se aplicável). Os logs estão funcionando e você consegue acessar para debugar.
## Limpeza e Manutenção
Para limpar recursos não utilizados:
```bash
# Limpar containers Docker órfãos
docker container prune -f
# Limpar imagens não utilizadas
docker image prune -a -f
# Limpar volumes não utilizados
docker volume prune -f
# Limpar builds antigos do Dokku
dokku cleanup
```
Para verificar uso de disco:
```bash
df -h
docker system df
```
## Referência Rápida de Comandos
| Ação | Comando |
|------|---------|
| Listar apps | `dokku apps:list` |
| Criar app | `dokku apps:create nome-app` |
| Deletar app | `dokku apps:destroy nome-app` |
| Ver config | `dokku config nome-app` |
| Setar config | `dokku config:set nome-app CHAVE=valor` |
| Ver logs | `dokku logs nome-app -t` |
| Reiniciar | `dokku ps:restart nome-app` |
| Listar bancos | `dokku postgres:list` |
| Info banco | `dokku postgres:info nome-banco` |
| Link banco | `dokku postgres:link nome-banco nome-app` |
## GoHorseJobs - Fluxo Git
O gohorsejobs eh um monorepo hospedado em dois remotes. O **GitHub eh a origem de desenvolvimento** e o **Forgejo eh mirror**.
### Remotes
| Remote | URL | Funcao |
|--------|-----|--------|
| origin | github.com/rede5/gohorsejobs | Desenvolvimento (PRs, CI) |
| pipe | pipe.gohorsejobs.com/bohessefm/gohorsejobs | Mirror Forgejo |
| dokku | dokku@localhost:gohorsejobs | Deploy app principal |
| dokku-frontend | dokku@localhost:gohorse-frontend | Deploy frontend |
### Sincronizacao GitHub -> Forgejo
```bash
cd /root/gohorsejobs
git pull origin dev # Puxa do GitHub
git push pipe dev # Envia para Forgejo
```
Repetir para branches `main` e `hml` conforme necessario.
### Regra: GitHub primeiro, Forgejo depois
Todo codigo novo entra via GitHub (PRs, Codex, commits diretos). O Forgejo recebe via push manual na VPS. Nunca commitar direto no Forgejo.

96
vps/vim/services_inventory.md
View file

@ -1,96 +0,0 @@
# Inventário de Serviços Vim
> Última atualização: 2026-02-14
## Visão Geral
Este documento apresenta o inventário completo de serviços hospedados no servidor Vim (38.19.201.52), utilizando a plataforma Dokku como camada de gerenciamento de aplicações baseadas em contêineres.
## Tabela de Aplicações
| Aplicação | Domínio | Porta | Proxy | Banco de Dados | SSL | Status |
|-----------|---------|:-----:|:-----:|----------------|:---:|:------:|
| **gohorse-backend** | dokku.rede5.com.br | 8521 | Desabilitado | PostgreSQL externo (Absam) | - | Rodando |
| **gohorse-frontend** | dokku.rede5.com.br | 3000 | Nginx | - | - | Rodando |
| **gohorse-backoffice** | gohorse-backoffice.dokku.rede5.com.br | 3001 | Nginx | postgres-main | - | Rodando |
| **gohorse-seeder** | gohorse-seeder.dokku.rede5.com.br | 3001 | Nginx | postgres-main | - | Rodando |
| **gohorsejobs** | gohorsejobs.dokku.rede5.com.br | 8521 | Nginx | postgres-main | - | Rodando |
| **sextando** | api-dev.sextando.com.br | 8080 | Nginx | postgres-main | HTTPS | Rodando |
| **sextando-frontend** | dev.sextando.com.br | 3000 | Nginx | - | HTTPS | Rodando |
| **agno-orquestrador** | agno.rede5.com.br | 5000 | Nginx | agno-db | HTTPS | Rodando |
### Notas sobre Aplicações
- **gohorse-backend**: Proxy Dokku desabilitado, Docker expõe porta 8521 diretamente. Usa banco PostgreSQL externo (Absam Cloud). JWT_SECRET configurado.
- **gohorsejobs**: Porta 8521 compartilhada com gohorse-backend (containers diferentes).
- **gohorse-frontend**: Possui container docker-compose dev rodando em paralelo ao Dokku.
## Tabela de Bancos de Dados
| Serviço | Versao | Apps Vinculados | Porta | Volume |
|---------|:------:|-----------------|:-----:|--------|
| **postgres-main** | 17 | gohorsejobs, sextando, gohorse-backoffice, gohorse-seeder | 5432 | /var/lib/dokku/services/postgres/postgres-main/data |
| **agno-db** | 18.1 | agno-orquestrador | 5432 | /var/lib/dokku/services/postgres/agno-db/data |
**Nota**: gohorse-backend usa banco PostgreSQL externo (Absam Cloud), nao o postgres-main local.
## Containers Docker Ativos
| Container | Imagem | Porta | Notas |
|-----------|--------|:-----:|-------|
| gohorse-backend.web.1 | dokku/gohorse-backend:latest | 8521/tcp | API Go, deploy 2026-02-14 |
| gohorse-frontend.web.1 | 27aa73f3586b | 3000/tcp | Frontend Next.js |
| gohorse-backoffice.web.1 | dokku/gohorse-backoffice:latest | 3001/tcp | Backoffice NestJS |
| gohorse-seeder.web.1 | dokku/gohorse-seeder:latest | 3001/tcp | Seeder (healthy) |
| gohorsejobs.web.1 | dokku/gohorsejobs:latest | 8521/tcp | Jobs API Go |
| sextando.web.1 | dokku/sextando:latest | 8080/tcp | API Sextando |
| sextando-frontend.web.1 | b208b5d37fc5 | 3000/tcp | Frontend Sextando |
| agno-orquestrador.web.1 | dokku/agno-orquestrador:latest | 5000/tcp | Streamlit + DeepSeek |
| gohorse-frontend-dev | node:20-alpine | 3000 | Docker-compose dev |
| dokku.postgres.postgres-main | postgres:17 | 5432/tcp | Banco principal |
| dokku.postgres.agno-db | postgres:18.1 | 5432/tcp | Banco Agno |
## Repositorios Git
| App | Tipo | Remote | URL |
|-----|------|--------|-----|
| gohorse-frontend | Forgejo | origin | pipe.gohorsejobs.com/bohessefm/gohorsejobs.git |
| gohorse-frontend | Dokku | dokku | dokku@localhost:gohorse-frontend |
| gohorse-backend | Dokku | dokku | dokku@localhost:gohorse-backend |
| agno-orquestrador | GitHub | origin | github.com/rede5/agno-orquestrador |
## Dominios e SSL
| Dominio | App | SSL |
|---------|-----|:---:|
| dokku.rede5.com.br | gohorse-backend, gohorse-frontend | HTTP |
| gohorse-backoffice.dokku.rede5.com.br | gohorse-backoffice | HTTP |
| gohorse-seeder.dokku.rede5.com.br | gohorse-seeder | HTTP |
| gohorsejobs.dokku.rede5.com.br | gohorsejobs | HTTP |
| api-dev.sextando.com.br | sextando | Let's Encrypt |
| dev.sextando.com.br | sextando-frontend | Let's Encrypt |
| agno.rede5.com.br | agno-orquestrador | Let's Encrypt |
## Portas do Sistema
| Porta | Servico |
|:-----:|---------|
| 22 | SSH |
| 80 | Nginx (redirect para 443) |
| 443 | Nginx (HTTPS) |
| 8521 | gohorse-backend (Docker direto) |
## Services Systemd
| Servico | Status |
|---------|:------:|
| docker.service | active |
| dokku-event-listener.service | active |
| nginx.service | active |
## Issues Conhecidas
1. **Containers orfaos**: Deploys antigos deixam containers stopped. Limpar com docker container prune.
2. **Migration duplicates**: Backend tinha migrations com prefixos duplicados (013-019). Corrigido em 2026-02-14 renumerando para 037-043.
3. **Migration runner PG transaction bug**: O runner de migrations nao tratava transacoes PG abortadas corretamente quando tabelas ja existiam. Corrigido em 2026-02-14.
4. **SSL faltando**: Dominios dokku.rede5.com.br ainda sem HTTPS.