infra/openmetadata

Artefactos de operador para el stand-up de OpenMetadata en una VM con Docker Compose. El procedimiento completo, los gates y los criterios de cierre están en docs/runbooks/openmetadata-standup.md. Esto es sólo lo que se copia a la máquina.

Fichero	Qué es
`docker-compose.override.yml`	Los cuatro cambios del arranque reducido, superpuestos al compose oficial de OM
`docker-compose.trino.yml`	Añade Trino, el motor por el que OM ve el Warehouse. Aparte del override a propósito: aquél corrige el compose de OM, éste añade un servicio que no es de OM
`trino/`	Configuración de Trino: catálogo, sólo-lectura y tamaño. Sin secretos — los resuelve con `${ENV:…}` desde el `.env`
`env.example`	Plantilla de las variables que hay que cambiar. Se copia a `.env` en la VM
`Caddyfile`	Proxy inverso con TLS automático — obligatorio, ver §4 del runbook

Nada de esto sustituye a los ficheros de OpenMetadata: se superpone a ellos. Es lo que hace que actualizar de versión sea cambiar su fichero y no reconciliar un fork.

Uso

# En la VM, ya con Docker instalado y vm.max_map_count puesto (§2 del runbook)
mkdir -p ~/openmetadata && cd ~/openmetadata

export OM_VERSION=1.13.3   # confirmar la estable vigente antes de bajar nada
wget "https://github.com/open-metadata/OpenMetadata/releases/download/${OM_VERSION}-release/docker-compose-postgres.yml"

# Copiar aquí los tres ficheros de esta carpeta, luego:
cp env.example .env && chmod 600 .env
$EDITOR .env                      # generar y poner los secretos

# ── PASO OBLIGATORIO antes del primer `up` ──
# Los nombres de servicio del override tienen que casar con los reales:
docker compose -f docker-compose-postgres.yml config --services
# Si no coinciden, renombra las claves del override. Un nombre que no casa
# no da error: tus límites simplemente no se aplican, en silencio.

docker compose -f docker-compose-postgres.yml -f docker-compose.override.yml up -d

Con Trino (para que la Observabilidad tenga datos)

Trino es lo que permite a OM perfilar y ejecutar tests de calidad sobre el Warehouse: OM 1.13.3 no trae conector Iceberg, y el conector customDatabase no soporta perfilador. Approach y gates: docs/architecture/trino-openmetadata-warehouse.md.

docker compose -f docker-compose-postgres.yml \
               -f docker-compose.override.yml \
               -f docker-compose.trino.yml up -d

Antes del primer arranque hay que rellenar en el .env las tres variables TRINO_* (un cliente de Keycloak y un token de R2 de sólo lectura). Y la primera comprobación, que no es de humo sino de invariante — listar tablas puede funcionar con la lectura del dato rota, porque listar es catálogo y leer es storage:

docker compose exec trino trino --catalog lakehouse --execute "SHOW SCHEMAS"

Tienen que salir main.default y main.test. Si sólo sale main, falta nested-namespace-enabled y el catálogo se ve vacío sin dar ningún error.

Verificar que nada quedó expuesto

sudo ss -tlnp | grep -E '8585|9200|5432'

Debe aparecer 127.0.0.1:8585 y nada más. Si ves 0.0.0.0:*, el !override de la lista de ports no se aplicó — Compose apenda las listas de puertos en vez de sustituirlas, así que sin ese tag te quedas con el mapeo público del fichero base además del tuyo. Si tu versión de Compose no soporta !override, edita los ports en el fichero base y deja constancia de esa edición.

Sobre la UI de OpenMetadata

Sí, viene incluida. El servidor sirve la API REST y su interfaz en el mismo puerto 8585: al entrar en https://om.tudominio.com tienes OM entero — descubrimiento, linaje, glosario, calidad, y la gestión de conectores e ingestas.

Pero no es una superficie de producto, es una superficie de operador. La distinción importa y conviene fijarla ahora, antes de que alguien la dé por otra cosa:

	UI de OpenMetadata	Semantic Context Graph (Carbon)
Para quién	operadores y data stewards	el producto
Qué muestra	metadata técnica: tablas, columnas, linaje, calidad	Pods — objetos de negocio gobernados e hidratados
Para qué	configurar conectores, lanzar ingestas, inspeccionar lo ingerido	autorar y publicar lo que consumen los agentes
Escribe en OM	sí (es su casa)	nunca — decisión N2

Que la UI de OM exista es una ventaja real: durante P0 y P1 es exactamente lo que hace falta para ver si la ingesta trajo lo que debía, sin construir nada. Lo que no debe pasar es que se convierta en la puerta por la que los agentes o los usuarios finales miran los datos — por ahí se ven tablas, y eso rompe la invariante del norte («el agente nunca ve las tablas»).

Por eso el Caddyfile deja anotado el endurecimiento posterior: cuando P0 esté verde, lo natural es dejar público sólo /api/v1 —que es lo único que Carbon necesita— y meter la UI tras VPN o autenticación del proxy. No se hace durante el stand-up porque hasta que los conectores estén configurados, la UI es la herramienta.