Umgebungen

Der Abschnitt Umgebungen ermöglicht es Dir, verschiedene Umgebungen für Dein Projekt zu konfigurieren. Du kannst neue Umgebungen hinzufügen, bestehende bearbeiten oder bei Bedarf Umgebungen löschen.

Umgebungstypen

In DATAMIMIC kannst Du die folgenden Typen von Umgebungen konfigurieren:

• Database
• Kafka
• Mongo
• Data Warehouse

Tip

Wenn ein benötigter Umgebungstyp fehlt, nimm bitte Kontakt mit unserem Team auf, um diesen Umgebungstyp für Deinen Account oder Deine Instanz zu aktivieren.

Verwalten von Umgebungen

Sobald Du Umgebungen hinzugefügt hast, kannst Du sie im Umgebungen-Bereich verwalten.

Umgebungen verwalten

Verfügbare Aktionen

• Hinzufügen: Füge eine neue Umgebung hinzu.
• Metadaten scannen: Für Datenbank-Umgebungen (außer SQLite) werden Metadaten erstellt oder aktualisiert.
• Metadaten zurücksetzen: Löscht die gespeicherten Metadaten der ausgewählten Datenbank-Umgebung.
• Bearbeiten: Ändere die Einstellungen einer bestehenden Umgebung.
• Löschen: Entferne eine Umgebung.

Danger

Das Löschen einer Umgebung ist eine endgültige Aktion und kann nicht rückgängig gemacht werden.

Metadaten scannen (nur Datenbank)

Mit Metadaten scannen (Wiederholen-Symbol in der Tabellenzeile) erstellst oder aktualisierst du Datenbank-Metadaten für die ausgewählte Umgebung. Diese Aktion ist nur für Datenbank-Umgebungen verfügbar, die nicht SQLite sind.

Scan-Verhalten:

• Der Scan reflektiert alle Schemata der ausgewählten Datenbank, auf die der konfigurierte Benutzer zugreifen kann.
• Das in der Umgebung konfigurierte Schema bleibt das Default-Schema für nicht qualifizierte Namen.
• Schemata ohne Berechtigung werden übersprungen und als Warnung im Task-Log protokolliert.

Metadaten zurücksetzen (nur Datenbank)

Mit Metadaten zurücksetzen entfernst du veraltete oder inkonsistente Metadaten vor einem neuen Scan.

Empfohlene Reihenfolge nach Schemaänderungen:

1. Metadaten zurücksetzen
2. Metadaten scannen

Hinzufügen einer Umgebung

Um eine neue Umgebung hinzuzufügen, klicke auf die Schaltfläche Add oben rechts im Umgebungen-Bereich.

Schritte des Assistenten zum Hinzufügen einer Umgebung

Der Assistent führt Dich durch mehrere Schritte, um Deine Umgebung zu konfigurieren:

Schritt 1: Name und Typ auswählen

Gib einen Namen für Deine Umgebung ein und wähle einen der Umgebungstypen aus.

• Database
• Kafka
• Mongo

• Data Warehouse

Umgebungstyp auswählen

Schritt 2: Verbindungseinstellungen konfigurieren

Die Einstellungen in diesem Schritt hängen vom gewählten Umgebungstyp ab.

Verhalten von Test Connection

Die Aktion Test Connection validiert jetzt die gespeicherte Umgebungs-Konfiguration über denselben Runtime-Materialisierungspfad, der auch bei der eigentlichen Ausführung verwendet wird. In der Praxis bedeutet das: descriptor-lokale Umgebungs-Properties und TLS-Materialien verhalten sich zwischen Setup-Check und realem Lauf konsistenter. Die Umgebungs-Konfiguration bleibt auch dann gespeichert, wenn der Test fehlschlägt, sodass du korrigieren und erneut testen kannst, ohne alles neu eingeben zu müssen.

Datenbankeinstellungen

Konfiguriere Deine Datenbankeinstellungen. Wenn Du beispielsweise PostgreSQL auswählst, musst Du Details wie Host, Port, Datenbankname, Schema, Benutzer und Passwort angeben.

Für Kafka-spezifische TLS/SASL-Verbindungsführung siehe Kafka TLS & Security.

Oracle-spezifische Hinweise:

• Oracle-Verbindungen unterstützen sowohl Service Name als auch SID als Ziel.
• Wenn sowohl Service-Target als auch SID gesetzt sind, wird Service-Auflösung bevorzugt.
• Legacy-Oracle-Setups, die nur database setzen, werden weiterhin als service-name-artiges Target aufgelöst.

Datenbankeinstellungen testen

Kafka TLS & Security (Vereinfachter Flow)

Wenn Du eine Kafka-Umgebung mit SSL oder SASL_SSL konfigurierst, ergänzt der Assistent jetzt einen eigenen Schritt TLS & Security.
Bei PLAINTEXT wird dieser Schritt ausgeblendet, damit der Ablauf fokussiert bleibt.

Kafka-TLS-Schritt mit vereinfachter Zertifikats-Eingabe (Upload-Flow mit explizitem Apply)

Warum dieser Flow einfacher ist:

• Kein leerer Security-Schritt: TLS/SASL-Bereiche erscheinen nur, wenn das gewählte Security-Protokoll sie wirklich benötigt.
• Upload-first UX: Drag-and-drop ist der primäre Eingabeweg für PEM/Key-Dateien; gestagte Änderungen werden explizit übernommen.
• Weniger Zertifikats-Reibung: CA Certificate, Client Certificate und Client Key sind im selben TLS-Schritt gruppiert; Client-Zertifikat/Key nur setzen, wenn der Broker mTLS verlangt.
• Konsistentes Storage/Runtime-Verhalten: Hochgeladene binäre Materialien werden in ein runtime-sicheres Format konvertiert und für Healthcheck sowie Task-Ausführung konsistent genutzt.

Kafka-Sicherheitsmodi (Enterprise-Kurzleitfaden)

Protokoll	Transportverschlüsselung	Authentifizierung	Typischer Zertifikatsbedarf
PLAINTEXT	Nein	Keine	Kein TLS-Material
SASL_PLAINTEXT	Nein	SASL User/Passwort	Kein TLS-Material
SSL	Ja	TLS-zertifikatsbasiert	CA Certificate immer, Client-Zertifikat/Key nur bei mTLS
SASL_SSL	Ja	SASL User/Passwort über TLS	CA Certificate immer, Client-Zertifikat/Key nur wenn Broker mTLS erzwingt

Bedeutung der TLS-Felder

• CA Certificate: Trust-Anker, mit dem der Client Broker-Zertifikate prüft. Pflicht für SSL und SASL_SSL.
• Client Certificate: öffentliche Zertifikatskette, die der Client bei erforderlicher Client-Authentifizierung (mTLS) vorlegt.
• Client Key: privater Schlüssel passend zum Client-Zertifikat.
• Client Key Password: nur erforderlich, wenn der private Schlüssel verschlüsselt ist.

Regeln für Zertifikatsketten

• Nutze PEM-Format für alle TLS-Materialien.
• Die Datei für Client Certificate sollte enthalten:
• Leaf/Client-Zertifikat zuerst
• danach Intermediate-CA-Zertifikate
• kein privater Schlüssel in dieser Datei
• Die Datei für CA Certificate sollte vertrauenswürdige CA-Zertifikate enthalten (Root und bei Bedarf Intermediates).
  Ergänze Intermediates, wenn die Broker-Kette unvollständig ist oder die Enterprise-Trust-Policy explizite Bundles verlangt.

mTLS-Entscheidungslogik

• Wenn brokerseitig ssl.client.auth=required aktiv ist, muss der Client ein gültiges Client Certificate + Client Key liefern.
• Wenn Client-Auth brokerseitig nicht erforderlich ist, reicht typischerweise CA Certificate (plus SASL-Credentials bei SASL_SSL).
• Wenn nur Client Key ohne Client Certificate gesetzt ist, funktioniert Client-Zertifikatsauthentifizierung nicht; konfiguriere beide zusammen.

Empfohlene Validierungsreihenfolge

1. Protokoll und Auth-Modus mit Plattform-/Netzwerkteam klären (SSL vs SASL_SSL, mTLS erforderlich oder nicht).
2. Trust-Pfad des Broker-Zertifikats mit deinem CA-Bundle validieren.
3. Wenn mTLS erforderlich ist, Client-Zertifikat/Key-Paar und Key-Passwort gemeinsam vor dem Rollout prüfen.
4. Negativtest durchführen:
5. erwartetes mTLS: Verbindung ohne Client-Zertifikat muss fehlschlagen.
6. erwartetes non-mTLS: Verbindung mit CA + Protokoll-Credentials sollte funktionieren.
7. Verhalten gegen die effektive Broker-Runtime-Konfiguration prüfen (nicht nur gegen Repository-Defaults).

Häufige Fehlkonfigurationsmuster

• Falsches Key-Passwort scheint keinen Effekt zu haben: typischerweise wird der Client-Key nicht genutzt (zum Beispiel fehlendes Client-Zertifikat).
• Handshake-Fehler in Enterprise-Clustern: häufig verursacht durch unvollständige CA-Kette oder falsches Zertifikat/Key-Pairing.
• Unterschiedliches Verhalten zwischen Umgebungen: effektive Broker-Konfiguration weicht zwischen Test- und Produktiv-Cluster ab.

Schritt 3: Bestätigen

Überprüfe Deine Einstellungen und bestätige die Erstellung der neuen Umgebung.

Tip

Du findest Dein Datenbanksystem nicht? Nimm Kontakt mit unserem Team auf, um diesen Typ für Deinen Account oder Deine Instanz zu aktivieren.