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. A base de dados (PostgreSQL) está documentada 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, automatizações e exposição externa ficam em blocos separados no nível raiz:

• tdp-openmetadata: — servidor, imagem, Ingress, base de dados, backend de pesquisa, RBAC.
• externalServices: — referência ao PostgreSQL externo (hooks e palavra-passe admin).
• datasourcesIntegration: — job pós-instalação de registo 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 controlo 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 pesquisa 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 utilizador admin (admin@open-metadata.org) é criado automaticamente; a palavra-passe é 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 registo de datasources, ficheiros 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 ficheiro 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 por omissã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 da base de dados de metadados	mysql
tdp-openmetadata.openmetadata.config.database.host	Host da base de dados de metadados	tdp-openmetadata-mysql
tdp-openmetadata.openmetadata.config.elasticsearch.searchType	Tipo de backend de pesquisa	opensearch
tdp-openmetadata.openmetadata.config.elasticsearch.host	Host do backend de pesquisa	tdp-openmetadata-opensearch
tdp-openmetadata.openmetadata.config.pipelineServiceClientConfig.type	Modo de execução de pipelines: k8s ou airflow	k8s
externalServices.postgresql.enabled	Utilizar PostgreSQL externo em vez do MySQL empacotado	false
datasourcesIntegration.enabled	Job pós-install/upgrade que regista 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 restantes componentes TDP. Enquanto o Ozone, ClickHouse e Trino são consumidos por outras ferramentas (que leem ou escrevem dados neles), o OpenMetadata é quem cataloga e governa os outros: descobre, documenta e liga os ativos de dados de toda a plataforma.

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

Componente registado	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 este registo através de um Job pós-install/upgrade (datasourcesIntegration), que autentica na API do OpenMetadata e cria os serviços habilitados. Escolhe quais os componentes a registar — cada um tem o seu próprio bloco de configuração e pode ser habilitado ou desabilitado individualmente.

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

Para ficheiros 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.

Base 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. Palavra-passe gerada automaticamente — uma palavra-passe aleatória é criada para o utilizador 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 utilizador openmetadata_user no PostgreSQL, usando a palavra-passe 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)	Palavra-passe do admin do PostgreSQL — lida pelo Job de criação de banco
openmetadata-postgresql-secrets	Chart tdp-openmetadata (hook weight -10)	Palavra-passe do utilizador openmetadata_user — usada pelo OpenMetadata Server
<RELEASE_NAME>-postgresql-secrets	Chart tdp-openmetadata (hook weight -10)	Cópia com prefixo do 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 (utilizado pelo OpenMetadata)
   • <RELEASE_NAME>-postgresql-secrets (cópia com prefixo do nome do release)

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

   • liga ao PostgreSQL utilizando a palavra-passe de admin do Secret do tdp-postgresql
   • cria a base de dados openmetadata_db e o utilizador openmetadata_user
   • define o utilizador como owner da base de dados

3. Recursos regulares — o servidor OpenMetadata inicia e liga 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 ficheiro de valores 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

Utilize esta opção quando preferir controlo total sobre os parâmetros ou quando não quiser depender do ficheiro de overlay fornecido. É necessário configurar explicitamente três blocos: habilitar o PostgreSQL externo, desativar o MySQL interno e apontar o OpenMetadata para a nova base de dados.

Configure os três blocos abaixo no ficheiro 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 num namespace diferente do OpenMetadata — por exemplo, numa instalação partilhada de base de dados — é necessário indicar o namespace no bloco externalServices e utilizar o FQDN completo do serviço no campo host, para que o OpenMetadata consiga alcançar o PostgreSQL entre namespaces.

Se o PostgreSQL estiver noutro namespace, utilize 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 aceder à interface e à API na porta padrão do serviço.

Terminal input

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

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

• Usuário: admin@open-metadata.org
• Palavra-passe: 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/palavra-passe 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), controlo de acesso, Secrets e boas práticas operacionais — consulte Segurança — OpenMetadata.

Resolução de problemas

Resoluçã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