Eine Anwendung vollständig veröffentlichen

Dieser Ablauf bringt ein freigegebenes Anwendungsartefakt bis zu einem öffentlichen HTTPS-Endpunkt: den Workload, seinen Health Check, die Domain und das TLS-Zertifikat, die Route und den Abnahmetest.

Das Ziel ist ein Dienst, der aus Benutzersicht fehlerfrei läuft, über die vorgesehene Domain erreichbar ist, in Opfield beobachtbar ist, durch die erwartete Zugriffsrichtlinie geschützt ist und sich zurücksetzen lässt, ohne die Control Plane neu aufzubauen.

Wenn dies Ihr erstes Deployment ist, bereiten Sie einen Docker Node vor, lesen Sie die Docker-Ressourcenmodelle und halten Sie Ihre erste Route veröffentlichen für den Ingress-Schritt geöffnet.

Das Workload-Modell festlegen

Wählen Sie die Ressource, die zur Zuständigkeit für den Lebenszyklus passt:

• Verwenden Sie einen Container für einen einfachen eigenständigen Dienst, bei dem der Austausch eine ausdrückliche Neuerstellung ist.
• Verwenden Sie ein Deployment, wenn ein Blue/Green-Rollout mit Health Checks und ein vorgehaltener Rollback-Slot erforderlich sind.
• Verwenden Sie ein Compose-Projekt, wenn mehrere Dienste, Netzwerke und Volumes eine Anwendung bilden und gemeinsam einen Lebenszyklus unveränderlicher Revisionen durchlaufen müssen.

Bilden Sie eine Anwendung aus mehreren Diensten nicht als unabhängige eigenständige Container ab, nur damit jedes untergeordnete Objekt direkt bearbeitbar ist. Das verwirft die Projektzuständigkeit und erschwert die Nachvollziehbarkeit von Rollback, Abweichungen und abhängigen Änderungen.

Geben Sie vor dem Fortfahren den genauen Image-Digest oder Git-Commit, die erwarteten Ressourcenlimits, die Quellen der Secrets, die Backup-Richtlinie für Volumes, Datenbankabhängigkeiten, den Health-Endpunkt, den öffentlichen Hostnamen und das Rollback-Ziel frei.

1. Kapazität und Zuständigkeit vorbereiten

Registrieren oder wählen Sie einen Docker Node, der online ist, für den Workload und einen Ingress Node, der online ist, für den öffentlichen Datenverkehr. Bestätigen Sie, dass jeder Node die richtige Rolle, eine kompatible Version, die benötigten Fähigkeiten und ausreichend Reserven hat. Ein grüner Node-Zustand beweist nicht, dass ein großes Image auf die Festplatte passt oder ein angeforderter Port verfügbar ist.

Vergeben Sie die Scopes vor dem Release. Der Entwickler benötigt möglicherweise Einblick in Quelle und Build, der Plattform-Operator Zugriff auf den Lebenszyklus des Workloads und der Ingress-Operator Zugriff auf Routen. Vergeben Sie nicht die Rolle des Systemadministrators, nur weil der Ablauf mehrere Ressourcentypen umfasst.

Bestätigen Sie bei zustandsbehafteten Workloads, wo persistente Daten liegen und wie sie wiederhergestellt werden. Ein Rollback eines Deployments ändert die Anwendungslaufzeit; es macht weder Schreibvorgänge in der Datenbank rückgängig noch repariert es ein Volume, das die neue Version verändert hat.

2. Den Workload erstellen oder verbinden

Erstellen Sie den gewählten Container, das Deployment oder das Compose-Projekt. Konfigurieren Sie den unveränderlichen Image-Digest oder die freigegebene Git-Quelle, den Befehl, die Umgebung, geschützte Secrets, das Neustartverhalten, Ressourcenlimits und verwaltete Volumes.

Bevorzugen Sie verwaltete Volumes oder ausdrücklich freigegebenen externen Speicher. Host-Bind-Mounts binden den Workload an einen Host und sind über normale Archiv- oder Migrationsabläufe nicht portierbar. Legen Sie Secrets nicht in gewöhnliche Umgebungswerte, Compose-Quellen, Build-Argumente oder Image-Labels.

Verwendet die Anwendung eine Datenbank, erstellen Sie das Binding vor der abschließenden Release-Prüfung, damit dieselbe Laufzeitkonfiguration getestet wird. Ein verwaltetes Binding gibt dem Workload eine eigene Datenbankidentität und kann eine normale Neuerstellung oder einen Rollout erfordern, um seine Umgebung und sein privates Netzwerk anzuwenden.

3. Den Zustand der Anwendung vor öffentlichem Datenverkehr nachweisen

Definieren Sie den Health-Zustand in für Benutzer relevanten Begriffen. Ein vorhandener Prozess oder ein TCP-Port, der Verbindungen annimmt, ist ein schwächerer Beleg als ein HTTP-Endpunkt, der bestätigt, dass die Anwendung und ihre kritischen Abhängigkeiten bereit sind.

Konfigurieren Sie bei einem Deployment den Health-Pfad, den erwarteten Statusbereich, eine optionale Prüfung des Antwortinhalts, Timeout, Intervall und Schwelle für langsame Antworten. Halten Sie den vorherigen Slot verfügbar, bis der neue Slot den Health Check und die externe Prüfung bestanden hat. Prüfen Sie bei einem Container oder Compose-Dienst den tatsächlichen Laufzeitzustand, die Logs und die Antwort der Anwendung, bevor Sie die öffentliche Route erstellen.

Leiten Sie keinen Produktionsverkehr an eine Anwendung, die noch Daten migriert, sofern die Migrationsstrategie dies nicht ausdrücklich unterstützt. Lang laufende oder destruktive Migrationen benötigen einen eigenen Rollback- und Kompatibilitätsplan.

4. Domain und TLS vorbereiten

Erstellen oder wählen Sie die Domain, platzieren Sie sie auf dem vorgesehenen Ingress Node und stellen Sie sicher, dass autoritatives DNS auf dessen öffentliche Dienstadresse zeigt. Stellen Sie ein Zertifikat aus, importieren oder wählen Sie eines, das den genauen Hostnamen oder einen passenden Wildcard abdeckt.

Getrennte Zuständigkeiten helfen hier: Eine DNS-Änderung sollte keine Änderung am Workload erfordern, und ein Rollback des Workloads sollte keinen Austausch des Zertifikats erfordern. Bestätigen Sie, wer hochgeladene Zertifikate verlängert und wer Ablaufbenachrichtigungen erhält.

5. Die Route erstellen

Erstellen Sie eine Route für die Domain und wählen Sie den verwalteten Workload als Upstream. Bei einem Docker-Container, einem Compose-Dienst oder einem Deployment kann Opfield einen Secure Link herstellen, sodass der Ingress den Workload über Relay erreicht, ohne nur für diesen Pfad einen Anwendungsport auf dem Host zu veröffentlichen.

Wählen Sie den Anwendungsport und das Upstream-Schema, die der Workload tatsächlich bedient. Aktivieren Sie öffentliches TLS und bei Bedarf Force HTTPS. Aktivieren Sie WebSockets, Präfixverhalten, Änderungen an der Pufferung, benutzerdefinierte Timeouts oder benutzerdefinierte Vorlagen nur, wenn der Vertrag der Anwendung sie erfordert; jede Ausnahme vergrößert die Fläche, die getestet werden muss.

Warten Sie, bis der Abgleich der Route und der Ingress-Konfiguration erfolgreich abgeschlossen ist. Bearbeiten Sie die generierte nginx-Konfiguration nicht direkt: Opfield ist die maßgebliche Quelle und gleicht den verwalteten Zustand ab.

6. Abnahmetest

Benutzerpfad

• DNS wird aus einem externen Netzwerk korrekt aufgelöst.
• TLS ist vertrauenswürdig und deckt den Hostnamen ab.
• Die Hauptseite oder der API-Endpunkt liefert das erwartete Release.
• Anmeldung, Callbacks, Uploads, Streaming und WebSockets funktionieren, sofern verwendet.
• Wartungs- und Zugriffsverweigerungsantworten sind beabsichtigt und wie erwartet gestaltet.

Plattformpfad

• Der Workload meldet den freigegebenen Digest oder Commit.
• Laufzeitzustand, Logs und Ressourcennutzung sind stabil.
• Health-Zustand der Route und Secure-Link-Laufzeit sind fehlerfrei.
• Access- und Error-Logs des Ingress zeigen die Abnahmeanfragen ohne wiederholte Upstream-Fehler.
• Ein Neustart des Workloads verliert weder persistente Daten noch die Binding-Konfiguration.
• Benachrichtigungen erreichen bei einem kontrollierten Testereignis die erwartete zuständige Person.

Governance-Pfad

• Benutzer mit minimalen Rechten können nur ihre zugewiesenen Ressourcen betreiben.
• Das Release, die Routenänderung und zugehörige Operationen erscheinen unter Tasks bzw. der jüngsten Aktivität und im Audit-Verlauf.
• Die Backup-Abdeckung umfasst zustandsbehaftete Volumes und externe Abhängigkeiten, nicht nur die Container-Definition.

7. Rollback und Grenze zum Vorfall

Halten Sie vor der Übernahme das letzte bekannt fehlerfreie Ziel fest. Prüfen Sie bei einem Deployment, dass der vorherige Slot fehlerfrei bleibt. Bewahren Sie bei einem Container den vorherigen unveränderlichen Image-Digest und die Konfiguration. Bewahren Sie bei Compose die vorherige unveränderliche Revision. Bewahren Sie bei Git-Auslieferung den freigegebenen Build und den genauen Quell-Commit.

Schlägt das Release fehl, während der Ingress fehlerfrei ist, setzen Sie den Workload zurück, statt die Domain, das Zertifikat oder die Route zu löschen. Verwenden Sie die Wartung der Route, wenn der Datenverkehr gestoppt werden muss, während Ressource und Konfiguration erhalten bleiben. Hat eine Migration bereits Daten verändert, ist ein Rollback nur der Anwendung möglicherweise unsicher; folgen Sie dem Plan zur Datenwiederherstellung.

Wiederholen Sie nach dem Rollback die Tests aus Benutzersicht und prüfen Sie die Logs auf Anfragen, die die fehlerhafte Revision erreicht haben könnten. Bewahren Sie das fehlerhafte Artefakt und die Belege der Operation auf, bis die Nachbetrachtung des Vorfalls abgeschlossen ist.

Diagnoseübersicht

Symptom	Zuerst prüfen	Ausführliche Anleitung
Workload wird nie bereit	Zugehöriger Task, Anwendungslogs, Port und Health Check	Docker-Übersicht
Route wird nicht veröffentlicht	DNS, TLS, nginx-Anwendung, Health-Zustand der Route und Upstream	Fehlerbehebung beim Ingress
Secure Link ist nicht verfügbar	Beide Nodes, Relay, Ziel-Workload und Connector-Operation	Sichere Upstreams
Neues Release ist fehlerhaft	Den zuständigen Workload zurücksetzen; die Route unverändert lassen	Blue/Green-Deployments
Migration hat Daten verändert	Schreibzugriffe stoppen und dem separaten Plan zur Datenwiederherstellung folgen	Updates und Backups