Benutzerdefinierte Domain und automatisches TLS auf Dockup

Eine Einrichtung mit benutzerdefinierter Domain und automatischem TLS besteht aus drei voneinander getrennten Ebenen: Der Dockup-Service muss verfügbar sein, DNS muss den Hostnamen auf die Plattform zeigen, und der Hostname muss verifiziert werden, bevor ein Zertifikat ausgestellt werden kann. Wenn Sie diese Ebenen getrennt betrachten, wird die Umstellung planbar und DNS-Fehler wirken nicht wie Fehler der Anwendung.

Dockup stellt jedem Service außerdem eine *.dockup.tech-Adresse bereit. Lassen Sie diese Adresse während der DNS-Propagation verfügbar, damit Sie die Anwendung unabhängig vom benutzerdefinierten Hostnamen testen können.

Was sollte vor dem Hinzufügen einer benutzerdefinierten Domain auf Dockup bereitstehen?

Beginnen Sie mit einem Service, der bereits läuft und seine Readiness-Prüfung besteht:

dockup status production/web --json
dockup health production/web --json

Öffnen oder testen Sie die vorhandene *.dockup.tech-URL. Wenn die Anwendung dort fehlschlägt, wird das Hinzufügen einer Domain das Problem nicht beheben. Prüfen Sie zuerst die Runtime-Logs.

Stellen Sie die folgenden Informationen zusammen:

Element	Beispiel	Warum es wichtig ist
Exaktes Ziel	production/web	Verhindert, dass die Domain dem falschen Service zugeordnet wird
Hostname	app.example.com	Der DNS-Name, den Benutzer aufrufen
DNS-Zugriff	Registrar oder DNS-Anbieter	Erforderlich, um den Eintrag anzulegen
Aktuelle TTL	300 Sekunden	Steuert Propagation und Geschwindigkeit eines Rollbacks
Kanonische URL der Anwendung	https://app.example.com	Kann Redirects und Cookies beeinflussen
Health-Route	/health	Bestätigt den Service vor der Umstellung

Senken Sie die bestehende DNS-TTL im Voraus, wenn Sie einen produktiven Anbieter ersetzen. Löschen Sie den alten Eintrag erst, wenn das Dockup-Ziel, die Anwendungskonfiguration und der Rollback-Plan feststehen.

Prüfen Sie das Anwendungsverhalten, das vom Host abhängt. Authentication-Callbacks, CORS-Allowlists, Cookie-Domains, OAuth-Redirect-URLs, Webhook-Ziele und generierte absolute Links müssen möglicherweise den neuen HTTPS-Hostnamen verwenden.

Wie fügen Sie die Domain hinzu und verifizieren sie?

Listen Sie zuerst die aktuellen Domains auf:

dockup domain list production/web --json

Fügen Sie den Hostnamen hinzu:

dockup domain add app.example.com production/web --json

Die Antwort enthält das DNS-Ziel, das konfiguriert werden muss. Legen Sie beim DNS-Anbieter den angegebenen CNAME-Eintrag an. Erfinden Sie keine IP-Adresse und kopieren Sie keinen Wert von einem anderen Service. Verwenden Sie das für diese Domain zurückgegebene Ziel.

Nachdem DNS propagiert wurde, verifizieren Sie die Domain mit der zurückgegebenen Domain-ID:

dockup domain verify <domainId> production/web --json

Die Verifizierung bestätigt, dass der öffentliche DNS-Eintrag wie erforderlich aufgelöst wird. Ein Fehler hat meistens eine von vier Ursachen:

1. Der Name des Eintrags ist falsch.
2. Das CNAME-Ziel ist falsch.
3. Ein alter, widersprüchlicher A-, AAAA- oder CNAME-Eintrag ist noch vorhanden.
4. Resolver-Caches haben den neuen Wert noch nicht übernommen.

Prüfen Sie das autoritative DNS, anstatt die Domain wiederholt zu entfernen und neu anzulegen. Propagation ist ein verteilter Cache-Prozess und kein Dockup-Build-Prozess.

Wie wird das HTTPS-Zertifikat ausgestellt und verwaltet?

Sobald die Verifizierung erfolgreich ist, fordern Sie das Zertifikat an:

dockup domain ssl <domainId> production/web --json

Dockup übernimmt die Zertifikatsausstellung für den verifizierten Hostnamen und stellt die benutzerdefinierte Domain über HTTPS bereit. Die Plattform verwaltet den TLS-Lifecycle. Der Application Container muss daher weder Zertifikatsdateien speichern noch einen Prozess zur Zertifikatserneuerung ausführen.

Validieren Sie das Ergebnis außerhalb der Plattform:

curl -I https://app.example.com

Bestätigen Sie, dass:

• Das Zertifikat zum Hostnamen passt.
• Die Antwort über HTTPS bereitgestellt wird.
• Redirects keine Schleife bilden.
• Die Anwendung den erwarteten Status zurückgibt.
• Authentication- und Callback-Flows den neuen Origin verwenden.
• Statische Assets ohne Mixed-Content-Fehler geladen werden.

Die Zertifikatsausstellung kann fehlschlagen, obwohl die Anwendung selbst fehlerfrei läuft. Halten Sie DNS- und Service-Diagnose getrennt. Verwenden Sie domain verify für die DNS-Inhaberschaft und Service-Logs für das Verhalten der Anwendung.

Der Artikel Zero-Downtime-Deployments erläutert die unabhängige Readiness-Prüfung für Releases.

Wie stellen Sie den Datenverkehr ohne Ausfall um?

Bei einer sicheren Umstellung bleibt der alte Pfad verfügbar, bis der neue Hostname erfolgreich geprüft wurde.

1. Stellen Sie den Dockup-Service bereit und verifizieren Sie ihn über seine Plattform-URL.
2. Fügen Sie die benutzerdefinierte Domain in Dockup hinzu.
3. Legen Sie den DNS-Eintrag an.
4. Verifizieren Sie DNS.
5. Stellen Sie TLS aus.
6. Testen Sie HTTPS direkt.
7. Aktualisieren Sie Callbacks, kanonische URLs und Monitoring.
8. Leiten Sie einen kleinen Teil des produktiven Datenverkehrs um, sofern die DNS-Konfiguration dies zulässt.
9. Beobachten Sie Logs und Uptime.
10. Deaktivieren Sie den alten Anbieter erst, wenn der neue Pfad stabil ist.

Die Uptime-Checks von Dockup laufen jede Minute und melden Statistiken zur Antwortzeit, einschließlich p95:

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

Behalten Sie für kritische Domains ein unabhängiges externes Monitoring bei. Ein Plattform-Probe bestätigt die öffentliche Erreichbarkeit, während ein externes Monitoring den Benutzerpfad von einem anderen System aus überprüft.

Wenn die benutzerdefinierte Domain einen aktuellen Produktions-Host ersetzt, dokumentieren Sie die Rollback-Daten: den vorherigen DNS-Wert, die vorherige TTL, den Status des alten Anbieters und die Bedingung, die eine Rückumstellung auslöst.

Wie funktionieren zusätzliche Port-Domains?

Ein Service kann einen zweiten HTTP-Port für eine Admin-Oberfläche, einen Metrics-Endpunkt oder einen weiteren Web-Prozess bereitstellen. Dockup kann dafür ohne benutzerdefiniertes DNS eine zusätzliche Plattform-Domain erstellen:

dockup port list production/web --json
dockup port add 8080 production/web --name admin --json

Die zurückgegebene Domain leitet Anfragen an den ausgewählten Container-Port weiter. Sie ist von der primären benutzerdefinierten Domain getrennt.

Machen Sie einen Port nicht allein deshalb öffentlich, weil ein Prozess darauf lauscht. Prüfen Sie, ob der Endpunkt Authentication bietet, ob er Produktionsdaten enthält und ob er überhaupt öffentlich erreichbar sein sollte. Eine nur intern gedachte Admin-Oberfläche sollte nicht aus Bequemlichkeit internetöffentlich werden.

Entfernen Sie eine nicht mehr benötigte Port-Domain über die unterstützte Domain-Schnittstelle erst, nachdem Sie überprüft haben, dass kein Monitor, Callback oder Operator-Workflow sie mehr verwendet. Änderungen an Port-Domains sind Mutationen und erscheinen im Audit-Log.

Wie beheben Sie Fehler bei DNS, TLS und der Anwendung?

Gehen Sie bei der Diagnose Ebene für Ebene vor:

Symptom	Erste Prüfung	Dockup-Befehl
Domain wird nicht aufgelöst	DNS-Eintrag und Propagation	domain verify
Zertifikat wird nicht ausgestellt	Status der Domain-Verifizierung	domain list, domain ssl
HTTPS funktioniert, aber die Anwendung meldet Fehler	Runtime-Logs	logs --json
Redirect-Schleife	Proxy-/Host-Einstellungen der Anwendung	env list, Runtime-Logs
Plattform-URL funktioniert, benutzerdefinierter Host nicht	DNS-/TLS-Ebene	Domain-Befehle
Beide URLs schlagen fehl	Deployment und Runtime	status, Build-/Runtime-Logs
Sekundärer Port schlägt fehl	Port-Domain-Zuordnung und Prozess	port list, Runtime-Logs

Prüfen Sie die Service-Ausgabe, ohne daraus DNS-Schlussfolgerungen abzuleiten:

dockup logs production/web --json
dockup status production/web --json

Wenn eine kürzlich vorgenommene Umgebungsänderung die kanonische URL ergänzt hat, denken Sie daran, dass dafür ein neues Deployment erforderlich ist:

dockup env set APP_URL=https://app.example.com \
  -s production/web \
  --json

dockup deploy production/web --wait --json

Der Leitfaden zu Umgebungsvariablen und Secrets beschreibt diesen Lifecycle.

Domain entfernen und Rollback

Das Entfernen der Dockup-Zuordnung ist für die Route destruktiv. Verschieben oder entfernen Sie daher zuerst den öffentlichen DNS-Eintrag und bestätigen Sie das gewünschte Ersatz-Ziel. Entfernen Sie die Zuordnung anschließend über die unterstützte Domain-Schnittstelle und verwenden Sie dabei exakt die Domain-ID.

Entfernen Sie die Domain bei einem vorübergehenden Zertifikats- oder Propagationsproblem nicht, sofern dies nicht für den Recovery-Plan erforderlich ist. Wenn die Konfiguration bestehen bleibt, kann die Verifizierung erfolgreich abgeschlossen werden, sobald die Caches aktualisiert sind.

Prüfen Sie Mutationen mit:

dockup audit --search domains --json

Der Audit-Trail sollte zeigen, wer den Hostnamen hinzugefügt, verifiziert, abgesichert oder entfernt hat.

Checkliste für die Übergabe an den Betrieb

Eine vollständige Übergabe für benutzerdefinierte Domain und automatisches TLS umfasst das Service-Ziel, den Hostnamen, die Domain-ID, Typ und Ziel des DNS-Eintrags, das Verifizierungsergebnis, das Zertifikatsergebnis, Änderungen an Application-Callbacks, die Monitoring-URL und den DNS-Wert für das Rollback.

Speichern Sie keinen privaten Zertifikatsschlüssel im Repository oder Container. Die verwaltete TLS-Grenze von Dockup gibt es genau deshalb, damit das Application-Team den Hostnamen betreiben kann, ohne Zertifikatsmaterial zu verteilen.

Verwenden Sie für alle aktuellen Flags die Dockup CLI-Referenz. Für das initiale Deployment vor der Domain-Konfiguration folgen Sie Vom Git-Repository in die Produktion.

Planen Sie Entscheidungen für Apex und Subdomains

Eine Subdomain wie app.example.com ist normalerweise der einfachste Hostname für eine Anwendung, da DNS-Anbieter sie mit einem CNAME darstellen können. Eine Apex-Domain wie example.com erfordert möglicherweise anbieterspezifisches Flattening oder Alias-Verhalten. Folgen Sie dem von Dockup zurückgegebenen DNS-Ziel und den Möglichkeiten des autoritativen DNS-Anbieters.

Wählen Sie einen kanonischen Host und leiten Sie alternative Hosts auf der Anwendungs- oder Routing-Ebene um. Wenn sowohl www als auch die Apex-Domain ohne eine Canonical Policy ausgeliefert werden, können Cookies, Analytics-Daten, Cache-Einträge und die Suchindexierung aufgeteilt werden.

Prüfen Sie die Annahmen zur Zertifikatserneuerung

Managed TLS macht es überflüssig, einen Renewal-Client im Container auszuführen. Der Hostname muss jedoch weiterhin korrekt aufgelöst werden. Eine spätere DNS-Migration, eine Proxy-Änderung oder ein gelöschter Eintrag kann die Validierung unterbrechen.

Nehmen Sie den Domain-Status in regelmäßige Prüfungen auf:

dockup domain list production/web --json
dockup uptime production/web --hours 24 --json

Das Runbook für benutzerdefinierte Domain und automatisches TLS sollte den DNS-Verantwortlichen, den Kontakt für die Erneuerung und das Datum der letzten externen Zertifikatsprüfung nennen. So müssen Zuständigkeiten nicht erst bei einem Zertifikatsvorfall ermittelt werden.

Schützen Sie Nicht-Produktions-Hostnamen

Staging- und Preview-Hostnamen können unfertige Funktionen und produktionsähnliche Daten offenlegen. Verwenden Sie bei Bedarf Application Authentication, legen Sie eine Indexierungsrichtlinie auf der Anwendungsebene fest und beschränken Sie die Weitergabe von Nicht-Produktions-URLs.

Anweisungen für Suchmaschinen sind keine Zugriffskontrolle. Eine geschützte Umgebung benötigt weiterhin Authentication und einen angemessenen Umgang mit Daten.

Prüfen Sie nach der Propagation erneut

Wiederholen Sie die externen HTTPS- und Callback-Tests, nachdem die ursprüngliche DNS-TTL vollständig abgelaufen ist.

Beginnen Sie mit einem verifizierbaren Deployment

Verknüpfen Sie zuerst einen nicht kritischen Hostnamen, behalten Sie die Plattform-URL während der Propagation bei und dokumentieren Sie den exakten DNS-Wert, der für ein Rollback benötigt wird.

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

FAQ

Welchen DNS-Eintrag benötigt eine benutzerdefinierte Domain auf Dockup?

Führen Sie dockup domain add aus und legen Sie den in der Antwort angezeigten DNS-Eintrag an. Verwenden Sie das zurückgegebene Ziel, anstatt einen Wert von einem anderen Service zu kopieren.

Wann kann Dockup TLS für eine benutzerdefinierte Domain ausstellen?

Nachdem der DNS-Eintrag des Hostnamens die Domain-Verifizierung von Dockup bestanden hat, fordern Sie die Zertifikatsausstellung mit dem dokumentierten domain ssl-Befehl an.

Muss mein Container TLS-Zertifikate speichern?

Nein. Dockup verwaltet TLS für die verifizierte benutzerdefinierte Domain. Der Application Container benötigt daher weder Zertifikatsdateien noch einen Prozess zur Erneuerung.

Kann Dockup einen zusätzlichen Container-Port bereitstellen?

Ja. Mit den Port-Befehlen kann für einen zusätzlichen öffentlichen Port eine separate automatisch generierte Domain erstellt werden, ohne dass benutzerdefiniertes DNS erforderlich ist.

Was sollte ich prüfen, wenn die Plattform-URL funktioniert, die benutzerdefinierte Domain aber fehlschlägt?

Konzentrieren Sie sich auf DNS-Einträge, Propagation, Domain-Verifizierung und Zertifikatsstatus. Die funktionierende Plattform-URL zeigt, dass die Anwendungsebene wahrscheinlich ordnungsgemäß arbeitet.