A plataforma iGRP a correr em Docker no teu computador — a pasta do workspace, as quatro stacks, como se ligam, a ordem de arranque e os dois modos de autenticação.
Um workspace criado pelo Studio traz a plataforma iGRP completa descrita em Docker Compose. Não é uma aplicação: é uma plataforma local que aloja vários serviços e os teus projetos em conjunto. Podes geri-la pelo separador Serviços do Studio ou diretamente com docker compose.
As quatro stacks
igrp-compose.yaml — nginx, PostgreSQL, Keycloak, Access Management, Application Center, gateway, Eureka, MinIO, Redis, pgAdmin.
process/ — APIs e UIs de Process Management e Process Studio.
monitoring/ — OpenTelemetry Collector, Prometheus, Loki, Tempo, Grafana, cAdvisor.
projects/<projeto>/ — um compose por projeto, ligado à stack principal.
A pasta do workspace
<workspace>/
|-- .igrpstudio/ # workspace.json, scripts de inicialização, realm do Keycloak
|-- igrp-compose.yaml # stack principal, modo Keycloak
|-- igrp-autentika-compose.yaml # stack principal, modo Autentika
|-- .env # ambiente da stack principal, modo Keycloak
|-- .igrp-autentika.env # ambiente da stack principal, modo Autentika
|-- nginx.conf # reverse proxy central
|-- redis.conf
|-- process/ # stack Process (se escolhida)
|-- monitoring/ # stack Monitoring (se escolhida)
|-- projects/ # os teus projetos
`-- logs/Os env-files têm segredos em texto simples
projects/ está no .gitignore; os env-files da raiz não. Revê-os antes de versionar ou partilhar o workspace.
Como se ligam
Todas as stacks partilham a mesma rede Docker e a infraestrutura da stack principal. Todo o tráfego HTTP entra pelo nginx, em http://<slug>:<porta>:
| Caminho | Destino |
|---|---|
/ | Application Center |
/auth | Keycloak |
/apps/<app> | frontends (os teus e os da stack Process) |
/gateway-api/<serviço> | APIs Spring, pelo gateway |
/pgadmin, /minio, /eureka, /grafana | ferramentas |
As APIs nunca são expostas diretamente: o nginx encaminha /gateway-api/* para o gateway, que resolve o serviço pelo Eureka. Um backend novo ganha rota ao registar-se no Eureka, sem mexer no nginx.conf. Num cluster é igual, mas o gateway descobre os serviços pelo Kubernetes e as entradas são três domínios — ver Cloud › Visão geral.
Sempre pelo hostname do workspace
Acede a tudo por <slug>:<porta> (o DOCKER_IP e a NGINX_HTTP_PORT do .env) — nunca pelo nome ou IP de um contentor. O hostname entra no issuer dos tokens e nos callbacks de login.
A ordem de arranque
Stack principal
Primeiro, sempre. Cria a rede, as bases de dados e regista os clientes OAuth de que tudo o resto depende.
Projetos
Só os que precisares.
Process e Monitoring
Extensões opcionais, por esta ordem.
No Studio, é o botão ▶ de cada grupo em Serviços; pela linha de comandos, os comandos estão na página de cada stack. Para parar, a ordem inversa.
Modos de autenticação
O workspace suporta dois fornecedores de identidade, mutuamente exclusivos. Em ambos, as aplicações autenticam no Access Management local — nunca diretamente no fornecedor:
| Modo | Stack principal | Stack Process |
|---|---|---|
| Keycloak (por defeito) | .env + igrp-compose.yaml | .env_process + igrp-process-compose.yaml |
| Autentika | .igrp-autentika.env + igrp-autentika-compose.yaml | .env_process_autentika + igrp-process-autentika-compose.yaml |
Detalhes em Autenticação.
Regras a preservar
Se adaptares este workspace, mantém o modelo: uma stack principal para a infraestrutura partilhada; stacks opcionais separadas; projetos em projects/ com o seu próprio compose; frontends em /apps/<projeto>; APIs pelo gateway com descoberta no Eureka; valores operacionais em env-files; um par compose/env por modo de autenticação.
Última atualização: