Migrations et archives de conteneurs

La migration déplace une charge de travail éligible entre nœuds Docker en préservant son identité Opfield et ses droits éligibles sur la ressource. Une archive GWCA empaquette une charge de travail éligible pour un export et un import contrôlés. Ces deux processus sont des changements d’exploitation, et non des sauvegardes : les données des volumes avec état nécessitent leur propre plan de sauvegarde et de restauration.

Choisir le bon résultat

Utilisez la migration lorsque la même charge de travail gérée doit passer sur un autre nœud Docker en conservant sa propriété et ses relations dans Opfield. Utilisez une archive de conteneur Opfield (GWCA) lorsque la configuration d’une charge de travail doit être exportée pour un transfert contrôlé ou un import ultérieur. Utilisez une sauvegarde applicative lorsque l’objectif est de protéger ou de restaurer des données. Ces résultats se recoupent sur le plan opérationnel, mais ne sont pas interchangeables.

Le propriétaire de la charge de travail décide de la fenêtre de maintenance et valide le comportement de l’application. Le responsable de la plateforme confirme la capacité de la cible, la compatibilité de l’exécution, l’accès aux images, le placement réseau et le nettoyage. Le responsable des données confirme la sauvegarde et la restauration. Une migration réussie préserve l’identité gérée et le chemin d’accès sur la cible ; une archive réussie prouve que la configuration prise en charge peut être importée, et non que les dépendances externes ou les données des volumes sont disponibles.

Confirmer d’abord l’éligibilité

La migration inter-nœuds effectue une vérification préalable de la capacité, le transfert des artefacts et des volumes, la vérification de la cible, la bascule et la reprise du nettoyage. La cible doit être en ligne, disposer de ressources suffisantes, prendre en charge l’environnement d’exécution choisi et pouvoir joindre tout artefact de registre requis.

Les charges de travail rattachées à un GPU, les charges de travail en secure runtime, les montages de répertoires de l’hôte et les projets Compose ne sont pas portables. Considérez-le comme une limite stricte plutôt que comme une condition à contourner en modifiant la configuration d’exécution appartenant à Opfield. Pour placer une application Compose existante sous la gestion d’Opfield sur son nœud actuel, adoptez plutôt le projet Compose.

La migration copie les données des volumes nommés locaux de la charge de travail et les crée sur la cible avec les mêmes noms. La vérification préalable arrête la migration si la cible possède déjà un volume portant le même nom, ou si un volume est partagé avec une autre charge de travail, non local ou adossé à une image disque. Un Container ou un Deployment disposant d’un lien vers une base de données ou un stockage ne peut pas migrer (MIGRATION_MANAGED_LINK_UNSUPPORTED) : supprimez le lien, migrez, puis recréez le lien sur le nœud cible. Les versions de Docker comportant un suffixe de distribution, comme 26.1.5+dfsg1 sur Debian, sont comparées selon leur numéro de version.

Migrer une charge de travail

1. Consignez les Routes, les liaisons de bases de données, les droits, les dépendances de volumes et la fenêtre de maintenance prévue.
2. Sauvegardez les volumes avec état et confirmez que le nœud cible dispose de la capacité et du profil d’exécution requis.
3. Lancez la migration depuis la charge de travail et suivez l’opération pendant le transfert et la vérification de la cible.
4. Attendez la bascule, puis vérifiez sur la cible la santé d’exécution, les routes, les journaux et les dépendances applicatives privées.
5. Conservez la source jusqu’à ce qu’Opfield signale la fin du nettoyage et que la fenêtre de vérification soit écoulée.

Si le transfert, le démarrage sur la cible ou la bascule échoue, examinez l’étape de l’opération. Utilisez les actions d’annulation ou de reprise du nettoyage fournies ; supprimer manuellement des objets intermédiaires peut empêcher Opfield de terminer ou de reprendre un nettoyage sûr.

Les charges de travail sur Docker Engine 20.10 à 28 migrent vers des nœuds dotés de moteurs plus récents. Les paramètres qu’un moteur plus récent ne peut pas conserver, comme une adresse MAC fixe ou une limite de mémoire noyau, sont listés par la vérification préalable avec le même message que celui sur lequel la migration s’arrêterait ; lorsque le nœud source exécute un démon Docker plus ancien, la vérification préalable affiche un avertissement à la place. Une migration qui a attendu la reconnexion d’un nœud puis s’est terminée apparaît comme terminée, et une migration annulée après une telle attente comme annulée.

Exporter et importer des archives GWCA

Les archives GWCA peuvent être autonomes ou adossées à un registre. Elles incluent la configuration de conteneur prise en charge et peuvent, en option, inclure les valeurs d’environnement, les secrets et les modifications de la couche accessible en écriture. Elles n’incluent jamais le contenu des volumes. À l’import, chaque volume archivé est créé vide sous un nouveau nom, ou vous le faites correspondre à un volume existant géré par Opfield.

L’export prend en charge un sous-ensemble portable des paramètres de conteneur. Les conteneurs dotés de montages de répertoires de l’hôte, de volumes anonymes, du mode privilégié ou de capacités modifiées, de périphériques ou de GPU, d’espaces de noms de l’hôte, de vérifications de santé (healthchecks), d’une journalisation personnalisée (la limite de journaux par défaut d’Opfield ne compte pas) ou d’autres paramètres propres à l’hôte sont refusés, et l’erreur liste les paramètres non pris en charge. Les conteneurs qui appartiennent à un projet Compose — tout conteneur portant un label com.docker.compose.project — ne peuvent pas être exportés : l’API REST et MCP les refusent avec DOCKER_ARCHIVE_COMPOSE_CONTAINER (HTTP 409) et la Console masque Export archive. Gérez-les via leur projet Compose. Les slots de Deployment blue/green sont également refusés.

Une archive ne transporte jamais les identifiants des liens du conteneur vers les bases de données ou le stockage. Un import ne peut pas rattacher le conteneur au réseau de l’hôte, à l’espace de noms réseau d’un autre conteneur ni aux réseaux internes d’Opfield, et il supprime les labels Compose et Opfield. Les clients MCP exportent et importent les archives via des liens à usage unique accompagnés d’une commande curl prête à l’emploi — l’opération link de download_docker_archive et de upload_docker_container_archive — au lieu de fragments base64 dans les appels d’outils.

Avant l’export, décidez s’il est nécessaire d’inclure les secrets et, le cas échéant, veillez à ce que l’archive soit traitée comme un élément sensible. Avant l’import, examinez le nœud cible, la disponibilité des images, la compatibilité de l’exécution, la correspondance des réseaux et les ports occupés. Restaurez les volumes séparément, puis vérifiez la charge de travail importée avant de lui envoyer du trafic.

Conséquences du retour arrière et du nettoyage

Le retour arrière d’une migration concerne le placement de la charge de travail et sa configuration d’exécution ; il n’annule pas les écritures effectuées par l’application pendant une bascule. Conservez la sauvegarde d’origine des volumes et les éléments de la source jusqu’à ce que la cible ait fait la preuve de sa santé. Supprimer une archive ne supprime pas une charge de travail, et la suppression de la source après une migration ne doit intervenir que par le cycle de vie de migration terminé.

Vérification et recette

Après une migration, vérifiez l’identité du nœud cible, l’exécution et la santé, les volumes rattachés, les Routes, les liaisons de bases de données, les droits, les journaux et une transaction client réelle. Confirmez que la source ne sert plus et n’accepte plus d’écritures avant d’approuver le nettoyage. Conservez les éléments de la source et les sauvegardes jusqu’à la fin de la période d’observation convenue.

Après l’import d’une archive, comparez l’empreinte de l’image, la commande, l’environnement, le traitement des secrets, les volumes, les réseaux, les ports, l’exécution et les limites de ressources avec l’intention de l’export. N’envoyez pas de trafic de production tant que les dépendances propres à l’application et la restauration des données ne sont pas terminées.

Détails pour l’opérateur : reprise après échec

La migration se déroule par étapes, de sorte qu’un échec avant la bascule doit laisser la source comme charge de travail active. Conservez l’enregistrement de l’opération et utilisez l’annulation ou la reprise du nettoyage prises en charge. Si la cible a démarré mais que la recette a échoué, déterminez si Opfield considère encore la source comme faisant autorité avant d’effectuer des modifications manuelles. Ne laissez jamais les deux copies accepter des écritures, sauf si l’application a été conçue pour cet état.

Les fichiers GWCA qui incluent des secrets ou des modifications de la couche accessible en écriture sont des artefacts sensibles. Stockez-les avec un contrôle d’accès, une protection de l’intégrité, des limites de conservation et un responsable. En cas d’échec de l’import, corrigez la compatibilité de la cible ou les correspondances et réessayez avec la même archive revue ; ne modifiez pas l’archive de façon non auditée pour contourner une politique.