Migrationen und Container-Archive

Eine Migration verschiebt einen geeigneten Workload zwischen Docker Nodes und bewahrt dabei seine Opfield-Identität und geeignete Ressourcenberechtigungen. Ein GWCA-Archiv verpackt einen geeigneten Workload für einen kontrollierten Export und Import. Beide Abläufe sind betriebliche Änderungen, keine Backups: Zustandsbehaftete Volume-Daten erfordern einen eigenen Backup- und Wiederherstellungsplan.

Das richtige Ergebnis wählen

Verwenden Sie eine Migration, wenn derselbe verwaltete Workload auf einen anderen Docker Node wechseln und dabei seine Opfield-Zuständigkeit und seine Beziehungen behalten muss. Verwenden Sie ein Opfield Container Archive (GWCA), wenn eine Workload-Konfiguration für eine kontrollierte Übertragung oder einen späteren Import exportiert werden muss. Verwenden Sie ein Anwendungs-Backup, wenn das Ziel darin besteht, Daten zu schützen oder wiederherzustellen. Diese Ergebnisse überschneiden sich betrieblich, sind aber nicht austauschbar.

Der Workload-Verantwortliche legt das Wartungsfenster fest und prüft das Verhalten der Anwendung. Der Plattformverantwortliche bestätigt Kapazität des Ziels, Laufzeitkompatibilität, Image-Zugriff, Netzwerkplatzierung und Bereinigung. Der Datenverantwortliche bestätigt Backup und Wiederherstellung. Eine erfolgreiche Migration bewahrt die verwaltete Identität und den Zugriffspfad auf dem Ziel; ein erfolgreiches Archiv beweist, dass die unterstützte Konfiguration importiert werden kann, nicht dass externe Abhängigkeiten oder Volume-Daten verfügbar sind.

Zuerst die Eignung bestätigen

Eine Cross-Node-Migration führt eine Kapazitäts-Vorabprüfung, die Übertragung von Artefakten und Volumes, die Prüfung des Ziels, die Umschaltung und die Wiederherstellung der Bereinigung durch. Das Ziel muss online sein, ausreichende Ressourcen haben, die gewählte Laufzeit unterstützen und jedes benötigte Registry-Artefakt erreichen.

Workloads mit GPU, Workloads mit sicherer Laufzeit, Host-Bind-Mounts und Compose-Projekte sind nicht portierbar. Behandeln Sie dies als harte Grenze und nicht als Bedingung, die man durch Ändern von Laufzeitkonfiguration, die Opfield gehört, umgehen könnte. Um eine bestehende Compose-Anwendung auf ihrem aktuellen Node unter die Verwaltung von Opfield zu bringen, übernehmen Sie das Compose-Projekt stattdessen.

Die Migration kopiert die Daten der lokalen benannten Volumes des Workloads und erstellt sie auf dem Ziel mit denselben Namen. Die Vorabprüfung stoppt die Migration, wenn das Ziel bereits ein Volume mit demselben Namen hat oder wenn ein Volume mit einem anderen Workload geteilt, nicht lokal oder durch ein Disk-Image gestützt ist. Ein Container oder Deployment mit einer Datenbank- oder Speicherverbindung kann nicht migriert werden (MIGRATION_MANAGED_LINK_UNSUPPORTED): Löschen Sie die Verbindung, migrieren Sie und verbinden Sie ihn auf dem Ziel-Node erneut. Docker-Versionen mit Distributionssuffixen, etwa 26.1.5+dfsg1 unter Debian, werden anhand ihrer Release-Nummer verglichen.

Einen Workload migrieren

1. Halten Sie Routen, Datenbank-Bindings, Berechtigungen, Volume-Abhängigkeiten und das geplante Wartungsfenster fest.
2. Sichern Sie zustandsbehaftete Volumes und bestätigen Sie, dass der Ziel-Node die benötigte Kapazität und das Laufzeitprofil hat.
3. Starten Sie die Migration vom Workload aus und verfolgen Sie die Operation durch Übertragung und Prüfung des Ziels.
4. Warten Sie auf die Umschaltung und prüfen Sie dann Laufzeitzustand, Routen, Logs und private Anwendungsabhängigkeiten auf dem Ziel.
5. Behalten Sie die Quelle, bis Opfield den Abschluss der Bereinigung meldet und das Prüffenster verstrichen ist.

Schlagen Übertragung, Start auf dem Ziel oder Umschaltung fehl, prüfen Sie die Phase der Operation. Verwenden Sie die bereitgestellten Aktionen zum Abbrechen oder zur Wiederherstellung der Bereinigung; das manuelle Löschen von Zwischenobjekten kann verhindern, dass Opfield eine sichere Bereinigung abschließt oder fortsetzt.

Workloads auf Docker Engine 20.10 bis 28 migrieren auf Nodes mit neueren Engines. Einstellungen, die eine neuere Engine nicht beibehalten kann, etwa eine feste MAC-Adresse oder ein Kernel-Speicherlimit, listet die Vorabprüfung mit derselben Meldung auf, mit der die Migration abbrechen würde; führt der Quell-Node einen älteren Docker-Daemon aus, zeigt die Vorabprüfung stattdessen eine Warnung. Eine Migration, die auf den erneuten Verbindungsaufbau eines Nodes gewartet hat und dann abgeschlossen wurde, wird als abgeschlossen angezeigt, und eine, die nach einem solchen Warten abgebrochen wurde, als abgebrochen.

GWCA-Archive exportieren und importieren

GWCA-Archive können eigenständig oder Registry-gestützt sein. Sie enthalten die unterstützte Container-Konfiguration und können optional Umgebungswerte, Secrets und Änderungen der beschreibbaren Schicht enthalten. Sie enthalten niemals Volume-Inhalte. Beim Import wird jedes archivierte Volume leer unter einem neuen Namen erstellt, oder Sie ordnen es einem bestehenden, von Opfield verwalteten Volume zu.

Der Export unterstützt eine portable Teilmenge der Container-Einstellungen. Container mit Host-Bind-Mounts, anonymen Volumes, privilegiertem Modus oder geänderten Capabilities, Geräten oder GPUs, Host-Namespaces, Health Checks, benutzerdefiniertem Logging (das Standard-Log-Limit von Opfield zählt nicht) oder anderen hostspezifischen Einstellungen werden abgelehnt, und der Fehler listet die nicht unterstützten Einstellungen auf. Container, die zu einem Compose-Projekt gehören – jeder Container mit dem Label com.docker.compose.project –, können nicht exportiert werden: Die REST API und MCP lehnen sie mit DOCKER_ARCHIVE_COMPOSE_CONTAINER (HTTP 409) ab, und die Konsole blendet Export archive aus. Verwalten Sie sie über ihr Compose-Projekt. Slots von Blue/Green-Deployments werden ebenfalls abgelehnt.

Ein Archiv enthält niemals die Zugangsdaten der Datenbank- oder Speicherverbindungen des Containers. Ein Import kann den Container weder an das Host-Netzwerk noch an den Netzwerk-Namespace eines anderen Containers noch an die internen Netzwerke von Opfield anbinden, und er verwirft Compose- und Opfield-Labels. MCP-Clients exportieren und importieren Archive über einmalige Links mit einem fertigen curl-Befehl – die Operation link von download_docker_archive und upload_docker_container_archive – statt über Base64-Blöcke in Werkzeugaufrufen.

Entscheiden Sie vor dem Export, ob das Einschließen von Secrets nötig ist, und stellen Sie sicher, dass das Archiv in diesem Fall als sensibles Material behandelt wird. Prüfen Sie vor dem Import den Ziel-Node, die Verfügbarkeit des Images, die Laufzeitkompatibilität, die Netzwerkzuordnung und belegte Ports. Stellen Sie Volumes separat wieder her und prüfen Sie dann den importierten Workload, bevor Sie Datenverkehr dorthin leiten.

Folgen für Rollback und Bereinigung

Ein Rollback einer Migration betrifft die Platzierung und Laufzeitkonfiguration des Workloads; es macht keine Schreibvorgänge der Anwendung während einer Umschaltung rückgängig. Bewahren Sie das ursprüngliche Volume-Backup und die Belege der Quelle auf, bis das Ziel nachweislich fehlerfrei ist. Das Löschen eines Archivs löscht keinen Workload, und das Löschen der Quelle nach einer Migration sollte nur über den abgeschlossenen Migrationslebenszyklus erfolgen.

Prüfung und Abnahme

Prüfen Sie nach einer Migration die Identität des Ziel-Nodes, Laufzeit und Health-Zustand, eingebundene Volumes, Routen, Datenbank-Bindings, Berechtigungen, Logs und eine echte Client-Transaktion. Bestätigen Sie, dass die Quelle nicht mehr bedient und keine Schreibvorgänge mehr annimmt, bevor Sie die Bereinigung freigeben. Bewahren Sie die Belege der Quelle und die Backups auf, bis das vereinbarte Beobachtungsfenster abgeschlossen ist.

Vergleichen Sie nach einem Archivimport Image-Digest, Befehl, Umgebung, Umgang mit Secrets, Volumes, Netzwerke, Ports, Laufzeit und Ressourcenlimits mit der Absicht des Exports. Leiten Sie keinen Produktionsverkehr dorthin, bevor anwendungsspezifische Abhängigkeiten und die Datenwiederherstellung abgeschlossen sind.

Details für Betreiber: Wiederherstellung nach Fehlern

Die Migration ist in Phasen gegliedert, sodass ein Fehler vor der Umschaltung die Quelle als bedienenden Workload belassen sollte. Bewahren Sie den Operationseintrag und verwenden Sie den unterstützten Abbruch oder die Wiederherstellung der Bereinigung. Ist das Ziel gestartet, die Abnahme aber fehlgeschlagen, stellen Sie fest, ob Opfield die Quelle noch als maßgeblich meldet, bevor Sie manuelle Änderungen vornehmen. Lassen Sie niemals beide Kopien Schreibvorgänge annehmen, sofern die Anwendung nicht für diesen Zustand ausgelegt ist.

GWCA-Dateien, die Secrets oder Änderungen der beschreibbaren Schicht enthalten, sind sensible Artefakte. Speichern Sie sie mit Zugriffskontrolle, Integritätsschutz, Aufbewahrungsgrenzen und einem Verantwortlichen. Korrigieren Sie bei einem Importfehler die Kompatibilität des Ziels oder die Zuordnungen und versuchen Sie es mit demselben geprüften Archiv erneut; bearbeiten Sie das Archiv nicht auf nicht nachvollziehbare Weise, um eine Richtlinie zu umgehen.