Produktion On-Prem einrichten

Herausforderung

Teams übernehmen die Compose-PoC-Datei 1:1 auf einen Server im Rechenzentrum und nennen das „Produktion“. Die UI antwortet, also gilt die Aufgabe als erledigt. Wochen später fehlen TLS, getrennte Ingestion-Runner, Restore-Nachweise und ein benannter Platform-Owner. Der erste Disk-Full, Credential-Leak oder fehlgeschlagene Connector-Job zeigt: Es lief nur eine lange PoC.

Typische Symptome:

• Admin-UI ohne TLS oder hinter einem Ad-hoc-Port-Forward.
• Metadata Store und Search auf derselben unterdimensionierten Disk ohne Snapshot-Richtlinie.
• Ingestion „irgendwo“ im Cluster — niemand besitzt Retry, Queue und Alerts.
• Produktions-Warehouse-Credentials im Ticket-System oder in einer Git-.env.

Ansatz

On-Prem-Produktion als gehärtete Control Plane bauen: Persistenz, Netzwerk/TLS, Secrets, getrennte Ingestion, Backup-Baseline und Platform-Owner — bevor der erste Prod-Connector läuft. Der Blueprint aus Teil 2 wird verbindlich umgesetzt, nicht „ungefähr Compose“.

Für kleine Teams kann ein Ubuntu-Host mit Docker Compose ein produktionsnaher Pilot sein. Das ist aber nur vertretbar, wenn ihr ihn wie Betrieb behandelt: feste Versionen, /opt/openmetadata, externe oder bewusst betriebene DB/Search-Komponenten, TLS, Secret-Management, Backup und Monitoring. Die offizielle Docker-Deployment-Doku weist genau deshalb darauf hin, dass produktive Setups nicht blind auf Quickstart-Abhängigkeiten beruhen sollten.

Für robuste Produktion bleibt die klarere Zielarchitektur meist Kubernetes/Helm: Rollouts, Ressourcen, Namespaces, Secrets, Monitoring und Ingestion-Runtime lassen sich dort sauberer trennen. Compose ist dann eher Pilot/kleiner Betrieb; Helm/Kubernetes ist der bessere Weg, wenn OpenMetadata ein dauerhaftes Plattformprodukt wird.

Ingress/TLS → OM Server (HA)
           → Metadata Store + Search (persistiert, kapazitätsgeplant)
Ingestion Runners (eigene Nodes/Namespace, monitored)
Secrets (Vault) + Identity (SSO)
Backup + Restore-Nachweis (Teil 10)

Pflichtentscheidungen vor Go-Live

Empfohlenes Vorgehen (Reihenfolge)

1. Serverweg wählen und die benötigten Komponenten aus Teil 2 prüfen.
2. Namespace/Cluster, Ingress, TLS und StorageClasses bereitstellen; Netzwerkzonen zu Sources skizzieren.
3. Metadata Store und Search mit Backup-Pfad deployen (Restore später in Teil 10 testen).
4. OM Server hinter Ingress; Health-Checks, Resource Limits und mindestens zwei Replicas, falls HA gefordert ist.
5. SSO und Secret-Store anbinden (Teil 9) — vor Prod-Usern und Prod-Connectors.
6. Ingestion-Runner in eigenem Namespace deployen; Non-Prod-Kurztest-Connector grün fahren.
7. Restore-Test und Upgrade-Probe auf Staging (Teil 10) dokumentieren.
8. Zuerst einen begrenzten Connector testen; die eigene Connectors-Serie erklärt dessen Einrichtung.

Installation Schritt für Schritt: vom Paket zum geprüften System

Erweiterung geprüft am 26.10.2026: OpenMetadata-Dokumentationslinie 2.0.x, Bezugsrelease 2.0.6. Die Herstellerhilfe kann noch Befehle für andere Patchstände zeigen. Die hier genannte Referenz ist keine automatische Auswahl der neuesten oder für euch freigegebenen Version. Release-Datei, Server, Ingestion-Paket, Chart und Abhängigkeiten im Projekt konkret abgleichen. Die Anleitung wurde redaktionell geprüft; keine Installation in einer Kundenumgebung wurde ausgeführt.

1. Die Zielumgebung vorbereiten

Dieser Weg gilt für eine dauerhaft betriebene Serverinstanz. Für den Laptop-Test verwendest du stattdessen die Plattformartikel aus Teil 4–6.

Halte den unterstützten Release, Serveradresse, Betriebskonto und Installationsverzeichnis bereit. Prüfe die Versionen der Datenbank, des Suchdienstes und der Ingestion-Laufzeit gegen die Herstellerhilfe. Stelle persistente Speicherorte und die erforderlichen Netzwerkverbindungen bereit. Zugangsdaten werden über den für diese Umgebung vorgesehenen Mechanismus bereitgestellt; sie gehören nicht in Git oder frei zugängliche Notizen.

Ein Projektformular oder eine ausgefüllte Kundenakte ist kein Installationsschritt. Optionale technische Notizen kannst du nach dem erfolgreichen Start ergänzen.

2. Abhängigkeiten vor dem Start bereitstellen

Der Server stellt Oberfläche und API bereit. Die Metadaten-Datenbank hält den Katalogbestand. Der Suchdienst ermöglicht dessen Suche. Ein Runner führt die Metadatenaufnahme aus; er braucht einen Netzweg sowohl zur Quelle als auch zum OpenMetadata-Server. Diese Rollen im Komponentenregister getrennt erfassen.

1. Konkrete Datenbank- und Suchversion anhand der zur Zielversion gehörenden Herstellerhilfe prüfen. Nicht irgendeine vorhandene Instanz übernehmen.
2. Persistente Speicherorte und Zuständigkeiten festlegen. Ein Containerneustart darf den Katalogbestand nicht verlieren.
3. DNS, Ports und Zertifikatsvertrauen für jeden notwendigen Netzweg prüfen: Nutzer → Server, Server → Datenbank/Suche, Runner → Quelle/Server; bei UI-gesteuerter Ingestion zusätzlich die benötigte Steuerverbindung zur Laufzeitumgebung.
4. Zugangsdaten in der freigegebenen Secret-Ablage vorbereiten. In Formular, Ticket und Git nur Referenzen speichern.
5. Kapazität mit dem Pilot messen: Objektanzahl, Laufdauer, Speicherentwicklung und Suchreaktion festhalten. Die Messung und erwartetes Wachstum begründen die Dimensionierung.

Stoppen, wenn ein notwendiger Netzweg ungeklärt ist, die Versionskombination nicht belegt werden kann oder kein betreuter persistenter Speicher vorhanden ist.

3. Docker-Pilot kontrolliert aufsetzen

Für einen betriebenen Docker-Host empfiehlt die Herstellerhilfe eigene, betreute Datenbank- und Suchabhängigkeiten statt ungeprüfter Quickstart-Komponenten. Wählt im freigegebenen Release die passende Datei aus; verwendet keinen unbemerkten latest-Download.

1. Release-Datei unverändert als Bezugsartefakt ablegen; Herkunft, Datum und Prüfsumme dokumentieren. Arbeitskopie und Freigabe trennen.
2. Externe Abhängigkeiten und Serverkonfiguration nach der Docker-Hilfe für genau diese Version eintragen. env-pilot ist hier euer lokal vorbereiteter Dateiname, keine mitgelieferte Standarddatei.
3. Vor dem Start prüfen. Die folgenden Befehle setzen installierte Docker-/Compose-Werkzeuge und bereits vorbereitete Dateien voraus:

# Im vorbereiteten Arbeitsverzeichnis ausführen.
docker --version
docker compose version
docker compose -p om-pilot -f docker-compose-openmetadata.yml --env-file ./env-pilot config --quiet
docker compose -p om-pilot -f docker-compose-openmetadata.yml --env-file ./env-pilot config --services
docker compose -p om-pilot -f docker-compose-openmetadata.yml --env-file ./env-pilot config --images

config --quiet prüft die Compose-Konfiguration, nicht Datenbankrechte oder die Erreichbarkeit einer Quelle. Die tatsächlichen Image-Tags mit dem gewählten Release vergleichen. Ausgaben einer vollständig aufgelösten Konfiguration können Zugangsdaten enthalten; deshalb hier keine vollständige config-Ausgabe weiterreichen.

4. Nach Freigabe der vorbereiteten Konfiguration starten und den Zustand ansehen:

docker compose -p om-pilot -f docker-compose-openmetadata.yml --env-file ./env-pilot up --detach
docker compose -p om-pilot -f docker-compose-openmetadata.yml --env-file ./env-pilot ps

5. Start- und gegebenenfalls Migrationsmeldungen gemäß Releasehilfe prüfen. „Container läuft“ bedeutet noch nicht „Anwendung bereit“. Oberfläche, Anmeldung, Suche und einen begrenzten Lauf einzeln testen.

Fehlersuche: Bei DB-Verbindungsfehlern aus dem Servernetz prüfen; bei fehlendem Quellobjekt aus dem Runnernetz und mit dessen Identität prüfen. Bei Suchfehlern direktes Objekt und Suchtreffer getrennt vergleichen. Nicht pauschal zusätzliche Adminrechte vergeben.

4. Kubernetes bewusst als eigenen Installationsweg behandeln

Die Kubernetes-Hilfe verwendet Helm. Ein Helm-Chart beschreibt die Bereitstellung; seine Version ist nicht automatisch die Serverversion. Das Team benötigt einen betreuten Cluster. Kubernetes allein macht eine Anwendung nicht hochverfügbar.

1. Namespace, betreute DB/Suche, Storage, Ressourcen und Betriebszugriffe festlegen.
2. Chartversion und zugehörige Standardwerte prüfen; eure Änderungen in einer eigenen versionierten Values-Datei dokumentieren. Secrets nur referenzieren.
3. Ingress/TLS und Netzregeln explizit prüfen. Nicht annehmen, dass sie durch die Installation automatisch sicher eingerichtet sind.
4. Erst gerenderte Konfiguration und Migrationen prüfen, dann mit dem freigegebenen Verfahren ausrollen. Reihenfolge und Abbruchkriterien vor dem Ausrollen prüfen.
5. Startbereitschaft, Neustartverhalten und die tatsächlichen Anwendungstests nachweisen. Für die geforderte Verfügbarkeit auch Datenbank, Suche und Ingestion betrachten.

5. Die tatsächliche Installation prüfen

1. Oberfläche über die vorgesehene Adresse öffnen und Zertifikat prüfen.
2. Mit einer normalen Testidentität anmelden; eine erlaubte und eine nicht erlaubte Aktion prüfen.
3. Einen Testgegenstand speichern und nach einem kontrollierten Neustart wiederfinden.
4. Bei eingerichteter Ingestion einen begrenzten Testlauf ausführen; Quelle und Runner müssen erreichbar sein.
5. Für die dauerhafte Instanz Sicherung und Wiederherstellung nach Teil 10 prüfen. Ein erfolgreiches Startprotokoll beweist keine Wiederherstellung.

Bei einem Fehler zuerst den betroffenen Baustein und dessen Logs untersuchen. Eine Formularvorlage ist für diese Tests nicht nötig. Für spätere betriebliche Dokumentation stehen Plattformwerkzeug und Upgrade-Planer optional bereit.

Abgrenzung zum PoC

Troubleshooting-Hinweise

• UI up, Discovery leer/langsam: Search-Cluster oder Disk prüfen; Index-Jobs und Heap/CPU.
• Connector „Permission denied“: Netzwerkpfad und Least-Privilege-User getrennt von Human-SSO prüfen.
• Jobs veraltet ohne Alert: Ingestion-Monitoring und Freshness-SLO fehlen — Teil 10.
• Nach Reboot Daten weg: Persistenz/Volumes falsch gemountet — vor Produktivstart fixen.

Häufige Anti-Patterns

• Laptop-Compose auf einen „Produktion-Server“ kopieren und hoffen.
• Ingestion und UI unmonitored im selben Deployment.
• Produktions-Warehouse-User mit Schreibrechten für den Katalog-Metadatenimporter.
• Produktivstart ohne benannten Platform-On-Call.
• Environments in einem Service-Namen vermischen (prod und dev im selben FQN-Raum).

Hilfe beim Umsetzen

Arbeitet die Go-Live-Tabelle zeilenweise ab und datiert jede Zeile. Ohne Datum zählt sie nicht. Restore-Probe und SSO (Teil 9) sind harte Gates vor dem ersten Prod-Connector.

Parallelisieren: Netz/TLS und Persistenz können parallel zu Secret-Store laufen; Ingestion-Runner erst wenn Server+Store gesund sind. Den ersten Connector mit einem kleinen Testumfang nach der eigenen Connectors-Serie einrichten.

Nutzt OpenMetadata-Ingestions-Generator für die erste Service-Config, sobald Secrets im Vault liegen.

Checkliste

• Restore mindestens einmal erfolgreich getestet und datiert?
• SSO und Secret-Store angebunden?
• Ingestion-Runner getrennt und mit Alerting?
• Ersten Connector mit begrenztem Testumfang geprüft?
• Environments in Namen/FQNs getrennt?
• TLS und Netzwerkdiagramm abgenommen?

Artefakt

On-Prem Go-Live Checklist plus Netzwerk-/Secret-Diagramm und Verweis auf das Restore-Protokoll (Teil 10).

Tools

• OpenMetadata Deployment — produktionsorientiertes Deploy (K8s/Helm, Compose-Härte).
• OpenMetadata-Ingestions-Generator — Ingestion-Service-Config und Setup-Checkliste nach Produktivstart-Härte.
• Vault / K8s Secrets, Ingress, Observability (intern) — Secrets, TLS, Alerts.

Ressourcen

• OpenMetadata Deployment
• Docker production-oriented deploy