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:

• RDBMS: PostgreSQL, SQLite, MSSQL, MySQL und Oracle
• MongoDB: Dokumentdatenbank
• Kafka: Verteilte Streaming- und Messaging-Plattform
• Broker: RabbitMQ-Broker für asynchrone Aufgabenverarbeitung
• Object Storage: Skalierbarer Speicher für große unstrukturierte Daten

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

• Add: Füge eine neue Umgebung hinzu.
• Edit environment: Ändere die Einstellungen einer bestehenden Umgebung. Die Schaltfläche befindet sich direkt in der Tabellenzeile.
• More actions (⋯): Öffnet ein Popover mit:
• Refresh metadata snapshot: Scannt für Datenbank-Umgebungen (außer SQLite) die Verbindung, um Metadaten zu erstellen oder zu aktualisieren.
• Reset metadata snapshot: Löscht die gespeicherten Metadaten der ausgewählten Datenbank-Umgebung.
• Delete environment: Entfernt eine Umgebung.

Danger

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

Refresh metadata snapshot (nur Datenbank)

Verwende Refresh metadata snapshot aus dem Popover ⋯ More actions in der Tabellenzeile, um Datenbank-Metadaten für die ausgewählte Umgebung zu erstellen oder zu aktualisieren. Diese Aktion ist nur für Datenbank-Umgebungen verfügbar, die nicht SQLite sind, und fordert vor dem Start zur Bestätigung auf.

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.
• Scans können über ein benutzerdefiniertes Attribut include_tables auf eine kommagetrennte Tabellenliste begrenzt werden, zum Beispiel public.users,public.orders.
• Schemata ohne Berechtigung werden übersprungen und als Warnung im Task-Log protokolliert.

Reset metadata snapshot (nur Datenbank)

Mit Reset metadata snapshot entfernst du veraltete oder inkonsistente Metadaten vor einem neuen Scan.

Empfohlene Reihenfolge nach Schemaänderungen:

1. Reset metadata snapshot
2. Refresh metadata snapshot

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 enthält einen festen ersten und letzten Schritt. Die Schritte dazwischen hängen vom gewählten Umgebungstyp ab. Die meisten Typen erhalten einen Settings- sowie einen Options- bzw. TLS & Security-Schritt und optional einen Advanced / Custom-Schritt:

Typ	Settings-Schritt	Options-/Security-Schritt	Advanced-/Custom-Schritt
RDBMS	DB Settings	DB Options	Ja
MongoDB	MONGO Settings	MONGO Options	Ja
Kafka	KAFKA Settings	TLS & Security (bedingt)	Ja
Object Storage	Object Storage Settings	—	Ja
Broker (RabbitMQ)	Broker Connection (Einstellungen, Zugangsdaten und TLS in einem Schritt)	—	Nein

Schritt 1: Umgebungsdetails

Gib einen Namen für Deine Umgebung ein und wähle einen der Umgebungstypen aus. Die typspezifischen Settings-/Options- bzw. Connection-Schritte entsprechen der obigen Tabelle.

• RDBMS
• MongoDB
• Kafka
• Broker

• Object Storage

Umgebungstyp auswählen

Typspezifische Schritte

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.

DB Settings / DB Options (RDBMS)

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.
• Gib nur eines der beiden Ziele an. Wenn beide gesetzt sind, ist die Priorität derzeit nicht konsistent; verlasse Dich nicht darauf, dass eines der Ziele stillschweigend ignoriert wird.
• Legacy-Oracle-Setups, die nur database setzen, werden weiterhin als service-name-artiges Target aufgelöst.

Datenbankeinstellungen konfigurieren

Broker Connection (RabbitMQ)

Gib Host, Port, User und optional Virtual Host und Password an. Aktiviere Enable TLS, um die Eingaben CA Certificate, Client Certificate und Client Key einzublenden. Broker-Optionen umfassen außerdem Heartbeat, Blocked Connection Timeout, Connection Attempts und Retry Delay. Eine Broker-Umgebung kann im DSL als Quelle und Ziel verwendet werden. Anders als die übrigen Typen hat Broker keinen separaten Advanced-/Custom-Schritt.

MONGO Settings / MONGO Options (MongoDB)

Gib Host und Database Name sowie optional Port, User und Password an. Unter Options kannst Du Auth Source, Auth Mechanism (PLAIN, SCRAM-SHA-1, SCRAM-SHA-256, MONGODB-CR, MONGODB-X509, GSSAPI), Compressors (snappy, zlib, zstd), TLS und Read Only konfigurieren.

Object Storage Settings

Wähle einen Type (aws, minio oder azure) und gib Host an. Optional kannst Du Port, Access Key, Secret Key, Use TLS/SSL und eine Connection String für Azure oder benutzerdefinierte Endpunkte angeben.

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.

Letzter Schritt: Überprüfen und bestätigen

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

Kafka-Sicherheitsreferenz (Enterprise-Kurzleitfaden)

Kafka-Sicherheitsmodi

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

Bedeutung der TLS-Felder

• CA Certificate: Trust-Anker, mit dem der Client Broker-Zertifikate prüft. In der Regel für SSL und SASL_SSL erforderlich; die konkrete Pflicht hängt von Broker-Trust-Policy und Konfiguration ab.
• 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.

Tip

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