Docker-Übersicht

In Opfield ist ein Docker-Workload eine Ressource, nicht nur ein laufender Container. Die Ressource enthält ihre Konfiguration, Zugriffsberechtigungen, ihren Lebenszyklusverlauf, ihre Beziehungen und ihren Sollzustand, und Opfield gleicht diesen Zustand nach einer Unterbrechung ab.

Wählen Sie den höchsten Lebenszyklus, der zur Anwendung passt:

Container: eine direkt verwaltete Laufzeit mit fokussierter Konfiguration und eigenem Lebenszyklus.
Deployment: eine stabile Anwendungsidentität mit zwei Laufzeit-Slots für Blue/Green-Releases mit Health-Gate und Rollback.
Compose-Projekt: eine erkannte externe Anwendung oder eine von Opfield verwaltete Anwendung auf einem Node mit validierter Konfiguration, unveränderlichen Revisionen, Lebenszyklusoperationen, Logs, Routen und Datenbank-Bindings.
Git-Quelle: eine Auslieferungseingabe für Container, Deployments und Pages. Sie ist keine eigenständige Anwendungsentität.

Workload Availability (HA) ist in Business und Enterprise für geeignete Container ohne Mounts, Deployments und ganze Compose-Projekte verfügbar. Sie fügt der bestehenden Ressourcenidentität Replikation mit fester Anzahl oder Failover mit einer bedienenden Instanz über unabhängige Docker Nodes hinzu.

Das Betriebsmodell wählen

Die Entscheidung betrifft in erster Linie Zuständigkeit und Wiederherstellung, nicht die Anzahl der Felder in einem Formular.

Bedarf	Empfohlenes Modell	Wichtigster Kompromiss
Ein Dienst mit einfachem Lebenszyklus	Container	Direkt und flexibel, aber Releases und Rollback verwaltet der Operator
Releases mit Health-Gate und vorgehaltenem Rollback-Kandidaten	Deployment	Höhere Release-Sicherheit, mit zwei verwalteten Laufzeit-Slots
Mehrere Dienste, die sich als eine Anwendung ändern müssen	Compose-Projekt	Eine Revisions- und Operationsgrenze, ein Node pro Platzierung; optional Availability für das ganze Projekt in Business/Enterprise
Reproduzierbare Artefakte aus der Quellcodeverwaltung	Git-Quelle plus eine zuständige Ressource	Fügt Build-Herkunft hinzu; die Sicherheit des Deployments kommt weiterhin von Container, Deployment, Compose oder Pages

Wählen Sie den höchsten Eigentümer, der abbildet, wie die Anwendung bei einem normalen Release geändert und bei einem Vorfall wiederhergestellt werden soll. Bilden Sie eine Anwendung aus mehreren Diensten nicht als unabhängige Container ab, nur um Compose zu vermeiden, und wählen Sie kein Deployment, wenn die Anwendung gemeinsamen beschreibbaren Zustand hat, der nicht sicher über Release-Slots hinweg existieren kann.

Die Plattformleitung sollte festlegen, wer für die Anwendungsressource, ihre Daten, ihre öffentlichen Routen, ihren Registry-Zugriff und ihre Rollback-Entscheidung zuständig ist. Opfield erfasst und erzwingt diese Grenzen, kann aber nicht entscheiden, ob eine Datenmigration auf Anwendungsebene umkehrbar ist.

Grenzen der Zuständigkeit

Opfield ist für die Metadaten und den Sollzustand der Ressourcen zuständig, die es erstellt oder übernimmt. Der Ziel-Docker-Daemon ist für den Laufzeitprozess, den Image-Cache, die lokale Speicherimplementierung und die Netzwerkanbindung zuständig. Eine verwaltete Ressource kann daher nicht verfügbar sein, während ihr Sollzustand erfasst bleibt; die Wiederherstellung beginnt mit der Wiederherstellung der Daemon- oder Node-Konnektivität, danach lässt man Opfield abgleichen.

Manche Docker-Objekte gehören einem übergeordneten Eigentümer. Deployment-Slots werden über ihr Deployment gesteuert, und Container mit Compose-Labels werden im Kontext ihres erkannten Projekts gruppiert. Ändern Sie untergeordnete Objekte eines Eigentümers nicht über einen eigenständigen Lebenszyklusweg: Direkte Änderungen können Abweichungen zwischen dem laufenden Daemon-Zustand und der in Opfield erfassten Konfiguration erzeugen.

Container, die Opfield nicht erstellt hat, sind dennoch sichtbar und bedienbar. Ein mit docker run gestarteter eigenständiger Container kann mit ressourcenbezogenen Berechtigungen ohne Übernahme neu gestartet und geprüft werden, während ein externes Compose-Projekt bis zu seiner Übernahme schreibgeschützt bleibt. Siehe Container, die Opfield nicht erstellt hat und Ein externes Projekt übernehmen.

Von Opfield verwaltete interne Ressourcen können Labels, Laufzeitnamen, Netzwerke, Volumes, Zugangsdaten, Build-Artefakte und Task-Einträge umfassen. Behandeln Sie diese als Implementierungsdetails, sofern eine Aktion in Opfield sie nicht ausdrücklich bereitstellt. Sie über Docker-Werkzeuge zu löschen oder umzubenennen, kann den Abgleich, das Routing oder ein künftiges Rollback zerstören.

Wie Lebenszyklusarbeit ausgeführt wird

Lang laufende Änderungen werden als Tasks oder Operationen dargestellt. Eine Operation erfasst die Absicht, durchläuft die Arbeit des Daemons und endet mit einem Erfolgs- oder Fehlerergebnis, das später geprüft werden kann. Eine zweite, konkurrierende Aktion zu starten, während eine aktiv ist, kann abgelehnt oder zurückgestellt werden; warten Sie auf die aktuelle Operation, bevor Sie es erneut versuchen.

Prüfen Sie vor der Änderung eines Workloads seine abhängigen Routen, Datenbank-Bindings, Berechtigungen, eingebundenen Volumes, Quelleinstellungen und Neustartrichtlinie. Entscheiden Sie vor dem Löschen, ob seine Daten und öffentlichen Einstiegspunkte an anderer Stelle erhalten bleiben müssen. Ein erfolgreiches Stoppen der Laufzeit ist nicht dasselbe wie ein abgeschlossenes Löschen.

Workloads erreichen Datenbanken auf eine von zwei Arten. Eine verwaltete Datenbank kann an einen Container, ein Deployment oder einen Compose-Dienst gebunden werden, und Opfield speist Verbindungswerte für eine eigene Engine-Identität ein. Eine externe Datenbank wird über Verbindungswerte erreicht, die Sie als Workload-Secrets speichern. Siehe Verwaltete und externe Datenbanken im Überblick.

Sichere Betriebsreihenfolge

Bestätigen Sie, dass der ausgewählte Docker Node online ist und die benötigte Laufzeitfähigkeit hat.
Prüfen Sie den Eigentümer der Ressource und verwandte Ressourcen, bevor Sie die Konfiguration bearbeiten.
Nehmen Sie eine beabsichtigte Lebenszyklusänderung vor und verfolgen Sie ihren Task bis zum Abschluss.
Prüfen Sie Health-Zustand, Anwendungslogs und die erwartete Route oder private Verbindung.
Behalten Sie ein bekannt fehlerfreies Image oder einen vorherigen Deployment-Slot, bis das Wiederherstellungsfenster verstrichen ist.

Schlägt eine Operation fehl, verwenden Sie ihre Diagnosen, um Fehler bei Image, Konfiguration, Speicher, Port, Berechtigung und Node-Konnektivität zu unterscheiden. Beheben Sie die ermittelte Voraussetzung und wiederholen Sie aus Opfield heraus. Entfernen Sie keine Docker-Objekte, die Opfield gehören, als allgemeine Wiederherstellungsmaßnahme.

Erfolgskriterien

Ein Workload ist bereit, wenn Soll- und beobachteter Zustand übereinstimmen, die zuständige Operation abgeschlossen ist, Health-Zustand und Logs akzeptabel sind und der tatsächliche Zugriffspfad funktioniert. Bei öffentlichen Anwendungen ist das die Route; bei privaten Anwendungen kann es ein Secure Link oder eine Datenbankabhängigkeit sein. Ein laufender Prozess ohne geprüften Zugriff ist kein erfolgreiches Deployment.

Behalten Sie für jeden Produktions-Workload ein bekannt fehlerfreies Artefakt, dokumentieren Sie persistente Daten und die Zuständigkeit für die Wiederherstellung und legen Sie das Rollback-Fenster fest. Testen Sie die Wiederherstellungsmaßnahme vor einem Vorfall. Details zu Ressourcen für Betreiber und Bereinigungsregeln behandeln die unten verlinkten Seiten.