Blue/Green-Deployments

Ein Deployment besitzt eine stabile Anwendungsidentität und zwei Laufzeit-Slots. Opfield bereitet ein neues Release im inaktiven Slot vor, bewertet seinen Health-Zustand und schaltet den Datenverkehr erst um, wenn das Release bereit ist. Der zuvor aktive Slot bleibt als Rollback-Kandidat verfügbar, bis er vom Lebenszyklus des Deployments außer Betrieb genommen wird.

Verwalten Sie Slots über das Deployment statt als einzelne Container. Das Deployment ist für die Umschaltung des Datenverkehrs, den Release-Verlauf, die Rollback-Fähigkeit und die Beziehung zwischen den beiden untergeordneten Laufzeiten zuständig. Ein direktes Bearbeiten eines aktiven untergeordneten Objekts erzeugt Zustandsabweichungen und schwächt die Garantien, die ein Rollback sicher machen.

Was die Entscheidung für ein Deployment ändert

Wählen Sie ein Deployment, wenn das Release-Risiko vor allem vom Start und Health-Zustand der Anwendung abhängt und wenn zwei Release-Slots während der Umschaltung sicher auf demselben Docker Node existieren können. Das Ergebnis ist eine stabile Dienstidentität mit kontrollierter Übernahme und einem ausdrücklichen Rollback-Kandidaten. Das ist besonders nützlich für öffentliche oder gemeinsam genutzte Dienste, bei denen der direkte Austausch eines Containers vermeidbare Ausfallzeiten verursachen würde.

Das Anwendungsteam ist für die Release-Bereitschaft, die Semantik des Health-Zustands, die Kompatibilität von Datenmigrationen und die Entscheidung über Übernahme oder Rollback zuständig. Das Plattformteam ist für Node-Kapazität, Image-Vertrauen, Routen, die Bereitstellung von Secrets und die Verfügbarkeit des Rollback-Wegs zuständig. Opfield koordiniert die Slots und erfasst die Operation; es kann eine inkompatible Schemaänderung nicht umkehrbar machen.

Verwenden Sie Blue/Green nicht als Ersatz für eine Datenstrategie. Beide Slots können vorübergehend auf dieselbe externe Abhängigkeit oder dieselben persistenten Daten zugreifen. Datenbankmigrationen müssen für das Rollback-Fenster abwärtskompatibel sein, oder der Release-Plan muss ausdrücklich akzeptieren, dass ein Rollback nur der Laufzeit nicht ausreicht.

Voraussetzungen

Verwenden Sie einen unveränderlichen Image-Digest oder ein freigegebenes Build-Artefakt. Bestätigen Sie vor dem Start eines Releases, dass der Ziel-Node online ist, das Image bezogen werden kann, Secrets und Volumes korrekt sind, die Ressourcenlimits auf den Node passen und die Health-Route den Anwendungspfad prüft, der für Benutzer wichtig ist. Prüfen Sie abhängige Routen und Datenbank-Bindings als Teil derselben Änderung.

Eine neue Version veröffentlichen

1. Öffnen Sie das Deployment und bereiten Sie das neue Image und die Konfiguration vor.
2. Prüfen Sie die Release-Eingabe, einschließlich Umgebung, Secrets, Volumes, Laufzeitauswahl und Health Check.
3. Starten Sie das Release und verfolgen Sie den Task, während Opfield den inaktiven Slot vorbereitet.
4. Warten Sie, bis der Health Check besteht.
5. Lassen Sie die Umschaltung des Datenverkehrs abschließen und prüfen Sie dann eine echte Anfrage, Anwendungslogs und Metriken.
6. Lassen Sie den vorherigen Slot unverändert, bis das vereinbarte Rollback-Fenster verstrichen ist.

Das Speichern eines neuen Image-Tags, Befehls, von Mounts, Labels oder einer Laufzeit in den Einstellungen des Deployments rollt es auf diese Weise aus; die Schaltfläche lautet Save & Deploy. Das Speichern von Umgebungsvariablen eines laufenden Deployments stellt sie im Bereitschafts-Slot bereit. Ressourcenlimits werden mit der Konfiguration gespeichert. Das Bereitstellen oder Aktualisieren eines Deployments mit einem neuen Image oder Befehl erfordert docker:containers:environment und docker:containers:secrets darauf, weil der neue Slot die Umgebung und die Secrets des Deployments erhält; eine neue Umgebung allein erfordert nur docker:containers:environment. Deploy-Befehle warten auf das Beziehen des Images, die Startkulanzzeit und das Deploy-Timeout, bevor sie ein Ergebnis melden.

Über die API ersetzt POST /api/docker/nodes/{nodeId}/deployments/{deploymentId}/deploy mit env die gesamte Umgebung des Deployments und speichert sie als seine Konfiguration; senden Sie also jede Variable, die das Deployment behalten soll. Das MCP-Werkzeug deploy_docker_deployment und der Assistent setzen env stattdessen über die gespeicherte Umgebung und entfernen die in removeEnv aufgeführten Schlüssel; jede andere gespeicherte Variable bleibt erhalten. Beide erfordern docker:containers:environment.

Per Webhook ausgelöste Releases verwenden denselben Autorisierungs- und Health-Gate-Weg. Eine Webhook-Anfrage umgeht nicht die Zuständigkeit des Deployments und macht aus einem fehlgeschlagenen Build kein öffentliches Release.

Fehler und Rollback

Schlägt die Vorbereitung oder die Health-Prüfung fehl, bevor der Datenverkehr umgeschaltet wird, bleibt der bestehende aktive Slot die bedienende Version. Prüfen Sie die Operation auf Fehler beim Beziehen des Images, beim Start, beim Health Check, bei Secrets, Volumes oder Kapazität; beheben Sie die Ursache und beginnen Sie ein neues Release, statt den fehlgeschlagenen Slot an Ort und Stelle zu ändern. Ein Kandidaten-Slot, der seinen Health Check nicht besteht, wird gestoppt und für seine Logs aufbewahrt, sodass er nicht in einer Absturzschleife hängen und dem bedienenden Slot Datenbankverbindungen wegnehmen kann; eine spätere Umschaltung auf diesen Slot erstellt ihn aus seinem erfassten Release neu.

Tritt nach der Umschaltung eine für Kunden sichtbare Regression auf, verwenden Sie die ausdrückliche Rollback-Aktion. Sie stellt den Datenverkehr auf den vorgehaltenen, bekannt fehlerfreien Slot zurück und erfasst das Ereignis im Verlauf des Deployments. Prüfen Sie nach dem Rollback Route, Health-Zustand der Anwendung und Logs. Eine Slot-Umschaltung behält die Version des Bereitschafts-Slots, und ein Rollback kehrt zum vorherigen Release zurück. Löschen Sie den neueren Slot erst, wenn der Vorfalleintrag und die gewünschte Nachbereitung geklärt sind.

Operationen bei Neustarts, Updates und Builds

Deployment-Operationen überstehen Neustarts von Opfield. Ein dauerhafter Durchlauf schließt das Auslaufen des vorherigen Slots ab, und ein unterbrochenes Release wird aus dem Slot rekonstruiert, den der Router des Nodes tatsächlich bedient. Kann der Node nicht innerhalb von 5 Minuten geprüft werden, wird das Release als fehlgeschlagen markiert, mit einem Grund wie einem gestoppten Router oder einem Daemon, der seinen bedienenden Slot nicht melden kann; aktualisieren Sie im letzteren Fall den Docker-Daemon.

Während ein Release läuft, sind die Einstellungen des Deployments gesperrt: Speichern liefert DEPLOYMENT_BUSY, und die Konsole deaktiviert Save, bis das Release abgeschlossen ist. Während ein Git-Build auf das Deployment ausgerollt wird, liefern Lebenszyklus- und Konfigurationsänderungen BUILD_ROLLOUT_IN_PROGRESS; warten Sie, bis der Rollout abgeschlossen ist. Ein Deployment kommt nach Stop und anschließendem Start oder nach einem Neustart des Nodes auf seinem aktiven Slot zurück, und ein Neustart von Opfield mitten in einem Deploy verliert das Release nicht. Während eines Opfield-Updates werden neue Deployment-Operationen mit OPFIELD_UPDATING abgelehnt, bis das Update abgeschlossen ist; siehe Voraussetzungen für Updates in 2.11.

Deployment-Router

Jedes Deployment hat einen kleinen nginx-Router-Container auf seinem Node. Der Router empfängt den Datenverkehr des Deployments und leitet ihn an den aktiven Slot weiter; eine Umschaltung oder ein Rollback ändert nur das Ziel des Routers.

• Er kommt nach einem Neustart zurück. Router laufen mit der Neustartrichtlinie unless-stopped. Wenn der Docker-Daemon startet, repariert er den Router jedes bedienenden Deployments: Ein Router, der von einem älteren Release erstellt wurde oder mit der Neustartrichtlinie no zurückblieb, erhält die aktuelle Richtlinie oder wird aus der Konfiguration, die er bedient, samt Routen und veröffentlichten Ports neu erstellt und auf den Anwendungs-Slot ausgerichtet, der tatsächlich läuft. Der Daemon wiederholt die Reparatur jede Minute, bis sie gelingt; während eine Deployment-Operation das Deployment hält, wartet die Reparatur darauf und läuft danach einmal. Ein Deployment, das bewusst gestoppt oder beendet wurde, behält seinen Router gestoppt.
• Operationen starten einen gestoppten Router. Ein Deploy, eine Slot-Umschaltung, ein Router-Update oder ein Start fährt einen Router hoch, der durch Kill oder Stop gestoppt wurde, statt daran zu scheitern, und ein Deployment, dessen aktiver Slot nicht starten kann, bleibt nicht mehr hängen.
• Er hängt nicht vom DNS von Docker ab. Die Router-Konfiguration nennt die Adresse des Containers des aktiven Slots und leitet auf jeder nginx-Version direkt dorthin weiter, ohne Resolver; der Daemon prüft die Adresse alle 5 Sekunden und schreibt die Konfiguration neu, wenn sie sich ändert. Nur eine Konfiguration, die geschrieben wurde, bevor die Adresse des Slots bekannt war, löst den Slot-Namen über das DNS von Docker auf. Bestehende Router werden an Ort und Stelle aktualisiert, ohne neu erstellt zu werden.
• Er schreibt kein Access-Log. Der Ingress Node protokolliert bereits jede Anfrage. Ein Router blockiert daher nie auf seiner Containerausgabe, die dockerd ausliest, sodass eine hängende Docker Engine (dockerd) den Datenverkehr zu einem laufenden Deployment nicht stoppt.
• Anwendungen, die jede Anfrage protokollieren. Die Containerausgabe läuft über die Log-Pipeline von Docker, die nicht mehr ausgelesen wird, solange dockerd eingefroren ist. Eine Anwendung, die für jede Anfrage eine Zeile auf stdout oder stderr schreibt, kann daher ins Stocken geraten, sobald diese Pipe voll ist, auch wenn der Router und die Secure Links weiter funktionieren. Halten Sie das Protokollieren pro Anfrage aus der Containerausgabe heraus oder akzeptieren Sie, dass eine solche Anwendung während eines Einfrierens von dockerd ins Stocken geraten kann.
• Anfrageinhalte sind nicht begrenzt. Der Router leitet Anfrageinhalte beliebiger Größe weiter (das Limit legt die Route fest) und streamt sie an den Slot, statt sie auf der Festplatte zu puffern. Router, die vor dieser Änderung erstellt wurden, übernehmen sie bei ihrem nächsten Deploy, ihrer nächsten Slot-Umschaltung oder ihrem nächsten Neustart.
• Seine eigenen Fehler sind gekennzeichnet. Kann der Router den aktiven Slot nicht erreichen, antwortet er mit 502 oder 504 und dem Header X-Opfield-Deployment-Router: upstream-unavailable (X-Gateway-Deployment-Router bei einem Router, der vor 2.12.1 bereitgestellt wurde, bis das Deployment erneut bereitgestellt wird), was einen Router-Fehler von einem Anwendungsfehler unterscheidet. Workload Availability verwendet ihn, um zu entscheiden, ob eine Deployment-Platzierung bereit ist.

Folgen der Außerbetriebnahme

Das Entfernen eines Deployments entfernt seine verwalteten Slots und kann Zugriffsbeziehungen entfernen, die nur zu dieser Ressource gehören. Ein Deployment kann gelöscht werden, während sein Bereitschafts-Slot noch ein älteres Image ausführt. Lösen oder migrieren Sie zuerst Routen, Datenbank-Bindings und persistente Daten, die erhalten bleiben müssen. Ein Rollback eines Deployments schützt einen vorherigen Laufzeit-Slot; es ersetzt kein Backup veränderlicher Volume-Daten.

Erfolgskriterien und Rollout-Richtlinie

Legen Sie einen Health Check fest, der eine für Benutzer relevante Abhängigkeit abbildet, nicht nur, dass der Prozess eine TCP-Verbindung annimmt. Prüfen Sie vor der Übernahme Startlogs, die Stabilität des Health-Zustands über den vereinbarten Beobachtungszeitraum, die Ressourcennutzung und alle privaten Abhängigkeiten. Prüfen Sie nach der Übernahme eine echte Anfrage über die Route und beobachten Sie Fehlerrate und Latenz, bevor Sie den vorherigen Slot außer Betrieb nehmen.

Legen Sie ein ausdrückliches Rollback-Fenster fest. Halten Sie in diesem Fenster das vorherige Artefakt und die Konfiguration verfügbar und vermeiden Sie Änderungen, die es unmöglich machen, damit zu bedienen. Steht ein späteres Problem nicht mit dem neuen Release in Zusammenhang, halten Sie diesen Beleg vor einem Rollback fest; unnötiges Umschalten von Slots kann die Diagnose erschweren.

Details für Betreiber: Kapazität und fehlgeschlagene Releases

Der inaktive Slot benötigt genug CPU, Arbeitsspeicher, Speicher, Ports und Zugriff zum Beziehen von Images, um neben dem aktiven Slot zu starten. Während der Überlappung teilen sich beide Slots außerdem jede Datenbankverbindung des Deployments, die so viele Verbindungen transportiert, wie die Datenbank annimmt; dimensionieren Sie Verbindungspools so, dass der neue Slot seine Pools öffnen kann, während der bedienende Slot seine eigenen hält. Siehe Verbindungskapazität und Verbindungspools. Die Kapazitätsplanung muss diese vorübergehende Überlappung einbeziehen. Ein Release, das seinen inaktiven Slot nicht zuweisen kann, sollte fehlschlagen, bevor sich der Datenverkehr ändert, und den aktiven Dienst unberührt lassen.

Wird der Health-Zustand nie bereit, prüfen Sie die Logs des inaktiven Slots und die genaue Health-Antwort. Korrigieren Sie das Image oder die Release-Konfiguration und erstellen Sie einen neuen Release-Versuch; ändern Sie nicht den verwalteten untergeordneten Container. Ist die Übernahme abgeschlossen, die Prüfung schlägt aber fehl, verwenden Sie die erfasste Rollback-Aktion und prüfen Sie dann sowohl den Dienstpfad als auch die Identität des endgültig aktiven Slots.