Instalação completa¶

Como executar uma instalação completa em uma infraestrutura própria?¶

Este guia é voltado a um administrador de infraestrutura responsável por colocar o DSP em produção, migrando dados reais de uma organização (o "adotante").

Requisitos de infraestrutura¶

Fluxo de instalação¶

flowchart LR
  r["Passo 1<br/>Organizar os repositórios"] --> e["Passo 2<br/>Entrar no dsp-core"]
  e --> a["Passo 3<br/>./config.sh (wizard)"]
  a --> b["gera adopter-config.yaml<br/>e arquivos operacionais"]
  b --> c["Passo 4<br/>./setup.sh (opção 2)"]
  c --> d["Passo 5<br/>./start.sh — sobe a stack"]

Passo 1 — Organizar os repositórios¶

O DSP é dividido em repositórios irmãos no GitHub. Recomendamos criar uma pasta dsp e clonar tudo no mesmo nível.

Os scripts procuram cada módulo nesta ordem: primeiro a pasta curta (backend, frontend, job-data-migration, job-geo-file-generation) e, se o código não estiver lá, a pasta com o nome do repositório (dsp-backend, dsp-frontend, dsp-job-data-migration, dsp-job-geo-file-generation). Se as duas faltarem, o download automático cria a pasta com o nome do repositório. A publicação automática no CI continua usando a pasta curta.

Opção A — fluxo mais simples (recomendado)¶

Crie a pasta, clone só o core e entre nele. Os scripts ./config.sh, ./setup.sh e ./start.sh detectam repositórios irmãos ausentes e oferecem cloná-los automaticamente ao lado do core:

mkdir dsp && cd dsp
git clone https://github.com/Rural-Environmental-Registry/dsp-core.git
cd dsp-core

Depois que você aceitar o clone automático nos scripts, a árvore típica fica assim:

dsp/
├── dsp-core/          ← você trabalha aqui (config.sh, setup.sh, start.sh)
├── dsp-backend/
├── dsp-frontend/
├── dsp-job-data-migration/
└── dsp-job-geo-file-generation/

Opção B — clone manual¶

Clone todos os repositórios de aplicação como pastas irmãs dentro de dsp:

mkdir dsp && cd dsp
git clone https://github.com/Rural-Environmental-Registry/dsp-core.git
git clone https://github.com/Rural-Environmental-Registry/dsp-backend.git
git clone https://github.com/Rural-Environmental-Registry/dsp-frontend.git
git clone https://github.com/Rural-Environmental-Registry/dsp-job-data-migration.git
git clone https://github.com/Rural-Environmental-Registry/dsp-job-geo-file-generation.git

Resultado:

dsp/
├── dsp-core/
├── dsp-backend/
├── dsp-frontend/
├── dsp-job-data-migration/
└── dsp-job-geo-file-generation/

Passo 2 — Entrar no core¶

Se você ainda não estiver dentro do core:

cd dsp/dsp-core

Não é necessário criar nem copiar o .env manualmente. O arquivo é gerado automaticamente na primeira execução de ./config.sh ou ./setup.sh, a partir de .env.example, quando ainda não existir.

Passo 3 — ./config.sh¶

A pessoa que executa o script será guiada por perguntas no terminal: em cada estágio o wizard explica o campo, onde o valor é usado e mostra o padrão ou o valor já salvo (Enter mantém o que está entre colchetes). Assim é possível configurar tudo o que o adotante precisa — origem dos dados, ETL, textos, mapa, KPIs e personalizar a interface sem editar JSON/YAML à mão.

O fluxo tem 6 etapas guiadas (a última, About, é opcional):

O ./config.sh grava a fonte de verdade do adotante em config/adopter/adopter-config.yaml — este é o arquivo pensado para edição manual ou importação de YAML pronto. Na reaplicação (wizard ou opção 1 — Reaplicar), o ./config.sh gera os arquivos operacionais consumidos pelo backend, GeoServers e jobs. Não edite esses operacionais à mão: eles são sobrescritos a cada ./config.sh.

Sem o wizard: copie um adopter-config.yaml pronto para config/adopter/ (use o .example como referência) ou edite somente esse YAML. O DSP não lê o adotante na runtime — backend, GeoServers e jobs usam os JSON/YAML gerados.

Passo 4 — ./setup.sh¶

No Step 3 — Setup mode, escolha:

• Opção 1 — Demonstração (veja também Começando rápido):
• Carrega dados de exemplo (mapa do Brasil simplificado) nos bancos locais.
• Sobe os bancos, aplica o seed e publica as camadas do mapa nos dois GeoServers.
• Não conecta ao banco da sua organização e não liga os jobs de importação em segundo plano.

• Ao final, indica rodar ./start.sh para abrir o site e a API.

• Opção 2 — Adotante real (dados da organização): exige ./config.sh antes. O script confere se a configuração de importação está pronta e pergunta como os dados da fonte vão mudar ao longo do tempo (texto em inglês no terminal: How will your source data be updated over time?):

Ao final do fluxo real, o setup salva as agendas escolhidas no arquivo .env. Rodar ./setup.sh de novo com opção 2 repete as perguntas, usando o que já estiver salvo como padrão.

• Opção 3 — Stack status / cleanup / exit:
• Lista status dos containers do projeto e URLs conhecidas.
• Opcionalmente remove containers, volumes e imagens deste projeto (confirmação explícita).
• Não executa seed, migração nem sobe backend/frontend.

Passo 5 — ./start.sh¶

Usado depois do ./setup.sh, com bancos, GeoServers e jobs (quando existirem) já rodando. O ./start.sh sobe somente o site, a API e o ponto de entrada HTTP — não importa dados de novo nem republica camadas. Importação e demo ficam no ./setup.sh ou nas agendas salvas no setup.

Ao final, abra no navegador http://localhost:8026/dsp/ (ou a URL que o próprio ./start.sh mostrar se você mudou porta ou endereço no .env).

Detalhamento completo de cada opção e sub-fluxo: dsp-core.

Próximos passos¶