Eine Anwendung mit einer privaten Datenbank verbinden

Dieser Ablauf gibt einer Anwendung privaten Datenbankzugriff, ohne den Datenbankport zu veröffentlichen und ohne die Zugangsdaten des Datenbankbesitzers zu teilen. Opfield erstellt ein dauerhaftes Binding – die verwaltete Beziehung zwischen einem Workload und einer Datenbank – und stellt für diese Beziehung eine eigene Engine-Identität bereit.

Wenn dies Ihr erster Datenbankablauf ist, lesen Sie die Datenbankübersicht, bereiten Sie eine verwaltete Datenbank vor und machen Sie sich mit dem Verhalten von Anwendungs-Bindings vertraut, bevor Sie Produktionsdaten anlegen.

Der Workload erhält nur die Verbindungswerte, die er benötigt. Das Entfernen des Anwendungszugriffs und das Löschen der Datenbank sind getrennte Operationen.

Entscheiden, ob eine verwaltete Datenbank geeignet ist

Verwenden Sie eine von Opfield verwaltete PostgreSQL-, Key-Value- oder ClickHouse-Instanz, wenn Opfield auf einem Storage Node für Bereitstellung, Laufzeit-Lebenszyklus, Kapazitätseinstellungen, Zugangsdaten, Monitoring und private Workload-Bindings zuständig sein soll. Verwenden Sie eine externe Verbindung, wenn eine andere Plattform die Datenbank bereits betreibt und Opfield nur die Verbindung speichert und Health Checks, Explorer, Konsole und Backups dagegen ausführt. Bindings und damit dieser Ablauf gelten nur für verwaltete Datenbanken; eine Anwendung, die eine externe Datenbank verwendet, erhält ihre Verbindungswerte als Workload-Secrets. Vergleichen Sie beide Modelle unter Verwaltete und externe Datenbanken im Überblick.

Geben Sie vor dem Anlegen von Daten frei:

• die Datenbank-Engine und die unterstützte Version;
• den Storage Node und den Ort des dauerhaften Speichers;
• Limits für CPU, Arbeitsspeicher, Swap und Speicher;
• die Zuständigkeit für Backup, Aufbewahrung, Wiederherstellung und Löschung;
• ob eine direkte TCP-Veröffentlichung wirklich erforderlich ist;
• welche Anwendungsressource das Binding erhalten wird;
• erwartete Verbindungslimits und das Wiederholungsverhalten der Anwendung.

Das Löschen einer verwalteten Datenbank ist destruktiv und entfernt ihre verwaltete Festplatte bzw. ihr Image oder ihren Mount zusammen mit der Instanz. Das Löschen einer Verbindung oder eines Bindings ist nicht dieselbe Aktion. Machen Sie diese Unterscheidung in den Berechtigungen der Operatoren und in den Runbooks deutlich.

1. Den Storage Node vorbereiten

Registrieren Sie einen dedizierten Storage Node und prüfen Sie seine Speicher-Vorabprüfung. Storage Nodes verwenden verwalteten Speicher fester Größe, dessen Grenze auf dem Host durchgesetzt wird. Das Installationsprogramm prüft die lokale Docker Engine und den Lebenszyklus aus Loop-Device, Mount, Schreiben, Vergrößern, Größenänderung, Unmount und Trennen, den verwaltete Instanzen verwenden.

Eine VM oder ein Bare-Metal-Host stellt diese Fähigkeiten normalerweise direkt bereit. Ein LXC-Gast benötigt ausdrückliche Berechtigungen für Loop-Devices und Mounts von seinem äußeren Host; Opfield weicht nicht auf ein unbegrenztes Volume aus, wenn die erforderliche Grenze fehlt.

Der Node sollte online sein, genug nicht zugewiesenen Speicher für die angeforderte Datenbank haben und über ein dokumentiertes Backup-Ziel verfügen. Platzieren Sie keine Anwendungscontainer auf einem Storage Node, nur weil beide intern Docker verwenden.

2. Die Datenbank privat bereitstellen

Öffnen Sie Databases, wählen Sie die unterstützte Engine und Version, wählen Sie den Storage Node und konfigurieren Sie die Ressourcen- und Speicherlimits. Lassen Sie Publish TCP deaktiviert, sofern direkter Client-Zugriff nicht eine geprüfte Anforderung ist. Die Veröffentlichung und ihr Host-Port können später in den Datenbankeinstellungen geändert werden; Opfield erstellt dann den Datenbankcontainer neu und behält seine Daten, planen Sie also eine kurze Unterbrechung ein.

Warten Sie, bis Bereitstellung und Health Checks Ready erreichen. Bestätigen Sie die angezeigte Engine, den Node, die Speicherkapazität, den TLS-Zustand und das Monitoring. Fahren Sie nicht aus einem lediglich erstellten oder startenden Zustand fort.

Opfield hält die Zugangsdaten des Engine-Besitzers intern. Reveal credentials zeigt nur, solange die TCP-Veröffentlichung aktiviert ist, einen separaten Benutzer für den direkten Zugriff; er ist für kontrollierte externe Administration gedacht und nicht als Zugangsdaten, die in jede Anwendung kopiert werden.

3. Das Anwendungs-Binding erstellen

Öffnen Sie den Ziel-Container, das Deployment oder den Compose-Dienst und erstellen Sie eine Verbindung zu einer verwalteten Datenbank. Wählen Sie die Datenbank und die unterstützten Verbindungsvariablen bzw. -optionen. Opfield erstellt für dieses Binding eine eigene PostgreSQL-Rolle, einen eigenen ACL-Benutzer des Key-Value-Stores oder einen eigenen ClickHouse-Benutzer.

Bei einem eigenständigen Container bindet Opfield das private Binding-Netzwerk an und verwendet den normalen Neuerstellungsablauf, um die Verbindungsumgebung anzuwenden. Bei einem Deployment wird die Sollkonfiguration aktualisiert und ein Slot wird ausgerollt, sodass künftige Blue- und Green-Instanzen denselben privaten Endpunkt erhalten, der vom gemeinsamen Secure-Link-Connector des Ziel-Docker-Nodes bedient wird. Compose hält das Binding am zuständigen Dienst statt an einem flüchtigen Namen eines untergeordneten Containers. Auch ein Workload, der gestoppt ist, fehlschlägt oder noch nicht bereitgestellt wurde, kann verbunden werden: Das Binding wird als pending gespeichert und angewendet, wenn der Workload das nächste Mal startet oder seinen Rollout abschließt; siehe Workloads, die nicht laufen.

Wenden Sie den Workload nur dann an oder erstellen Sie ihn nur dann neu, wenn die Oberfläche anzeigt, dass die geänderte Laufzeitkonfiguration es erfordert. Der Sollzustand des Bindings ist dauerhaft; eine normale Neuerstellung des Workloads darf nicht jedes Mal einen neuen Engine-Benutzer erzeugen.

4. Aus der Anwendung prüfen

Verwenden Sie die Anwendung oder eine kontrollierte Diagnose innerhalb des Workloads, um eine Verbindung zu öffnen und eine harmlose, Engine-spezifische Operation auszuführen. Prüfen Sie:

• dass Hostname, Port, Datenbankname und Zugangsdaten aus dem Binding stammen und nicht aus kopierten Zugangsdaten des Besitzers; das Binding verbindet sich über das private Binding-Netzwerk und fügt keine TLS-Einstellungen hinzu;
• dass die Verbindung gelingt, ohne den Host-Port der Datenbank zu veröffentlichen;
• dass die Engine den Binding-spezifischen Benutzer sieht;
• dass Verbindungs- und Abfrageverhalten zu den Pool-Einstellungen der Anwendung passen und die Pools aller Container, die die Datenbank gemeinsam bedient, unter dem eigenen Verbindungslimit der Datenbank bleiben, das sich alle ihre Verbindungen teilen, ebenso wie beide Deployment-Slots während eines Rollouts: PostgreSQL max_connections (standardmäßig 100, 20–10000, festgelegt unter Database Settings → Maximum connections), maxclients des Key-Value-Stores oder 4096 bei ClickHouse (Verbindungskapazität);
• dass die Laufzeittelemetrie des Bindings fehlerfrei wird und die erwarteten Datenströme bzw. den erwarteten Datenverkehr zeigt;
• dass die Workload-Logs die Secret-Werte nicht ausgeben.

Erstellen Sie den Workload dann über seinen normalen Opfield-Lebenszyklus neu und wiederholen Sie die Abfrage. Starten Sie während des Abnahmetests den Docker-Daemon neu oder verbinden Sie den Node erneut und bestätigen Sie, dass der Abgleich die Verbindung und das Binding wiederherstellt, ohne eine zusätzliche Rolle zu erzeugen. Ein Neustart von Opfield unterbricht bestehenden Binding-Verkehr nicht; ein Relay-Update kann es.

Erwartete Garantien und Grenzen

• Der Workload erhält nicht die Zugangsdaten des Datenbankbesitzers.
• Jedes Binding erhält eine eigene Engine-Identität, die unabhängig widerrufen werden kann.
• Die Neuerstellung des Workloads bewahrt die Zuständigkeit für das Soll-Binding.
• Das Löschen eines Bindings widerruft seinen Prinzipal, ohne die Datenbank zu löschen.
• Neue Zulassungen schlagen sicher fehl (fail closed), wenn der benötigte Pfad über Datenbank, Daemon oder Relay nicht verfügbar ist.
• Der Abgleich stellt die Verbindung des Bindings wieder her und validiert die bestehende Engine-Identität, statt bei vorübergehenden Fehlern verwaiste Benutzer zu erzeugen.

Ein privates Binding ist weder ein Backup noch eine Replikation noch ein Hochverfügbarkeitssystem. Die Verfügbarkeit der Datenbank hängt weiterhin von der verwalteten Instanz, ihrem Node, dem Speicher und Ihrem Wiederherstellungskonzept ab. In Business und Enterprise kann die Datenbank selbst auf 2 bis 5 Storage Nodes laufen, einem Primary und seinen Kopien; Bindings erreichen immer den Primary (Datenbanken und Speicher auf mehreren Servern). Relay-Updates sind ausdrückliche Wartung der Datenebene und können Tunnelsitzungen unterbrechen; Updates von Anwendung bzw. Control Plane und Relay-Wartung sind unterschiedliche Ereignisse.

Fehler und sichere Wiederherstellung

Ist das Binding fehlerhaft, ermitteln Sie zuerst, welche Ebene nicht verfügbar ist: Anwendungs-Workload, Docker Node, der Secure-Link-Connector des Nodes, Relay, Storage Node, Datenbankinstanz, Engine-Identität oder TLS. Prüfen Sie den begrenzten Operationsverlauf und die Logs, bevor Sie den Zustand ändern.

Bevorzugen Sie nach Behebung der Ursache einen Abgleich oder eine gezielte Wiederholung. Löschen Sie Netzwerke, Connectoren oder Engine-Benutzer, die Opfield gehören, nicht manuell; das kann aus einem behebbaren Laufzeitausfall eine Zuständigkeitsabweichung oder ein verwaistes Bereinigungsproblem machen. Veröffentlichen Sie den Datenbankport nicht nur, um einen Vorfall bei einer privaten Verbindung zu umgehen.

Muss der Anwendungszugriff entfernt werden, löschen Sie das Binding und prüfen Sie, dass sein Engine-Prinzipal widerrufen ist. Muss die Datenbank selbst gelöscht werden, bestätigen Sie die Anforderungen an Backup und Aufbewahrung und verwenden Sie den Löschablauf für verwaltete Datenbanken, in dem Bewusstsein, dass ihr verwalteter Speicher entfernt wird. Halten Sie diese beiden Entscheidungen in der Änderungsfreigabe getrennt.

Diagnoseübersicht

Symptom	Zuerst prüfen	Ausführliche Anleitung
Datenbank erreicht nie Ready	Storage Node, Speicher-Vorabprüfung, Engine-Version, Bereitstellungs-Task	Verwaltete Datenbanken
Binding ist fehlerhaft	Datenbank, beide Nodes, Relay, die Verbindung des Bindings und die Engine-Identität	Anwendungs-Bindings für Datenbanken
Anwendung wird abgewiesen	Verbindungswerte, TLS-Modus und der Binding-spezifische Prinzipal	Datenbankbetrieb
Binding schlägt nach einem Node-Neustart fehl	Aktualität des Nodes und Abgleichsverlauf	Node-Updates und Offline-Verhalten
Direkter Zugriff ist erforderlich	Veröffentlichter TLS-Port und Netzwerkbeschränkungen	Ports und Netzwerkpfade