diff --git a/CONNECTIONS.md b/CONNECTIONS.md index 59307bd..02d7beb 100644 --- a/CONNECTIONS.md +++ b/CONNECTIONS.md @@ -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 | `` | | 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="" export CF_AUTH_KEY=$(cat ~/.ssh/cloudflare-token) -export CF_ZONE_ID="5e7e9286849525abf7f30b451b7964ac" +export CF_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/ +git clone https://:$TOKEN@pipe.gohorsejobs.com/ ``` --- @@ -229,8 +220,8 @@ git clone https://yamamoto:$TOKEN@pipe.gohorsejobs.com/ | Propriedade | Valor | |-------------|-------| -| Server | everest.mxrouting.net | -| Username | net5cloud | +| Server | | +| 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: " \ + -H "X-Username: " \ -H "X-API-Key: $API_KEY" # Listar contas de email curl -X GET "https://api.mxroute.com/accounts/" \ - -H "X-Server: everest.mxrouting.net" \ - -H "X-Username: net5cloud" \ + -H "X-Server: " \ + -H "X-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 ``` diff --git a/OBJECT-STORAGE.md b/OBJECT-STORAGE.md index f638a2f..fc1b1e4 100644 --- a/OBJECT-STORAGE.md +++ b/OBJECT-STORAGE.md @@ -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` | --- diff --git a/README.md b/README.md index c58980b..9903b97 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/inventcloud/invista/nexus/OPERATIONS.md b/inventcloud/invista/nexus/OPERATIONS.md index 8796422..00ee13a 100644 --- a/inventcloud/invista/nexus/OPERATIONS.md +++ b/inventcloud/invista/nexus/OPERATIONS.md @@ -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 = (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 diff --git a/vps/redbull/services_inventory.md b/vps/redbull/services_inventory.md index 5c92f20..76be4a8 100644 --- a/vps/redbull/services_inventory.md +++ b/vps/redbull/services_inventory.md @@ -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 diff --git a/vps/vim/README.md b/vps/vim/README.md deleted file mode 100644 index a717703..0000000 --- a/vps/vim/README.md +++ /dev/null @@ -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 diff --git a/vps/vim/architecture.md b/vps/vim/architecture.md deleted file mode 100644 index febe26e..0000000 --- a/vps/vim/architecture.md +++ /dev/null @@ -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
Ports: 80, 443] - end - - subgraph Dokku ["Plataforma Dokku"] - DCore[Dokku Core
Dokku
Docker
Buildpacks] - - subgraph Apps ["Aplicações Hospedadas"] - direction LR - GoHorseBE[GoHorse
Backend] - GoHorseFE[GoHorse
Frontend] - GoHorseBO[GoHorse
Backoffice] - GoHorseSD[GoHorse
Seeder] - GoHorseJobs[GoHorse
Jobs] - Sextando[API
Sextando] - SextandoFE[Frontend
Sextando] - Agno[Agno
Orquestrador] - end - end - - subgraph Databases ["Bancos de Dados"] - PGMain[(PostgreSQL
Main)] - PGAgno[(PostgreSQL
Agno-DB)] - end - - subgraph Cache ["Camada de Cache"] - Redis[(Redis)] - end - - subgraph Storage ["Armazenamento"] - Volumes[Volumes
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. diff --git a/vps/vim/deployment_guide.md b/vps/vim/deployment_guide.md deleted file mode 100644 index 2d81c03..0000000 --- a/vps/vim/deployment_guide.md +++ /dev/null @@ -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. diff --git a/vps/vim/services_inventory.md b/vps/vim/services_inventory.md deleted file mode 100644 index eb288d8..0000000 --- a/vps/vim/services_inventory.md +++ /dev/null @@ -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.