Gov Hub BR - Transformando Dados em Valor para Gestão Pública

O Gov Hub BR é uma iniciativa para enfrentar os desafios da fragmentação, redundância e inconsistências nos sistemas estruturantes do governo federal. O projeto busca transformar dados públicos em ativos estratégicos, promovendo eficiência administrativa, transparência e melhor tomada de decisão. A partir da integração de dados, gestores públicos terão acesso a informações qualificadas para subsidiar decisões mais assertivas, reduzir custos operacionais e otimizar processos internos.

Potencializamos informações de sistemas como TransfereGov, Siape, Siafi, ComprasGov e Siorg para gerar diagnósticos estratégicos, indicadores confiáveis e decisões baseadas em evidências.

• Transparência pública e cultura de dados abertos
• Indicadores confiáveis para acompanhamento e monitoramento
• Decisões baseadas em evidências e diagnósticos estratégicos
• Exploração de inteligência artificial para gerar insights
• Gestão orientada a dados em todos os níveis

Fluxo/Arquitetura de Dados

A arquitetura do Gov Hub BR é baseada na Arquitetura Medallion, em um fluxo de dados que permite a coleta, transformação e visualização de dados.

Para mais informações sobre o projeto, veja o nosso e-book. E temos também alguns slides falando do projeto e como ele pode ajudar a transformar a gestão pública.

Slides

Apoio

Esse trabalho é mantido pelo Lab Livre e apoiado pelo IPEA/Dides.

Contato

Para dúvidas, sugestões ou para contribuir com o projeto, entre em contato conosco: lablivreunb@gmail.com

Infra — Gov-Hub (GitOps)

Infraestrutura de dados gerenciada via Argo CD (GitOps).
Este monorepo contém os manifests/helm charts e os overlays por ambiente para:

• Argo CD (controle GitOps)
• App-of-Apps (gera os Applications filhos)
• Airflow (ETL/ELT)
• MinIO (objeto storage)
• Postgres (metastore/analytics)
• Superset (BI)
• JupyterHub (notebooks)

Importante: não publicamos URLs/portas no README raiz. Endpoints e credenciais são tratados por ambiente e documentados internamente, quando necessário, nos respectivos READMEs.

---

Sumário

• Infra — Gov-Hub (GitOps)
  • Sumário
  • Estrutura do repositório
  • Conceitos
    • Overlays por ambiente
    • App-of-apps
    • Sync waves
  • Pré-requisitos
  • Bootstrap / Deploy
  • Segurança: secrets & acessos
  • Padrões de contribuição
  • Referências por componente

---

Estrutura do repositório

.
├── airflow/        # README e manifests do Airflow
├── app-of-apps/    # Chart que gera os Applications filhos
├── argocd/         # Instalação do Argo CD + entrypoints (preprod/prod)
├── assets/         # imagens/diagramas
├── jupyterhub/     # README e manifests do JupyterHub
├── minio/          # README e manifests do MinIO (+ overlay prod)
├── postgres/       # README e manifests do Postgres
├── superset/       # README e manifests do Superset
└── README.md       # (este arquivo)

Cada pasta possui um README próprio com detalhes de setup, pré-requisitos específicos e exemplos.

---

Conceitos

Overlays por ambiente

• Arquivos values.*.yaml sobrescrevem apenas o que muda por ambiente (ex.: values.prod.yaml, values.preprod.yaml).
• O merge é por chave (deep-merge). O que não está no overlay é herdado do base.

App-of-apps

• Um Application raiz gera/aplica os Applications filhos (Airflow, MinIO, Postgres, etc.).
• Cada filho pode usar Helm, Kustomize ou plugin (kustomized-helm).
• A ordem de bootstrap é definida por sync waves.

Sync waves

• Usamos a anotação argocd.argoproj.io/sync-wave: "<N>" para ordenar a aplicação.

• Regra geral:

  • Infra base/dependências: waves negativas (ex.: DB/obj storage)
  • Orquestrador: 0 (ex.: Airflow)
  • Visualização/serviços finais: 1+ (ex.: Superset/JupyterHub)

---

Pré-requisitos

• Acesso ao cluster Kubernetes (kubeconfig).
• kubectl, helm e (opcional) argocd CLI instalados.
• Acesso à VPN quando exigido pelo ambiente.
• Secrets exigidos por cada app criados antes do deploy (ver README de cada componente).

---

Bootstrap / Deploy

O fluxo padrão é declarativo via Argo CD:

1. Argo CD: instale/sincronize conforme argocd/README.md (usa values.yaml + overlay do ambiente).
2. App-of-apps: o application.<env>.yaml cria o Application raiz; ao sincronizar, ele gera/aplica os filhos conforme app-of-apps/values.<env>.yaml.
3. Waves garantem a ordem (ex.: Postgres/MinIO → Airflow → Superset/JupyterHub).

Para testes pontuais, cada componente expõe um comando de renderização/aplicação manual (kubectl kustomize ... | kubectl apply -f - -n <ns>). Em produção, evite aplicar manualmente para não criar drift.

---

Segurança: secrets & acessos

• Nunca commitar credenciais no repositório.
• Criar secrets via kubectl -n <ns> apply -f - <<'EOF' ... EOF ou usar gerenciadores (Sealed/External Secrets, se adotados).
• Certificados e chaves (ex.: SIAFI/SIAPE) são críticos. Os nomes das secrets e chaves esperadas constam nos READMEs de Airflow e JupyterHub.
• Acesso a painéis/DBs é tratado por ambiente; procure a equipe de infra para endpoints e credenciais.

---

Padrões de contribuição

• Branches: prefira prefixos feat/, fix/, refactor/, docs/.

• Commits: Conventional Commits (ex.: feat(argocd): ..., docs(airflow): ...).

• MR/PR: descreva o porquê e liste mudanças relevantes (paths/values alterados).

• Rebase da branch com main antes de abrir o MR:

  git fetch origin
  git rebase origin/main
  git push --force-with-lease

---

Referências por componente

• Argo CD: argocd/README.md
• App-of-apps: app-of-apps/README.md
• Airflow: airflow/README.md
• MinIO: minio/README.md
• Postgres: postgres/README.md
• Superset: superset/README.md
• JupyterHub: jupyterhub/README.md