Configuração do OpenMetadata

ChartVersion3.0.1TypeapplicationAppVersion1.12.4

CompatibilidadeKubernetes1.32+OpenShift4.19+Rancher2.10.x+

Suporte a recursosLDAPsuportadoExternal DBsuportadoIngresssuportadoGateway APIsuportado

Esta página cobre a instalação e configuração do OpenMetadata via chart tdp-openmetadata: pré-requisitos, instalação OCI, parâmetros principais, acesso e desinstalação. Autenticação, LDAP e job de datasources são detalhados nas páginas relacionadas. O banco de dados (PostgreSQL) está documentado nesta página.

O que é o OpenMetadata?

O OpenMetadata é uma plataforma de catálogo de dados e governança.

Em termos práticos, é onde você registra todos os ativos de dados da sua organização — tabelas do ClickHouse, tópicos do Kafka, dashboards do Superset, pipelines do Airflow — e obtém uma visão unificada de quem os criou, o que significam, quem os usa e como eles se relacionam.

No TDP Kubernetes, o OpenMetadata resolve a seguinte necessidade: com tantos componentes (Trino, ClickHouse, Kafka, Airflow, Superset), fica difícil saber onde um dado específico está, o que significa, e se ainda é confiável.

O OpenMetadata centraliza a descoberta, a catalogação e a documentação dos ativos de dados.
Isso facilita a descoberta da origem, do contexto e dos responsáveis pelos dados em ambientes com múltiplos motores.
O catálogo não substitui o monitoramento de pipelines ou SLAs, mas organiza metadados e vínculos entre ativos registrados na plataforma.

Para saber mais

Consulte OpenMetadata — Conceitos para uma visão completa da ferramenta, sua arquitetura e funcionamento.

Estrutura de valores (Helm)

Os valores do servidor OpenMetadata ficam sob a chave tdp-openmetadata:. Configurações de serviços externos, automações e exposição externa ficam sob blocos separados no nível raiz:

• tdp-openmetadata: — servidor, imagem, Ingress, banco de dados, backend de busca, RBAC.
• externalServices: — referência ao PostgreSQL externo (hooks e senha admin).
• datasourcesIntegration: — job pós-instalação de registro automático de datasources TDP.
• gatewayApi: — configuração do HTTPRoute e Gateway para exposição via Gateway API.
• TDP-Settings: — seleção do modo de exposição HTTP/HTTPS (Ingress ou Gateway API).
• openshift: — configuração de SCC para ambientes OpenShift.

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: false

tdp-openmetadata:
  openmetadata:
    config:
      database:
        dbScheme: "mysql"

externalServices:
  postgresql:
    enabled: false

Chave de controle de exposição

Este chart usa a chave TDP-Settings.gateway para controlar qual modo de exposição HTTP está ativo. Habilite apenas um: Ingress ou Gateway API.

Componentes implantados

Componente	Descrição
OpenMetadata Server	API e interface web do catálogo
MySQL (interno padrão)	Banco de metadados do OpenMetadata
OpenSearch	Backend de busca para encontrar ativos de dados
K8s Jobs de ingestão	Executor de pipelines de ingestão (padrão; sem dependência de Airflow)
Job de datasources (opcional)	Registra automaticamente os serviços TDP após a instalação

Automações do chart

O chart tdp-openmetadata inclui as seguintes automações:

• URLs dinâmicas — endpoints de API e JWKS são derivados automaticamente do nome do release e do namespace, sem necessidade de configuração manual.
• Bootstrap de credenciais — o usuário admin (admin@open-metadata.org) é criado automaticamente; a senha é configurável via values e exibida na saída do helm install (NOTES).
• Secrets gerados automaticamente — dependências empacotadas (MySQL, OpenSearch) recebem secrets Kubernetes gerados pelo próprio chart.
• Limpeza no uninstall — um Job post-delete remove automaticamente os PVCs, secrets e configmaps deixados pelo release ao executar helm uninstall.

Visão geral

Propriedade	Valor
Chart	tdp-openmetadata
Versão do OpenMetadata	1.12.4
Versão do Chart	3.0.1
Registry (OCI)	oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata

Páginas relacionadas

Página	Conteúdo
Integrações — OpenMetadata	Job de registro de datasources, arquivos de valores modulares, configuração por serviço e execução de pipelines
Segurança — OpenMetadata	Autenticação básica e via LDAP, controle de acesso e boas práticas
Exposição externa	Ingress e Gateway API para o OpenMetadata

Pré-requisitos

• Kubernetes 1.32+, Red Hat OpenShift 4.19+ ou Rancher Manager 2.10.x+.
• Helm 3.2.0+.
• StorageClass disponível no cluster para volumes persistentes.

Instalação

Instalação (OCI)

Instalação no Kubernetes

O comando a seguir cria o release no namespace indicado. Use --wait --wait-for-jobs para aguardar a conclusão dos Jobs pós-instalação antes de retornar — sem esses flags o helm pode reportar sucesso antes de os Jobs terminarem.

Terminal input

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  --wait --wait-for-jobs --timeout 10m

Instalação no OpenShift

No OpenShift, os Jobs de ingestão executam com runAsUser: 0 (root) para instalar dependências via pip. Por isso requerem a SCC (Security Context Constraint) anyuid.
Defina openshift.enabled: true para que o chart configure automaticamente o RoleBinding necessário.

Terminal input

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  --set openshift.enabled=true \
  --wait --wait-for-jobs --timeout 10m

Ou via arquivo de valores:

values-openshift.yaml

openshift:
  enabled: true

Terminal input

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  -f values-openshift.yaml \
  --wait --wait-for-jobs --timeout 10m

Ao habilitar openshift.enabled: true, o chart cria um RoleBinding que adiciona as seguintes ServiceAccounts à SCC anyuid:

ServiceAccount	Uso
openmetadata-ingestion	Jobs de ingestão do OpenMetadata
<RELEASE_NAME>-openmetadata-sa	Job de integração de datasources

Após criar um serviço de dados na UI do OpenMetadata, verifique que os Jobs iniciaram corretamente:

Terminal input

oc get jobs -n <NAMESPACE>
oc get pods -n <NAMESPACE>

Parâmetros principais

Parâmetros principais

A tabela abaixo destaca chaves que definem se o stack sobe, qual imagem roda, como o servidor alcança MySQL e OpenSearch, se há Ingress, e se entram em cena PostgreSQL externo ou o job de datasources. Para a lista completa de parâmetros, consulte helm show values na versão do chart instalada.

Parâmetro	Descrição	Valor padrão
tdp-openmetadata.enabled	Habilitar o deploy do OpenMetadata	true
tdp-openmetadata.image.tag	Tag da imagem do servidor	1.12.4
TDP-Settings.gateway.ingress.enabled	Habilitar Ingress para exposição externa	false
TDP-Settings.gateway.gatewayApi.enabled	Habilitar Gateway API para exposição externa	false
tdp-openmetadata.openmetadata.config.database.dbScheme	Esquema do banco de metadados	mysql
tdp-openmetadata.openmetadata.config.database.host	Host do banco de metadados	tdp-openmetadata-mysql
tdp-openmetadata.openmetadata.config.elasticsearch.searchType	Backend de busca	opensearch
tdp-openmetadata.openmetadata.config.elasticsearch.host	Host do backend de busca	tdp-openmetadata-opensearch
tdp-openmetadata.openmetadata.config.pipelineServiceClientConfig.type	Modo de execução de pipelines: k8s ou airflow	k8s
externalServices.postgresql.enabled	Usar PostgreSQL externo em vez do MySQL empacotado	false
datasourcesIntegration.enabled	Job pós-install/upgrade que registra serviços externos	false
openshift.enabled	Configurar SCC anyuid para ambientes OpenShift	false

Os blocos individuais de cada datasource ficam desabilitados por padrão mesmo quando o job está ativo. Habilite apenas os serviços cujos dados de conexão e credenciais estiverem configurados.

Demais chaves: consulte a saída de helm show values para a versão do pacote que utiliza.

Detalhes de configuração

Integração

O OpenMetadata tem um papel diferente dos demais componentes TDP. Enquanto Ozone, ClickHouse e Trino são consumidos por outras ferramentas (que leem ou escrevem dados neles), o OpenMetadata é quem cataloga e governa os outros: ele descobre, documenta e conecta os ativos de dados de toda a plataforma.

Isso significa que a integração do OpenMetadata é, na prática, conectar o catálogo a cada um dos outros componentes da stack:

Componente registrado	Tipo de serviço no catálogo
Trino	Database Service
ClickHouse	Database Service
Superset	Dashboard Service
Airflow	Pipeline Service
Kafka	Messaging Service

O chart tdp-openmetadata automatiza esse registro por meio de um Job pós-install/upgrade (datasourcesIntegration), que autentica na API do OpenMetadata e cria os serviços habilitados. Você escolhe quais componentes registrar — cada um tem seu próprio bloco de configuração e pode ser habilitado ou desabilitado individualmente.

Além do registro de datasources, o chart também suporta substituição do MySQL interno por PostgreSQL externo (tdp-postgresql). Consulte a seção Banco de dados (PostgreSQL) nesta página.

Para arquivos de valores modulares, configuração por serviço, exemplos de desenvolvimento e produção, verificação e execução de pipelines, consulte Integrações — OpenMetadata.

Execução de pipelines

O OpenMetadata pode executar pipelines de ingestão em dois modos: k8s (padrão), com Jobs Kubernetes, ou airflow, com integração REST com o serviço Airflow.

O comportamento é controlado por pipelineServiceClientConfig.type. Parâmetros por modo e requisitos do Airflow estão em Integrações — OpenMetadata.

Banco de dados (PostgreSQL)

Por padrão, o OpenMetadata usa um MySQL empacotado para armazenar seus metadados. Esta seção descreve como substituí-lo por um PostgreSQL gerenciado pelo chart tdp-postgresql.

O que acontece ao habilitar

Ao definir externalServices.postgresql.enabled: true, o chart executa automaticamente a seguinte sequência:

1. MySQL desabilitado — nenhum pod MySQL é criado; PVCs MySQL não são provisionados.
2. Senha gerada automaticamente — uma senha aleatória é criada para o usuário openmetadata_user e salva em um Kubernetes Secret chamado openmetadata-postgresql-secrets.
3. Job pre-install/pre-upgrade — um Job cria o banco openmetadata_db e o usuário openmetadata_user no PostgreSQL, usando a senha de admin do tdp-postgresql (Secret gerado automaticamente por aquele chart ao instalar).
4. OpenMetadata conecta ao PostgreSQL — após o Job concluir, o servidor OpenMetadata inicia e conecta ao PostgreSQL usando as credenciais geradas no passo anterior.

Os Secrets envolvidos nesta integração são:

Secret	Criado por	Papel
<POSTGRESQL_RELEASE>-postgresql	Chart tdp-postgresql (pré-existente)	Senha do admin do PostgreSQL — lida pelo Job de criação de banco
openmetadata-postgresql-secrets	Chart tdp-openmetadata (hook weight -10)	Senha do usuário openmetadata_user — usada pelo OpenMetadata Server
<RELEASE_NAME>-postgresql-secrets	Chart tdp-openmetadata (hook weight -10)	Cópia prefixada pelo nome do release do secret anterior

Detalhe dos hooks

Quando externalServices.postgresql.enabled: true, o chart executa os seguintes hooks antes de subir o servidor:

1. Hook pre-install/pre-upgrade (weight -10) — cria dois Secrets:

   • openmetadata-postgresql-secrets (usado pelo OpenMetadata)
   • <RELEASE_NAME>-postgresql-secrets (cópia prefixada pelo nome do release)

2. Hook pre-install/pre-upgrade (weight -5) — Job de criação de banco:

   • conecta ao PostgreSQL usando a senha de admin do Secret do tdp-postgresql
   • cria o banco openmetadata_db e o usuário openmetadata_user
   • define o usuário como owner do banco

3. Recursos regulares — o servidor OpenMetadata inicia e conecta ao PostgreSQL.

Pré-requisitos

• Chart tdp-postgresql implantado no mesmo namespace (ou namespace acessível).
• Secret de admin do PostgreSQL criado automaticamente pelo tdp-postgresql.

Quick start

Adicione a configuração do PostgreSQL ao seu arquivo de values e aplique via Helm:

externalServices:
  postgresql:
    enabled: true
    releaseName: "tdp-postgresql"

openmetadata-dependencies:
  mysql:
    enabled: false

tdp-openmetadata:
  openmetadata:
    config:
      database:
        enabled: true
        host: "tdp-postgresql"
        port: 5432
        driverClass: org.postgresql.Driver
        dbScheme: postgresql
        databaseName: openmetadata_db
        auth:
          username: openmetadata_user
          password:
            secretRef: "openmetadata-postgresql-secrets"
            secretKey: "openmetadata-postgresql-password"

Terminal input

helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  -f <VALUES_FILE> \
  --wait --wait-for-jobs --timeout 20m

Configuração manual

Use esta opção quando preferir controle total sobre os parâmetros ou quando não quiser depender do arquivo de overlay fornecido. É necessário configurar explicitamente três blocos: habilitar o PostgreSQL externo, desabilitar o MySQL interno e apontar o OpenMetadata para o novo banco.

Configure os três blocos abaixo no arquivo de valores:

# 1. Habilitar PostgreSQL externo
externalServices:
  postgresql:
    enabled: true
    releaseName: "tdp-postgresql"  # nome do release tdp-postgresql
    namespace: ""                   # vazio = mesmo namespace do OpenMetadata
    database:
      secretName: "openmetadata-postgresql-secrets"  # gerado automaticamente

# 2. Desabilitar MySQL interno
openmetadata-dependencies:
  mysql:
    enabled: false

# 3. Configurar OpenMetadata para PostgreSQL
tdp-openmetadata:
  openmetadata:
    config:
      database:
        enabled: true
        host: "tdp-postgresql"
        port: 5432
        driverClass: org.postgresql.Driver
        dbScheme: postgresql
        databaseName: openmetadata_db
        auth:
          username: openmetadata_user
          password:
            secretRef: "openmetadata-postgresql-secrets"
            secretKey: "openmetadata-postgresql-password"

Deploy em namespaces distintos

Quando o tdp-postgresql está instalado em um namespace diferente do OpenMetadata — por exemplo, em uma instalação compartilhada de banco de dados — é necessário informar o namespace no bloco externalServices e usar o FQDN completo do serviço no campo host, para que o OpenMetadata alcance o PostgreSQL entre namespaces.

Se o PostgreSQL estiver em outro namespace, use o FQDN do serviço:

externalServices:
  postgresql:
    enabled: true
    releaseName: "tdp-postgresql"
    namespace: "postgresql-namespace"

tdp-openmetadata:
  openmetadata:
    config:
      database:
        host: "tdp-postgresql.postgresql-namespace.svc.cluster.local"

Verificação

Terminal input

# Verificar Job de criação do banco
kubectl -n <NAMESPACE> get jobs -l app.kubernetes.io/instance=<RELEASE_NAME>

# Verificar o secret gerado
kubectl -n <NAMESPACE> get secret openmetadata-postgresql-secrets -o yaml

# Confirmar o banco no PostgreSQL
kubectl exec -n <NAMESPACE> <POSTGRESQL_POD> -- psql -U postgres -c "\l openmetadata_db"

Exemplo

Exemplo

kubectl exec -n <NAMESPACE> tdp-postgresql-0 -- psql -U postgres -c "\l openmetadata_db"

Resolução de problemas

Sintoma	Causa provável	Correção
Job falha com "secret not found"	Secret de admin do PostgreSQL ausente	Confirme que tdp-postgresql está implantado e o secret existe
Job falha com "connection refused"	Nome do serviço ou namespace incorreto	Verifique host e namespace nos values
OpenMetadata não conecta	Usuário não criado	Verifique logs do db-create-job
"Secret already exists"	Secret criado manualmente	Remova o secret manual e deixe o chart gerenciar

Migração do MySQL para PostgreSQL

1. Faça backup dos dados (os dados do MySQL não são migrados automaticamente).
2. Desinstale o release atual (mantenha PVCs se quiser referência).
3. Reinstale com o overlay PostgreSQL (instalação limpa com PostgreSQL).

Acesso & Segurança

Exposição externa

Ingress e Gateway API são mutuamente exclusivos, controlados por TDP-Settings.gateway.*. No OpenMetadata, o Ingress fica sob tdp-openmetadata.ingress.* e o Gateway API sob gatewayApi.openmetadata.* (porta 8585).

Para os exemplos completos de values (Ingress e Gateway API), consulte Exposição externa.

Acesso

Enquanto o Ingress permanecer desabilitado ou em configuração, utilize o port-forward abaixo para acessar a interface e a API na porta padrão do serviço.

Terminal input

kubectl port-forward svc/<RELEASE_NAME> 8585:8585 -n <NAMESPACE>

Acesse http://localhost:8585 no navegador. As credenciais padrão são exibidas na saída do helm install (NOTES):

• Usuário: admin@open-metadata.org
• Senha: admin (padrão; altere em produção via values)

Segurança

O OpenMetadata suporta dois modos de autenticação:

• Básico (padrão): usuário/senha local gerenciado pelo próprio OpenMetadata.
• LDAP: autenticação delegada a um diretório corporativo (AD, OpenLDAP etc.).

Em produção, desabilite o auto-cadastro (enableSelfSignup: false) para controlar quem pode criar contas. As credenciais do administrador inicial e do job de datasources não devem ser armazenadas em texto simples nos values — use Kubernetes Secrets.

Para configuração detalhada — LDAP (DNs, atributos, roles, truststore), controle de acesso, Secrets e boas práticas operacionais — consulte Segurança — OpenMetadata.

Solução de problemas

Solução de problemas

Terminal input

kubectl -n <NAMESPACE> get jobs
kubectl -n <NAMESPACE> logs job/<RELEASE_NAME>-register-datasources

Falhas comuns: OpenMetadata ainda não pronto, erro de autenticação, Secret ausente ou serviço de destino inacessível. Para diagnóstico detalhado, consulte Integrações — OpenMetadata.

Desinstalação

Desinstalação

Terminal input

helm uninstall <RELEASE_NAME> -n <NAMESPACE>

O chart inclui um Job post-delete que remove automaticamente os recursos deixados pelo release:

• PVCs: data-mysql-0, opensearch-opensearch-0 e demais volumes do release
• Secrets: mysql-secrets, airflow-secrets, om-secret-* (criados pelos Jobs de ingestão)
• ConfigMaps: mysql-init-scripts e afins
• Jobs e CronJobs: om-job-*, om-cronjob-*, cron-deploy-pipelines, cron-reindex
• Pods concluídos: om-job-*, om-automation-test-connection-*

Para preservar PVCs ou secrets para análise, use --no-hooks (o Job de limpeza não será executado):

Terminal input

helm uninstall <RELEASE_NAME> -n <NAMESPACE> --no-hooks

Verificação após a desinstalação:

Terminal input

kubectl -n <NAMESPACE> get jobs,cronjobs,pods,secrets | \
  grep -E 'om-job-|om-cronjob-|om-secret-|cron-deploy-pipelines|cron-reindex|om-automation-test-connection' || true