Managed PostgreSQL auf Dockup: Der vollständige Leitfaden

Managed PostgreSQL stellt einer Anwendung eine provisionierte Datenbank bereit, deren Lifecycle-Operationen vom Service-Container getrennt sind. Dockup unterstützt das Erstellen, Starten und Stoppen, Logs, die Größenprüfung, Backups, die Wiederherstellung über die Plattform, schreibgeschützte Benutzer, die Migration zwischen Nodes und private Netzwerke.

Das zentrale Betriebsprinzip ist die Trennung: Das Anwendungs-Image ist austauschbar, die PostgreSQL-Daten sind persistent, Zugangsdaten sind Secrets, und die Wiederherstellung der Datenbank muss unabhängig von einem Rollback der Anwendung getestet werden.

Wie erstellt man eine Managed-PostgreSQL-Datenbank?

Wählen Sie den vorgesehenen Workspace aus und erstellen Sie anschließend die Datenbank:

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Listen Sie die Datenbanken auf, um Slug und Status exakt zu bestätigen:

dockup db list --json

Datenbankoperationen verwenden Ziele im Format project/db:

dockup db size production/main-db --json

Warten Sie, bis das Provisioning abgeschlossen ist, bevor Sie eine Anwendung anbinden. Raten Sie Hostname, Port, Benutzername oder Passwort nicht anhand des Datenbanknamens.

Der Free-Tarif erlaubt drei Datenbanken in einem Workspace und umfasst ein Startguthaben von 10 $. Bezahlte Tarife – Hobby für 5 $, Pro für 20 $ pro Monat – erlauben unbegrenzt viele Datenbanken, Workspaces und Deployments. Der Verbrauch von CPU, RAM und Speicherplatz wird pro Minute mit dem enthaltenen Nutzungsguthaben verrechnet.

Wie verbindet man eine Anwendung sicher?

Rufen Sie die Verbindungsdaten der Datenbank über die Datenbankschnittstelle von Dockup ab und behandeln Sie den Connection String als Secret. Fügen Sie ihn weder in das Repository noch in das Agent-Transkript ein.

Setzen Sie ihn für den Service:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Das Redeploy ist erforderlich, weil der laufende Prozess seine Umgebung beim Start erhalten hat. Der gespeicherte Wert wird maskiert, wenn die Umgebungskonfiguration ausgelesen wird.

Konfigurieren Sie das Connection Pooling der Anwendung bewusst. Zu viele Application Worker mit großen Pools können die Datenbankverbindungen erschöpfen, selbst wenn CPU und Arbeitsspeicher unauffällig aussehen. Legen Sie die Pool-Größe anhand der Workload und der Datenbankkapazität fest, nicht anhand der maximalen Anzahl, die ein Framework akzeptiert.

Testen Sie nach dem Deployment eine neue Verbindung. Ein Health Endpoint kann bestätigen, dass der HTTP-Prozess aktiv ist, ohne nachzuweisen, dass eine neue Datenbanksitzung aufgebaut werden kann.

Der Leitfaden zu Umgebungsvariablen und Secrets behandelt die Rotation von Zugangsdaten und maskierte Ausgaben.

Wie schützt ein privates Netzwerk den PostgreSQL-Datenverkehr?

Aktivieren Sie ein privates Projektnetzwerk:

dockup network enable production --json

Services und verwaltete Datenbanken in diesem Projekt erhalten stabile Hostnamen im Format <slug>.internal. Führen Sie für die Anwendung ein Redeploy durch, damit sie die injizierten internen Verbindungsvariablen erhält.

Um den öffentlichen Listener der Datenbank zu entfernen und sie ausschließlich privat erreichbar zu machen:

dockup db private production/main-db --json

Stellen Sie bei Bedarf den öffentlichen und privaten Zugriff wieder her:

dockup db private production/main-db --off --json

Wenn Sie die Datenbank ausschließlich privat erreichbar machen, wird ihr Container neu erstellt, die Daten bleiben jedoch erhalten. Planen und überprüfen Sie diese Änderung als Datenbankoperation und nicht als harmlose DNS-Anpassung.

Private Netzwerke steuern den Übertragungsweg, während PostgreSQL-Zugangsdaten Identität und Berechtigungen kontrollieren. Behalten Sie beides bei. Separate Projekte können einander nicht erreichen, da jedes Projekt über ein eigenes Netzwerk verfügt.

Der Artikel zu privaten Netzwerken und internen Domains beschreibt die vollständige Topologie.

Wie funktionieren Backups und die Wiederherstellung von PostgreSQL?

Listen Sie vorhandene Backups auf:

dockup db backups production/main-db --json

Starten Sie ein serverseitiges Backup:

dockup db backup production/main-db --json

Der Backup-Befehl erstellt ein datenbankbewusstes Backup und keine Live-Kopie des Raw-Volumes. Dokumentieren Sie die Backup-ID, den Erstellungszeitpunkt, die Datenbankversion und den Grund.

Dockup unterstützt die Wiederherstellung von Backups verwalteter Datenbanken über die Plattform. Die aktuelle CLI-Referenz dokumentiert keinen Befehl dockup db restore; dieser Leitfaden erfindet daher keinen. Führen Sie die Wiederherstellung über die unterstützte Dockup-Schnittstelle durch, wählen Sie das exakte Backup aus, holen Sie die Freigabe für die Produktion ein und überprüfen Sie das Ergebnis.

Ein Wiederherstellungsplan sollte Folgendes enthalten:

1. Wiederherstellungspunkt und erwartetes Zeitfenster für verlorene Schreibvorgänge.
2. Schreibsperre der Anwendung oder Verhalten während der Wartung.
3. Kompatibilität von Datenbank und Extensions.
4. Ein aktuelles Backup, sofern sinnvoll.
5. Verantwortliche Person und Freigabe für die Wiederherstellung.
6. Wiederherstellung der Anwendungsverbindung und Smoke-Test.
7. Audit- und Incident-Dokumentation.

Backups sind erst dann verlässlich, wenn eine Wiederherstellungsübung erfolgreich war. Testen Sie das Verfahren mit einer Nicht-Produktionsdatenbank oder in einer freigegebenen Recovery-Umgebung.

Bewahren Sie Backups gemäß einer genehmigten Richtlinie auf. Entfernen Sie veraltete Recovery Points nur über die unterstützte Datenbankschnittstelle und erst, nachdem Sie überprüft haben, dass keine Recovery- oder Compliance-Anforderung mehr von ihnen abhängt.

Wie funktionieren schreibgeschützte PostgreSQL-Benutzer?

Zusätzliche schreibgeschützte Benutzer sind für Analytics, Support-Untersuchungen, Preview-Deployments und Tools nützlich, die Abfragen ausführen, aber keine Schreibvorgänge durchführen dürfen.

Listen Sie die Benutzer auf:

dockup db users production/main-db --json

Erstellen Sie einen Benutzer mit einem Label:

dockup db user-add production/main-db \
  --label analytics \
  --json

Sichern Sie die bei der Erstellung generierten Zugangsdaten während des Vorgangs und geben Sie sie nicht in einer Agent-Antwort aus. Entziehen Sie dem zusätzlichen Benutzer den Zugriff über die unterstützte Oberfläche zur Verwaltung von Datenbankbenutzern, sobald sein Zweck erfüllt ist.

Schreibschutz auf der Berechtigungsebene der Datenbank ist zuverlässiger, als einem Query-Tool zu sagen: „Nicht schreiben.“ Der Zugriff auf lesbare Produktionsdaten bleibt dennoch bestehen; daher gelten weiterhin Datenschutz- und Least-Privilege-Regeln.

Dockup erstellt für eine PR- oder Branch-Preview in einem Projekt mit privatem Netzwerk automatisch einen schreibgeschützten Datenbankbenutzer. Die Preview kann dieselbe Produktionsdatenbank unter <slug>.internal erreichen und Daten lesen, ohne Schreibberechtigungen zu erhalten.

Wie überwacht man Größe, Logs und Platzierung?

Prüfen Sie die Größe auf dem Datenträger:

dockup db size production/main-db --json

Prüfen Sie die Runtime-Logs der Anwendung auf Verbindungsfehler, ohne Passwörter oder vollständige Connection Strings offenzulegen:

dockup logs production/api --json

Datenbankwartung kann abhängige Services vorübergehend nicht verfügbar machen. Planen Sie zustandsverändernde Operationen, verlangen Sie eine ausdrückliche operative Freigabe und kommunizieren Sie die Auswirkungen vor der Durchführung.

Verschieben Sie eine Datenbank mit der ID eines Ziel-Nodes zwischen Nodes:

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

Eine Migration ist eine zustandsbehaftete Operation. Bestätigen Sie den Backup-Status, die Erwartungen an die Wartung, private Netzwerkverbindungen und die Prüfungen der Anwendung nach dem Verschieben.

Checkliste für Managed PostgreSQL in der Produktion

Ein vollständiges Runbook dokumentiert:

Bereich	Erforderlicher Nachweis
Identität	Exaktes Ziel project/db
Konnektivität	Geheimer Connection String und getestete neue Sitzung
Netzwerk	Richtlinie für öffentlichen, privaten oder ausschließlich privaten Zugriff
Zugriff	Anwendungsrolle und beschriftete schreibgeschützte Benutzer
Kapazität	Aktuelle Größe und Prüfung des Wachstums
Backups	Aktuelle Backup-IDs und Aufbewahrung
Recovery	Erfolgreiche Wiederherstellungsübung
Betrieb	Freigabe für Start, Stop, Neustart und Migration
Audit	Datenbankänderungen sind einer handelnden Person oder einem System zuordenbar

Ein Rollback des Anwendungs-Deployments stellt PostgreSQL nicht wieder her. Die Wiederherstellung der Datenbank führt nicht automatisch zu einem Rollback des Anwendungscodes. Koordinieren Sie beides nur dann, wenn die Schema-Kompatibilität dies erfordert.

Für umfassendere Entscheidungen zur Skalierung lesen Sie Strategien zur Datenbankskalierung. Für exakte Befehle verwenden Sie die Dockup-CLI-Referenz.

Schema-Migrationen für Deployment und Rollback entwerfen

Anwendungsdeployment und Änderung des Datenbankschemas erfolgen auf unterschiedlichen Zeitschienen. Eine sichere Migration ist normalerweise mindestens für ein Release-Fenster abwärtskompatibel: Fügen Sie zunächst eine nullable Spalte hinzu, deployen Sie Code, der mit beiden Schemata umgehen kann, führen Sie das Backfill kontrolliert durch und entfernen Sie die alte Struktur später.

Lassen Sie einen Health Check keine lang laufende Migration ausführen. Wenn die Anwendung mehrere Replicas startet, stellen Sie sicher, dass nur ein Migration Runner die Änderung ausführen darf. Der exec-Befehl des PRO-Containers kann einen einmaligen Befehl ausführen und seinen tatsächlichen Exit-Code weitergeben:

dockup exec "npm run migrate" \
  -s production/api \
  --json

Verwenden Sie ihn nur, wenn der Migrationsbefehl geprüft wurde und der Service auf dem unterstützten Main Server läuft. Erfassen Sie stdout, stderr und den Exit-Code. Ein erfolgreiches Application Deployment bedeutet nicht, dass eine fehlgeschlagene Migration ignoriert werden kann.

Datenbankzugangsdaten ohne Ausfall rotieren

Erstellen Sie die neuen Zugangsdaten oder den schreibgeschützten Benutzer, aktualisieren Sie das Secret des nutzenden Services, führen Sie ein Redeploy durch und überprüfen Sie eine neue Verbindung, bevor Sie die alten Zugangsdaten widerrufen. Bestehende Connection Pools können ein falsches neues Passwort verbergen, bis sie sich neu verbinden.

Verwenden Sie für die primären Zugangsdaten der Anwendung die unterstützte Dockup-Schnittstelle und die Richtlinie für die Datenbank. Erstellen Sie für einen zusätzlichen Analytics-Benutzer ein beschriftetes schreibgeschütztes Konto und geben Sie es nur an den freigegebenen Consumer weiter.

Der Rotationsnachweis sollte Benutzerlabel, nutzende Services, Deployment-IDs, Prüf-Query, Zeitpunkt des Widerrufs und das Audit-Event aufführen – niemals das Passwort.

Wachstum vor der Skalierung beobachten

Die Datenbankgröße ist ein Signal:

dockup db size production/main-db --json

Setzen Sie sie in Beziehung zur Query-Latenz der Anwendung, zur Anzahl der Verbindungen, zum Cache-Verhalten, zur Backup-Dauer und zum Speicherwachstum. Eine größere CPU- oder RAM-Zuweisung behebt möglicherweise keine fehlenden Indizes oder unbeschränkten Queries.

Lesen Sie vor dem Verschieben von Nodes oder dem Erhöhen von Ressourcen Strategien zur Datenbankskalierung. Managed PostgreSQL reduziert den Provisioning-Aufwand, aber das Design von Schema und Queries bleibt in der Verantwortung der Anwendung.

Verfügbarkeit und Korrektheit getrennt betrachten

Ein laufender Datenbank-Container belegt, dass PostgreSQL verfügbar ist, nicht aber, dass die Queries der Anwendung korrekt funktionieren. Nehmen Sie in die Prüfung nach dem Deployment eine risikoarme neue Verbindung und einen repräsentativen Lesezugriff auf. Verwenden Sie für einen Schreibtest eine eigene Transaktion oder einen Testdatensatz, der sicher entfernt werden kann.

Das Runbook für Managed PostgreSQL sollte außerdem festhalten, ob Replicas, Analytics-Benutzer, Previews oder Background Worker zusätzlichen Verbindungsdruck erzeugen.

PostgreSQL-Zugriff regelmäßig überprüfen

Listen Sie zusätzliche Benutzer auf, bestätigen Sie, dass jedes Label einen aktiven Verantwortlichen hat, und entfernen Sie veraltete Konten. Diese einfache Überprüfung verhindert, dass sich der Lesezugriff auf Managed PostgreSQL nach dem Ende von Previews, Analytics-Projekten oder Support-Untersuchungen ansammelt.

Mit einem überprüfbaren Deployment beginnen

Erstellen Sie eine PostgreSQL-Datenbank für Nicht-Produktionszwecke, verbinden Sie einen Test-Service über ein maskiertes Secret, erstellen Sie ein Backup und führen Sie vor dem Produktions-Cutover eine Wiederherstellungsübung durch.

Jetzt kostenlos auf app.dockup.ai starten. Der Free-Tarif kostet 0 $ pro Monat, umfasst ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Welche Typen verwalteter Datenbanken unterstützt Dockup?

Dockup unterstützt verwaltete Datenbanken auf Basis von PostgreSQL, MySQL, MongoDB und Redis.

Wie sollte eine Anwendung ihren PostgreSQL-Connection-String erhalten?

Behandeln Sie den Connection String als Secret-Umgebungsvariable, setzen Sie ihn für den exakten Service und führen Sie ein Redeploy durch, damit der neue Container ihn erhält.

Kann Dockup einen schreibgeschützten PostgreSQL-Benutzer erstellen?

Ja. Der Befehl user-add für die Datenbank erstellt einen zusätzlichen schreibgeschützten Benutzer und gibt dessen Passwort bei der Erstellung einmalig zurück.

Gibt es einen dokumentierten CLI-Befehl dockup db restore?

Die aktuelle CLI-Referenz dokumentiert keinen solchen Befehl. Dockup unterstützt die Wiederherstellung von Backups über die Plattformschnittstelle. Verwenden Sie daher diesen unterstützten Weg, anstatt ein Flag oder einen Befehl zu erfinden.

Wird die PostgreSQL-Datenbank durch ein Application Rollback wiederhergestellt?

Nein. Die Deployment-Historie der Anwendung und die Backup-Historie der Datenbank sind getrennte Recovery-Systeme und müssen koordiniert werden, wenn Schemaänderungen beides erfordern.