Roadmap CPPS — eixo temporal
📌 Antes de tudo — leia Contexto institucional. Toda decisão deste roadmap é ancorada na missão CPPS + finalidade do Lab Multiusuário IPPRI + compromissos FAPESP. Decisão que não conecta com isso é otimização local.
Foco específico desta seção
O roadmap é o eixo temporal da documentação. Diferente das outras dimensões:
| Dimensão | Foco | Roadmap se diferencia porque |
|---|---|---|
| Camadas | Arquitetura técnica | Roadmap não documenta tecnologia — diz quando ela entra |
| Transversais | Requisitos horizontais | Roadmap não define política — diz em que sequência implementar |
| Frentes estratégicas | Entregas concretas | Roadmap não descreve o quê entregar — diz quando entregar |
| Operações | Manutenção rotineira | Roadmap olha futuro, operações olha agora |
O roadmap responde: em que sequência tudo evolui? Inclui caminho crítico (próximos PRs), 10 fases ordenadas por dependência, 9 ADRs vigentes, e decisões deferidas com critério de revisão.
Tracking tático (issues, kanban): colabhd/projects/1.
Cada item declara seu estado real:
- ✅ Validado em produção
- 📦 Declarado em IaC (Pulumi/Ansible) mas não validado/aplicado
- 🚧 Em andamento
- ❌ Desejado (não iniciado)
- 🔮 Futuro (fora do MVP)
- 🚫 Deferido (decisão explícita de não fazer agora)
Decisões arquiteturais consolidadas
| Tópico | Decisão | ADR |
|---|---|---|
| CNI padrão | Cilium em VM (suportado upstream) | ADR-002 |
| CNI exceção Tier 3 | flannel default em LXC privileged (apenas hosts sem iGPU) | ADR-002 |
| GPU placement Tier 3 | LXC com display físico via GT 710 PCIe x1 nativo | ADR-005 |
| Cluster GPU | Separado do principal por site (isolamento blast radius) | ADR-005, ADR-009 |
| Assimetria GPU SP/Franca | SP em LXC+flannel (Tier 3); Franca em VM+Cilium (Tier 2A) | Tiers de hardware |
| GitOps | 2 ArgoCDs independentes (1 por site) | ADR-001 |
| Multi-cluster federation | Cilium ClusterMesh + ArgoCD ApplicationSet (Karmada deferido) | ADR-004 |
| Storage primário | LINSTOR + DRBD (Ceph deferido) | ADR-003 |
| Secrets management MVP | SOPS + age (ESO + Vault no futuro) | ADR-006 |
| Failover DNS | Cloudflare Tunnel pra hostnames elegíveis | ADR-008 |
| Security stack | VyOS rules + Cloudflare proxy + fail2ban (CrowdSec/Wazuh deferidos) | ADR-007 |
Stack consolidada
┌─ Capacidades transversais (atravessam todas as camadas) ───────────────┐│ ◆ Secrets: SOPS+age ◆ CI/CD IaC: GitHub Actions ││ ◆ IAM: Authentik+LDAP ◆ Supply chain: Harbor+Trivy (futuro) ││ ◆ Certs: cert-manager+CF ◆ Observability: OTel+OpenObserve │└─────────────────────────────────────────────────────────────────────────┘ ▼┌─ Camadas verticais ─────────────────────────────────────────────────────┐│ 11 │ Workloads (apps, GPU/HPC, datalake) ││ 10 │ Self-service / IDP — Backstage opcional (deferido) ││ 9 │ Multi-cluster — Cilium ClusterMesh + ArgoCD ApplicationSet ││ 8 │ GitOps — ArgoCD por site (+ Argo Rollouts futuro) ││ 7 │ Service mesh + observabilidade — Cilium mesh + Hubble ││ 6 │ K8s networking — Cilium CNI (em VMs) + flannel (Tier 3 LXC) ││ 5 │ K8s runtime — K3s ││ 4 │ Ingress — Traefik por site + cert-manager + Cloudflare DNS ││ 3 │ Edge networking — VyOS + UnespNet + WireGuard cross-site ││ 2 │ Backup — PBS por site + sync cross-site (+ Velero futuro) ││ 1 │ Storage — LINSTOR + DRBD intra-site ││ 0 │ Virtualização — Proxmox + Pulumi (IaC) + Ansible (config) │└─────────────────────────────────────────────────────────────────────────┘Caminho crítico — próximos PRs
A ordem dos próximos commits/PRs. Itens marcados ⚡ são MVP de plataforma — bloqueiam todo o resto.
| # | PR | Bloco | Custo | Pré-req |
|---|---|---|---|---|
| 1 ⚡ | Secrets management (SOPS + age) | Transversal | ~1 sem | — |
| 2 ⚡ | cert-manager + Cloudflare DNS-01 Issuer | Transversal + Camada 4 | ~1 sem | PR 1 |
| 3 ⚡ | CI/CD de IaC (pulumi preview, ansible --check em PR) | Transversal | ~1 sem | PR 1 |
| 4 | Corrigir linstor_interface vazio em pve-ippri-34 | Camada 1 | ~1 dia | — |
| 5 | GT 710 PCIe x1 nativo em hosts Tier 3 (pve-ippri-31, 33) | Hardware | ~R$700-800 + 1 dia | — |
| 6 | PBS Franca + PBS SP (paralelo) | Camada 2 | ~2 sem | PR 1, 3 |
| 7 | PBS cross-site sync (pull bidirecional) | Camada 2 | ~1 sem | PR 6 |
| 8 | Renumeração Franca (refactor inventory + Pulumi + VyOS) | Camada 3 | ~2 sem | PR 1, 3 |
| 9 | WireGuard SP↔Franca via VyOS | Camada 3 | ~3 dias | PR 8 |
| 10 | K3s SP “principal” greenfield em VM com Cilium | Camadas 5-7 | ~2 sem | PR 1-3, 8 |
| 11 | ArgoCD SP em VM (paralelo a 10) | Camada 8 | ~1 sem | PR 1-3 |
| 12 | LINSTOR place_count: 3 no SP SSD (após PR 4) | Camada 1 | ~3 dias | PR 4 |
| 13 | POC Cloudflare Tunnel em argocd.colabh.org | Camada 4 | ~3 dias | PR 11 |
Total estimado MVP (PRs 1-13): ~12-16 semanas, custo de hardware ~R$700-800 (GT 710).
Estado por fase
Fase 0 — Plataforma operacional MVP (capacidades transversais) 🔥 prioridade
Objetivo: secrets, certs e CI/CD funcionando antes de qualquer expansão. Sem isso, mudança em prod é roleta russa e auditoria FAPESP fica frágil.
| Item | Estado | Notas |
|---|---|---|
| Secrets management (SOPS + age) | ❌ | ADR-006 — escolher e implementar |
| cert-manager + Cloudflare DNS-01 Issuer | ❌ | DNS-01, rotação de token via SOPS |
| CI/CD de IaC | ❌ | GitHub Actions: pulumi preview, ansible-lint, ansible --check em PR |
Branch protection em main | ❌ | 1+ revisor pra mudanças, sem push direto |
| Inventário de domínios e secrets | ❌ | Doc em /operacoes/dominios/ (já existe parcial) |
| Runbook de rollback por componente | ❌ | Doc por camada |
Definition of done: PR tocando Pulumi/Ansible/manifests roda preview/check automático e exige aprovação antes de merge. Secret novo entra em git criptografado, descriptografado em runtime.
Fase 1 — Renumeração unificada Franca
Objetivo: ranges IP estáveis em ambos os sites antes de configurar Cilium ClusterMesh, ArgoCD cross-site, Cloudflare DNS.
| Item | Estado | Notas |
|---|---|---|
SP — 192.168.10.0/23 LAN, 10.10.20.0/24 LINSTOR, 192.168.12.0/24 LAB | ✅ | PR #8 mergeado |
| Franca — definir range | ❌ | Decisão pendente — sugestão: 192.168.20.0/23, LINSTOR 10.10.30.0/24 |
| Franca — renumerar (inventory + Pulumi + VyOS) | ❌ | Pré-req: range definido |
| WireGuard SP↔Franca via VyOS | ❌ | Pré-req: ranges definidos em ambos |
Definition of done: ambos os sites com ranges não-conflitantes, conectividade SP↔Franca via WireGuard documentada e testada.
Fase 2 — Storage e backup hardening (camadas 1-2)
Objetivo: infra de dados sólida — perda de hardware não vira perda de serviço, perda lógica é recuperável.
| Item | Estado | Notas |
|---|---|---|
| Cluster Proxmox Franca/SP | ✅ | Em produção |
| Upgrade PVE 9.x | 🚧 | Alguns nodes feitos |
| LINSTOR Franca + SP SSD | ✅ | Em produção |
LINSTOR SP NVMe pve-ippri-34 interface vazia | ❌ | Bloqueador: corrigir antes de escalar |
LINSTOR place_count: 3 no SP SSD | ❌ | Após correção do pve-ippri-34 |
| DRBD auto-evict tuning + quorum policy | ❌ | Decisão recente, aplicar |
| Witness/tie-breaker em terceiro site | ❌ | Cloud VM ou outro campus pra anti-split-brain |
| PBS Franca | ❌ | VM dedicada |
| PBS SP | ❌ | VM dedicada |
| PBS cross-site sync | ❌ | Pull bidirecional via WireGuard |
| Restore real testado | ❌ | Validar VM e arquivo, documentar tempo |
Definition of done:
- Restore real de VM completa em < 30 min documentado
- Restore granular de arquivo testado
- Falha intencional de 1 node não interrompe workloads protegidos
- LINSTOR
pve-ippri-34operacional na rede dedicada
Fase 3 — Hardware Tier 3 + edge networking (camadas 3-4)
Objetivo: resolver display físico nos hosts Tier 3 (pré-req pra Cilium em VM em todo lugar) + ingress consolidado com TLS automatizado.
| Item | Estado | Notas |
|---|---|---|
GT 710 PCIe x1 em pve-ippri-31 | ❌ | ASUS GT710-2-SL-CSM ou GT710-SL-1GD5-BRK (~R$350) — libera A5000 pra passthrough |
GT 710 PCIe x1 em pve-ippri-33 | ❌ | Mesmo modelo (~R$350) — libera A5000 pra passthrough |
| VyOS Franca + SP em produção | ✅ | |
| Backup VyOS 3-camadas | ✅ | Runbook |
| WireGuard SP↔Franca | ❌ | Após Fase 1 |
| IP público fixo via UnespNet | ❌ | Decisão: usar pra quê? |
| VRRP HA pra VyOS | ❌ | Eliminar SPOF |
| Traefik SP em IP único | ✅ | 192.168.10.6 |
| Traefik Franca consolidado | 🚧 | Status real? |
| cert-manager + Issuer Cloudflare | ❌ | Fase 0 pré-req |
| Failover DNS via Cloudflare Tunnel | ❌ | Decidido em ADR-008: 2 túneis (1/site) por hostname elegível |
| Inventário de hostnames | ✅ | Documentado em /operacoes/dominios/ |
POC Tunnel: argocd.colabh.org | ❌ | Único hostname elegível pra failover real hoje |
| DNS secundário fora de Cloudflare | ❌ | Plano B se Cloudflare cair globalmente |
| Runbook “Cloudflare offline” | ❌ | Fallback manual com A records diretos |
Definition of done: apps acessíveis em ambos os sites com TLS válido emitido automaticamente; hosts Tier 3 com display físico funcionando + A5000 livres pra passthrough.
Fase 4 — Eliminar SPOFs declarados
Objetivo: consertar SPOFs que aparecem hoje no Pulumi e impedem qualquer DoD de “zero downtime”.
| Item | Estado | Notas |
|---|---|---|
traefik-sp ha: True declarado mas Pulumi não cria HA | 📦 | Implementar HA real ou remover flag |
vyos-sp e traefik-sp no mesmo pve-ippri-11 | 📦 | Distribuir em hosts diferentes |
| ArgoCD Franca single-replica | 🚧 | Avaliar HA |
| Authentik (futuro) — single-instance é SPOF | ❌ | Pensar HA antes de subir |
Definition of done: nenhum serviço de plataforma (VyOS, Traefik, ArgoCD, LINSTOR controller) depende de um único host físico.
Fase 5 — K3s + Cilium em VM (camadas 5-6)
Objetivo: K3s SP “principal” greenfield em VM com Cilium suportado upstream.
Estratégia: greenfield em hosts Tier 1 (pve-ippri-11/12) primeiro. Workers Tier 2A/2B/3 entram depois.
| Item | Estado | Notas |
|---|---|---|
K3s SP em VM com --flannel-backend=none | ❌ | Em hosts Tier 1 (pve-ippri-11/12) — Greenfield |
| Cilium 1.16+ em VM | ❌ | Caminho documentado upstream, sem POC complexo |
| Hubble (observabilidade L7) | ❌ | Integrado com OpenObserve |
| Validação SP (app de teste) | ❌ | Tutor staging |
| Workers Tier 2A com NVIDIA passthrough | ❌ | pve-ippri-34 — após GT 710 instalada |
| Workers Tier 2B (sem GPU workload) | ❌ | pve-ippri-32 em VM |
| Migrar Franca pra Cilium em VM | ❌ | Em janela após validação SP |
| Cilium ClusterMesh SP↔Franca (clusters principais) | ❌ | Cross-cluster service discovery |
gpu-sp-01 mantido como K3s standalone em LXC | ✅ | ADR-005 — Tier 3 sem Cilium |
gpu-sp-02 em pve-ippri-33 (futuro) | ❌ | Mesma arquitetura LXC + flannel se demanda crescer |
| Cluster GPU Franca em VM (Tier 2A) | 🔮 | Hosts labri-31/32/33 — aqui Cilium + GPU passthrough funcionam juntos |
Definition of done: service em SP resolve service em Franca via DNS interno; Hubble mostra fluxo cross-site; cluster GPU SP em LXC operacional separado, gerenciado por ArgoCD multi-cluster.
Fase 6 — GitOps maturado (camada 8)
Objetivo: 2 ArgoCDs independentes com repo structure clara. Pode rodar em paralelo às Fases 3-5.
| Item | Estado | Notas |
|---|---|---|
| ArgoCD Franca | ✅ | Apps em produção |
| ArgoCD SP em VM | ❌ | Não depende de Cilium — pode subir antes/em paralelo |
Repo structure apps/franca/, apps/sp/, apps/multi/ | ❌ | Refactor |
| ApplicationSet pra apps multi-site | ❌ | Substitui Karmada pra casos simples |
ArgoCD multi-cluster: registrar gpu-sp-01 | ❌ | Cluster GPU SP gerenciado pelo ArgoCD principal |
Definition of done: push em apps/multi/<app> deploya nos 2 sites simultaneamente; cada ArgoCD reconcilia local independentemente; cluster GPU registrado e gerenciável via ArgoCD.
Fase 7 — IAM + Observabilidade unificadas (transversais)
Objetivo: SSO único, audit trail FAPESP-ready, alertas funcionando.
| Item | Estado | Notas |
|---|---|---|
| OpenObserve setup | 🚧 | Validar uso real |
| OTel Collector universal (Proxmox + K3s) | ❌ | Via Ansible |
| Métricas LINSTOR/DRBD/PBS | ❌ | Exporters dedicados |
| Hubble integrado (Cilium) | ❌ | Após Fase 5 |
| Authentik (IdP) HA | ❌ | OIDC/SAML/OAuth2 — single-tenant institucional NÃO é multi-grupo cooperativo do lab IPPRI |
| Authentik LDAP Outpost (SSH/sudo) | ❌ | SSSD nos servidores |
| K8s + Proxmox RBAC com bindings Authentik | ❌ | Granularidade por grupo de pesquisa |
| OpenCost com attribution por grupo | ❌ | Pré-req pra prestação de contas FAPESP |
| Alert routing + 5 alertas básicos | ❌ | Node down, LINSTOR degraded, DRBD desync, ArgoCD out-of-sync, cert expirando |
| Blackbox probes externos | ❌ | Synthetic checks |
| SLOs definidos por serviço crítico | ❌ |
Definition of done: falha real produz alerta antes do usuário reclamar; admin diagnostica incidente sem SSH em nó; FAPESP recebe relatório de uso por grupo de pesquisa.
Fase 8 — Multi-cluster federation (opcional — avaliar pós-Fase 5-7)
Decisão pendente: Karmada vale o custo? Recomendação: começar com Cilium ClusterMesh + ApplicationSet (ADR-004). Adicionar Karmada só se aparecer caso real.
| Item | Estado | Notas |
|---|---|---|
| Cilium ClusterMesh ativo | ❌ | Fase 5 |
| ApplicationSet pra apps multi-site | ❌ | Fase 6 |
| MultiKueue pra batch GPU cross-site | ❌ | Pré-req pra Plataforma GPU Franca completa |
| Liqo (alternativa Karmada leve) | 🟡 | Avaliar se rebalanceamento dinâmico virar requisito |
| Karmada | 🚫 Deferido | Critério: 5+ clusters ou scheduling dinâmico (ADR-004) |
Fase 9 — Plataforma GPU + workloads acadêmicos (camadas 9-11)
Objetivo: plataforma GPU em produção (interativa + batch) + apps acadêmicos centrais robustos.
| Item | Estado | Notas |
|---|---|---|
gpu-sp-01 (LXC + K3s + A5000) | ✅ | Em produção, sem Cilium |
| HAMi ou NVIDIA Device Plugin time-slicing | ❌ | Após cluster GPU Franca em VM |
| TensorZero (model proxy) | ❌ | |
| vLLM / SGLang serving | ❌ | |
| Volcano ou Kueue (batch single-cluster) | ❌ | |
| MultiKueue cross-site | ❌ | Distribui jobs batch entre SP e Franca |
| Tutor / Open edX | ✅ | Em produção (Franca), docs |
| OpenObserve | 🚧 | Setup feito |
| OnlyOffice | 🚧 | Workstations Ryzen |
| OCR em lote (Docling/Marker) | ❌ | Acervos, teses, microfilmes |
| Datalake (MinIO + Iceberg) | ❌ | Plano em Plataforma de Dados |
| GraphRAG sobre corpus | ❌ |
Definition of done: pesquisador submete job (interativo via vLLM ou batch via Kueue) e vê resultado; FAPESP recebe relatório de uso GPU por projeto.
Fase 10 — Expansão híbrida 🔮
Objetivo: cloud bursting + integração HPC + novas unidades do Colaboratório.
| Item | Estado | Notas |
|---|---|---|
| Cluster K8s AWS/Azure managed | 🔮 | EKS/AKS |
| VPN cross-cloud | 🔮 | WireGuard ou cloud-native |
| ClusterMesh expandido pra cloud | 🔮 | Bursting sob demanda |
| Integração Grid Unesp (SLURM API) | 🔮 | Jobs batch externos |
| Novas unidades do Colaboratório de Humanidades Digitais | 🔮 | Replicar stack 0-7 |
| IDP completo (Backstage + Crossplane) | 🔮 | Quando self-service estruturado virar demanda |
Tiers de hardware — resumo
Detalhe completo em /operacoes/tiers-de-hardware/.
| Tier | Hosts | CNI | Estado |
|---|---|---|---|
| Tier 1 (server rack) | pve-ippri-11/12 | Cilium em VM | Pronto pra Fase 5 |
| Tier 2A (iGPU + NVIDIA workload) | pve-ippri-34, pve-labri-31/32/33 | Cilium em VM + passthrough | Pronto pra Fase 5/9 |
| Tier 2B (GPU básica display-only) | pve-ippri-32, pve-labri-21/22 | Cilium em VM (sem GPU workload) | Pronto pra Fase 5 |
| Tier 3 (NVIDIA disputada display+workload) | pve-ippri-31, 33 | flannel em LXC + GT 710 pra display | Pré-req: GT 710 (Fase 3 PR 5) |
Decisões deferidas (ADRs)
Componentes “modernos e elegantes” que não entram no MVP mas valem reavaliar com critérios objetivos:
| Componente | Critério de ativação | Alternativa MVP |
|---|---|---|
| Karmada | 5+ clusters ou scheduling dinâmico real | Cilium ClusterMesh + ApplicationSet |
| Crossplane | Demanda real de self-service multi-cloud | Pulumi/Ansible + ArgoCD direto |
| Backstage | 5+ devs querendo self-service estruturado | ArgoCD UI + repo organizado |
| KubeVela | Adoção formal de OAM platform engineering | Helm + Kustomize + ApplicationSet |
| KubeVirt | Self-service de VMs efêmeras | Pulumi via PR (VM nativa Proxmox) |
| Octelium / Teleport | Audit trail compliance formal além de Hubble | SSH keys via Authentik LDAP |
| Headscale | >5 nodes externos ou pesquisadores remotos | WireGuard direto via VyOS |
| CrowdSec | >100 IPs/mês atacando ou serviço público alto valor | VyOS rules + Cloudflare proxy + fail2ban |
| Wazuh | Compliance acadêmico formal exigir audit granular | OpenObserve + audit logs K8s |
| Suricata IDS/IPS | Ataque sofisticado detectado | Defesa em profundidade básica |
Cada um deve virar ADR formal antes de adoção.
Hardware refresh — guia futuro
Quando hardware Tier 3 for substituído (próximas compras):
| ✅ Preferir | ❌ Evitar |
|---|---|
| Ryzen 7000+ X3D (iGPU RDNA 2) | Ryzen 3000/5000 sem G (sem iGPU + workstation chassi) |
| Ryzen G-series (5600G, 5700G, 7700G) | Hardware sem iGPU como workstation |
| Server rack class (Tier 1 nato, sem display local) | Workstation com NVIDIA disputada display+workload |
| Mobo com IPMI/BMC integrado (Asrock Rack, Supermicro) | — |
Quando Tier 3 for substituído por Tier 2A ou Tier 1, padronização Cilium em VM completa e GT 710 vira hardware obsoleto.
Documentos detalhados
- Contexto institucional — missão CPPS, Lab Multiusuário IPPRI, Colaboratório de Humanidades Digitais, hierarquia de prioridades
- Arquitetura — modelo de camadas — papel de cada componente
- Tiers de hardware — categorização por host com arquitetura recomendada
- Inventário de hostnames — 26+ hostnames com tier de criticidade
- Plataforma GPU — arquitetura GPU completa
- Plataforma de Dados — data lake + CAQDAS + GraphRAG
- Integração SP-Franca — malha unificada multi-site
- ADRs em
/roadmap/adrs/