Private Networking und .internal-Domains auf Dockup

Private Networking ermöglicht die Kommunikation zwischen Services und verwalteten Datenbanken innerhalb eines Dockup-Projekts, ohne dass Datenverkehr innerhalb desselben Projekts über das öffentliche Internet geleitet wird. Jede Ressource erhält einen stabilen Hostnamen im Format <slug>.internal, während separate Projekte voneinander isoliert bleiben.

Das Netzwerk ist optional. Wenn Sie es aktivieren, werden bestehende Ressourcen des Projekts verbunden, ohne dass der Anwendungsdatenverkehr sofort umgestellt werden muss. Nach einem erneuten Deployment erhalten Services interne Verbindungsvariablen.

Wie reduziert Service-to-Service-Networking die öffentliche Angriffsfläche?

Ein öffentlicher Datenbank-Endpunkt ist aus dem Internet erreichbar, selbst wenn die Authentifizierung eine unbefugte Nutzung verhindert. Eine private Route beseitigt diese Angriffsfläche für den Anwendungsdatenverkehr und stellt Services einen stabilen internen Namen bereit, der nicht von einer öffentlichen Adresse abhängt.

Dasselbe Prinzip gilt für Aufrufe zwischen Services. Eine API kann einen Worker, einen internen Admin-Service oder ein Backend über das Projektnetzwerk aufrufen, statt dafür eine öffentliche Custom Domain zu verwenden.

Datenverkehrspfad	Öffentliche Route	Private Route
API zu PostgreSQL	Öffentlicher Host und Port	main-db.internal
Web zu API	Öffentliche Custom Domain	api.internal
Worker zu Redis	Öffentlicher Host und Port	app-redis.internal
Preview zur Produktionsdatenbank	Öffentliche Datenbank-Credentials	Interner schreibgeschützter Benutzer
Aufruf zwischen Projekten	Öffentlicher Endpunkt erforderlich	Durch Projektisolierung blockiert

Private bedeutet nicht unauthentifiziert. Verwenden Sie weiterhin Datenbankbenutzer, Service-Autorisierung und Secrets. Das Netzwerk bestimmt die Erreichbarkeit, Credentials bestimmen die Berechtigungen.

Wie aktivieren Sie Private Networking für ein Projekt?

Aktivieren Sie das Netzwerk für den Projekt-Slug:

dockup network enable production --json

Der Vorgang verbindet Services und verwaltete Datenbanken mit dem Projektnetzwerk. Bestehende öffentliche Listener bleiben standardmäßig verfügbar, sodass die Umstellung schrittweise erfolgen kann.

Führen Sie für jeden Anwendungs-Service, der interne Umgebungsvariablen erhalten soll, ein erneutes Deployment durch:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup injiziert Verbindungsdaten wie DATABASE_URL_INTERNAL, datenbankspezifische interne URL- und Host-Variablen sowie Host-/Port-Werte von Services. Lassen Sie sich die Environment-Keys des Services anzeigen, ohne Secrets offenzulegen:

dockup env list -s production/api --json

Erstellen Sie eine URL nicht manuell aus einem Anzeigenamen. Die Resource-Slugs bestimmen den Hostnamen <slug>.internal.

Prüfen Sie vor der Änderung der Anwendungskonfiguration, ob sich jede Abhängigkeit im selben Projekt befindet. Separate Projekte verfügen über separate Netzwerke und können einander über den internen Pfad weder auflösen noch erreichen.

Wie verändern .internal-Domains die Service-Konfiguration?

Internes DNS stellt einen stabilen Namen bereit, während sich Container und Nodes im Hintergrund ändern. Ein API-Service mit dem Slug api ist von Services im selben Projekt unter api.internal erreichbar; eine Datenbank mit dem Slug main-db ist unter main-db.internal erreichbar.

Bevorzugen Sie die injizierten Verbindungsvariablen, sofern diese verfügbar sind. Sie enthalten das korrekte Protokoll, die Credentials, den Datenbanknamen und das Host-Format. Ein manuell erstellter String kann TLS, die Kodierung des Passworts oder Datenbankparameter auslassen.

Migrieren Sie jeweils eine Abhängigkeit:

1. Aktivieren Sie das Netzwerk.
2. Führen Sie für den aufrufenden Service ein erneutes Deployment durch.
3. Bestätigen Sie, dass die interne Variable vorhanden ist.
4. Ändern Sie die Anwendung so, dass sie diese Variable verwendet.
5. Führen Sie das Deployment mit --wait aus.
6. Überprüfen Sie neue Verbindungen.
7. Beobachten Sie Runtime-Logs und Antwortzeit.
8. Fahren Sie mit der nächsten Abhängigkeit fort.

Ein Service kann seine öffentliche Custom Domain für Benutzerzugriffe behalten und gleichzeitig private Hostnamen für Backend-Aufrufe verwenden. Öffentliche und private Pfade dienen unterschiedlichen Vertrauensgrenzen.

Der Leitfaden zu Umgebungsvariablen und Secrets erläutert, warum Änderungen an Verbindungen ein erneutes Deployment erfordern.

Wie machen Sie eine verwaltete Datenbank ausschließlich privat erreichbar?

Nachdem alle erforderlichen Consumer den internen Pfad verwenden, entfernen Sie den öffentlichen Listener:

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

Dieser Datenbankvorgang erstellt den Container neu, während die Daten erhalten bleiben. Planen Sie ein für die Workload geeignetes Wartungsfenster, bestätigen Sie ein aktuelles Backup und testen Sie die erneute Verbindung der Anwendung.

Prüfen Sie vor der Umstellung auf ausschließlich privaten Zugriff:

• Jeder Produktions-Service, der die Datenbank verwendet, befindet sich im selben Projekt.
• Betriebliche Tools benötigen den öffentlichen Endpunkt nicht.
• Der Zugriff von Previews erfolgt über den unterstützten privaten Pfad.
• Ein Backup ist vorhanden und die Wiederherstellung ist bekannt.
• Connection Pools führen bei Fehlern sicher neue Verbindungsversuche durch.
• Das genaue Ziel project/db ist dokumentiert.

Eine ausschließlich private Datenbank kann von einem Operator-Laptop aus nicht direkt über das öffentliche Internet erreicht werden. Verwenden Sie die unterstützten Plattformzugriffe und Diagnosen auf Anwendungsebene, statt den Listener unüberlegt wieder zu öffnen.

Weitere Informationen zu Datenbankvorgängen finden Sie unter Managed PostgreSQL.

Wie greifen PR-Previews sicher auf Produktionsdaten zu?

Jede Dockup-PR- oder Branch-Preview erhält ein eigenes isoliertes Deployment und eine eigene URL. In einem Projekt mit Private Networking tritt die Preview dem Projektnetzwerk bei und kann <slug>.internal auflösen.

Dockup erstellt automatisch einen schreibgeschützten Benutzer für die verwaltete Produktionsdatenbank, die von der Preview verwendet wird. Die Preview kann Daten in produktionsnaher Form abfragen, aber über diesen Benutzer keine Schreibvorgänge ausführen.

Dieses Design verringert das Risiko, dass ein Feature-Branch Kundendatensätze ändert. Der Lesezugriff hat jedoch weiterhin Konsequenzen:

• Personenbezogene oder sensible Daten können in der Preview erscheinen.
• Neuer Anwendungscode kann abgefragte Daten loggen.
• Eine verwundbare Preview-URL kann abgefragte Ergebnisse offenlegen.
• Aufwendige Abfragen können die Produktionslast beeinflussen.
• Schema-Annahmen können zwischen Branch und Produktion abweichen.

Aktivieren Sie Preview-Deployments nur auf Grundlage einer geprüften Richtlinie:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Verwenden Sie die isolierte Umgebung der Preview für Feature Flags und Secrets, die nicht zur Datenbank gehören. Ersetzen Sie die automatisch bereitgestellten schreibgeschützten Credentials nicht durch die Credentials mit Schreibzugriff auf die Produktion.

Wie sollten Sie Private Networking überwachen und Fehler beheben?

Beginnen Sie mit Topologie und Konfiguration, statt von einem Plattformausfall auszugehen.

Symptom	Wahrscheinlicher Bereich	Prüfung
Name nicht gefunden	Falscher Slug bzw. falsches Projekt oder Service nicht erneut deployed	Service-Liste und Env-Keys
Verbindung abgelehnt	Ressource gestoppt oder falscher Port	Status sowie Datenbank-/Service-Logs
Authentifizierung fehlgeschlagen	Falsche Credentials	Secret-Rotation und Benutzer
Öffentlich funktioniert, privat nicht	Interne Variable oder Umstellung auf das Netzwerk	Netzwerk aktivieren, erneutes Deployment
Preview kann lesen, aber nicht schreiben	Erwartete schreibgeschützte Richtlinie	Credentials nicht ersetzen
Aufruf zwischen Projekten schlägt fehl	Erwartete Isolierung	Öffentliche authentifizierte API verwenden

Untersuchen Sie die Runtime-Logs der Anwendung:

dockup logs production/api --json

Prüfen Sie Datenbankgröße und Verbindungsfehler der Anwendung:

dockup db size production/main-db --json
dockup logs production/api --json

Geben Sie vollständige interne Verbindungs-URLs nicht in Incident-Notizen aus. Sie können Credentials enthalten, auch wenn der Hostname selbst kein Secret ist.

Migrations- und Rollback-Plan

Lassen Sie den öffentlichen Listener in der ersten Phase aktiviert. Wenn das interne Deployment fehlschlägt, stellen Sie die vorherige Konfiguration der Anwendung wieder her und führen Sie ein erneutes Deployment durch. Machen Sie die Datenbank erst ausschließlich privat erreichbar, wenn der interne Pfad stabil funktioniert.

Um das gesamte Projektnetzwerk zu deaktivieren:

dockup network disable production --json

Dies sollte ein bewusst geplantes Rollback sein, nicht der erste Schritt bei der Fehlerbehebung. Das Deaktivieren des Netzwerks betrifft jede verbundene Ressource im Projekt.

Dokumentieren Sie Änderungen am Netzwerk über das Audit-Log:

dockup audit --writes --json

Checkliste für Private Networking in der Produktion

Ein vollständiges Runbook für Private Networking enthält den Projekt-Slug, Service- und Datenbank-Slugs, interne Hostnamen, Namen injizierter Variablen, die Richtlinie für öffentliche Listener, die Richtlinie für Preview-Zugriff, den Backup-Status, die Reihenfolge der erneuten Deployments und den Rollback-Pfad.

CPU, RAM und Speicherplatz werden weiterhin nutzungsbasiert und minutengenau abgerechnet; privates Routing ist eine Architekturentscheidung und keine feste Instance-Klasse. Verwenden Sie PaaS-Preise erklärt für die Kostenmodellierung.

Die Dockup CLI-Referenz enthält die aktuellen Netzwerk- und Datenbankbefehle. Informationen zur allgemeinen Isolierung von Deployments finden Sie unter Best Practices für Sicherheit.

Service-Autorisierung getrennt von Erreichbarkeit modellieren

Ein interner Hostname beweist nur, dass der Aufrufer sich im Projektnetzwerk befindet. Er beweist nicht, welcher Service die Anfrage gestellt hat oder ob dieser Service die Aktion ausführen darf. Behalten Sie die Authentifizierung auf Anwendungsebene für sensible interne APIs und Datenbank-Credentials für den Datenzugriff bei.

Verwenden Sie Service-spezifische Secrets statt eines gemeinsamen internen Tokens. Wenn eine Preview schreibgeschützten Datenbankzugriff erhält, geben Sie ihr nicht zusätzlich ein Produktions-Service-Token, das über eine API Schreibvorgänge auslösen kann.

Auswirkungen der Umstellung messen

Vergleichen Sie Verbindungslatenz, Fehlerrate und p95-Antwortzeit vor und nach der Umstellung auf interne Endpunkte. Das primäre Ziel sind Isolierung und ein stabiler privater Pfad; eine mögliche Verbesserung der Latenz sollte gemessen und nicht versprochen werden.

dockup uptime production/api --hours 24 --json

Bewahren Sie das Beobachtungsfenster und die Deployment-ID auf. Dadurch erhält die Änderung am Private Networking ein messbares Abschlusskriterium und endet nicht bei „DNS wurde aufgelöst“.

Ausnahme für den öffentlichen Pfad dokumentieren

Manche externe Integration, manche Operator-Tools oder manche Services aus anderen Projekten benötigen möglicherweise weiterhin einen öffentlichen Endpunkt. Listen Sie jede Ausnahme, ihre Authentifizierung, den Verantwortlichen und die Bedingung für ihre Entfernung auf. So bleibt der öffentliche Listener nicht dauerhaft aktiv, nur weil sich niemand mehr an den Grund dafür erinnert.

Ein vollständiger Rollout von Private Networking kann schrittweise erfolgen, aber jeder öffentliche Pfad sollte bewusst eingerichtet sein.

Interne Abhängigkeiten nach Umbenennungen prüfen

Eine Umbenennung oder ein Austausch einer Ressource kann den für die .internal-Adressierung verwendeten Slug ändern. Erfassen Sie vor einer Umbenennung alle Consumer, führen Sie mit den aktualisierten injizierten Variablen für sie ein erneutes Deployment durch und überprüfen Sie jede private Verbindung.

So bleibt Private Networking stabil, während sich das Projekt weiterentwickelt.

Mit einem überprüfbaren Deployment beginnen

Aktivieren Sie das Netzwerk in einem Nicht-Produktionsprojekt, migrieren Sie eine Abhängigkeit auf ihren .internal-Endpunkt und weisen Sie den Rollback-Pfad nach, bevor Sie einen öffentlichen Listener entfernen.

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

FAQ

Welchen Hostnamen verwenden Dockup-Ressourcen im privaten Netzwerk?

Jeder Service und jede verwaltete Datenbank im selben Projekt ist über einen stabilen Hostnamen im Format <slug>.internal erreichbar.

Entfernt die Aktivierung von Private Networking den öffentlichen Datenbankzugriff?

Nein. Das Netzwerk wird standardmäßig zusätzlich aktiviert. Verwenden Sie den separaten Datenbankbefehl für den privaten Zugriff, um den öffentlichen Listener zu entfernen, nachdem die Consumer den internen Pfad verwenden.

Können verschiedene Dockup-Projekte einander privat erreichen?

Nein. Jedes Projekt verfügt über ein isoliertes Netzwerk. Die Kommunikation zwischen Projekten muss daher eine geeignete öffentliche und authentifizierte Schnittstelle verwenden.

Kann eine PR-Preview in die Produktionsdatenbank schreiben?

In einem Projekt mit Private Networking stellt Dockup für die Preview automatisch einen schreibgeschützten Datenbankbenutzer bereit. Dadurch sind Lesezugriffe möglich, Schreibvorgänge über diese Credentials jedoch nicht.

Warum müssen Services nach der Aktivierung des Netzwerks erneut deployed werden?

Durch das erneute Deployment erhält der neue Container die internen Verbindungsvariablen, sodass die Anwendung mit der Konfiguration für den privaten Endpunkt starten kann.