Introduction
Marsh House livre A river remembered, River edition 2, à un moteur de réception isolé du registre. Un paquet de transfert existe déjà, mais il ne sauvegarde que l’image web. Réparez-le, chargez les deux images sur le destinataire et utilisez l’exposition complète après l’arrêt de sa source.
Ce TP indépendant prépare sa propre source, ses fichiers et son destinataire ; il n’a besoin de rien provenant de la VM précédente. Vous devez avoir appris l’assemblage du paquet, les relations Compose fournies et la différence entre étiquettes et identifiants d’images dans Pack the Exhibition, ou avoir des connaissances équivalentes. Docker et Compose sont prêts. Vous allez apprendre les contextes explicites, le chargement côté destinataire et le démarrage hors ligne.
Utilisez Workstation, Source Exhibition et Receiving Exhibition. Les deux moteurs ont des sockets, processus containerd et stockages d’images distincts, mais partagent le noyau de cette VM ; il s’agit d’une frontière de réception contrôlée, pas de deux machines physiques ni d’une garantie de reprise après sinistre complète. Prévoyez environ 45 minutes, lecture et erreurs ordinaires comprises ; il s’agit d’une estimation de l’auteur.
Examiner la frontière de réception
Dans cette étape, vous allez distinguer les deux moteurs avant de modifier l’un ou l’autre. Commencez dans Source Exhibition. Ouvrez Pocket compass et Crossing ledger, lisez leurs fiches et téléchargez leurs fiches de terrain. Notez River edition 2 sur la page de collection. Receiving Exhibition indique actuellement Exhibition not running, avec HTTP 503 : il n’emprunte pas la page source.
Passez à Workstation, qui démarre dans /home/labex/project/exhibition-handoff :
cd /home/labex/project/exhibition-handoff
cat release.json
Les étiquettes requises sont field-notes/web:receive et field-notes/api:receive. Le dossier packet préparé contient la collection et le fichier Compose à chemins relatifs, mais une seule image dans images.tar.
Un contexte Docker nomme une connexion à un démon. La commande context create ci-dessous enregistre une connexion au socket Unix du destinataire ; elle ne crée pas de nouveau moteur et ne change pas le contexte actif par défaut. unix:// est le protocole de socket local, et le reste du chemin appartient uniquement au destinataire isolé de ce cours :
docker context create receiver --docker host=unix:///opt/labex/dk03/receiver-socket/docker.sock
Si ce nom existe déjà à la suite de votre essai, examinez-le avec docker context inspect receiver plutôt que de changer le contexte global ou de créer un autre destinataire. Utilisez --context pour chaque opération afin de garder sa cible explicite.
docker --context default info --format '{{.ID}}'
docker --context receiver info --format '{{.ID}}'
docker --context receiver image ls
Les identifiants des moteurs diffèrent. Le destinataire possède une image de base Python utilisée par son service de référence indépendant receiving-desk, mais aucune des deux étiquettes d’exposition requises. Préservez ce service et le moteur de réception lui-même.
Le moteur de réception se trouve dans le conteneur du cours dk03-receiver. Les deux commandes de lecture seule suivantes exécutent des outils dans ce conteneur via le moteur source. ip route affiche les routes connectées, sans route par défaut. wget tente une véritable requête au registre ; -T 5 borne l’attente réseau et -O /dev/null ignore tout corps de réponse. Cette tentative doit échouer avec un code non nul, car cet espace de noms de réception ne dispose d’aucune route vers le registre :
docker --context default exec dk03-receiver ip route
docker --context default exec dk03-receiver wget -T 5 -O /dev/null https://registry-1.docker.io/v2/
Lisez l’erreur de connexion. Un échec de connexion réseau diffère d’un code HTTP applicatif 404 ou 503. N’ajoutez pas de route, n’activez pas l’accès au registre et ne montez pas le socket Docker source pour le contourner : le paquet doit suffire à réaliser le transfert.
Réparer, copier et charger le paquet
Dans cette étape, vous allez placer les deux images requises et la collection locale dans le dossier de réception. Commencez dans Workstation. Le TP précédent sur le paquet enseignait image save, cp et les chemins Compose relatifs. Remplacez l’archive incomplète par la paire exacte indiquée dans le descriptif de version de ce TP :
docker --context default image save -o packet/images.tar field-notes/web:receive field-notes/api:receive
cat packet/compose.yaml
Confirmez que le montage est ./collection:/collection:ro et que les étiquettes des services se terminent par :receive. Son chemin relatif sera résolu à côté de la configuration reçue. Copiez le paquet complet, pas seulement son archive d’images :
cp -r packet /home/labex/project/receiving/packet
ls /home/labex/project/receiving/packet
Au premier essai, cette destination n’existe pas. Si vous répétez votre copie, copiez le contenu avec cp -r packet/. /home/labex/project/receiving/packet/ plutôt que d’imbriquer un autre répertoire packet. Le répertoire parent de réception contient aussi desk/, qui appartient au service de référence à préserver. Ne le supprimez pas et ne l’écrasez pas.
image load -i importe les configurations, couches et étiquettes d’images d’une archive sauvegardée dans le moteur sélectionné :
docker --context receiver image load -i /home/labex/project/receiving/packet/images.tar
docker --context receiver image ls
Les deux étiquettes requises doivent maintenant apparaître. Ce destinataire ne partageait pas le magasin d’images du moteur source ; sauvegarder une étiquette sur la source seule ne pouvait pas la rendre disponible ici. Si une seule étiquette apparaît, revenez à release.json, réparez l’archive de sauvegarde du paquet source et recopiez son contenu avant de recharger.
Ouvrir le destinataire sans sa source
Dans cette étape, vous allez démarrer uniquement à partir des fichiers côté destinataire et démontrer son indépendance. Commencez dans Workstation. --project-directory définit où Compose résout ses fichiers relatifs, -p exhibition nomme uniquement les ressources applicatives de ce cours, up -d les démarre en arrière-plan, --pull never interdit les téléchargements depuis le registre et --no-build interdit la construction des images manquantes :
docker --context receiver compose --project-directory /home/labex/project/receiving/packet -p exhibition up -d --pull never --no-build
docker --context receiver compose --project-directory /home/labex/project/receiving/packet -p exhibition ps
gallery et records doivent tous deux être actifs. Si Compose indique qu’une image manque, réparez et chargez le paquet au lieu de la télécharger. Si la page indique Collection unavailable, examinez les journaux du service de fiches avec le même préfixe Compose suivi de logs records, comparez le dossier de collection reçu et son montage :ro, puis corrigez le paquet et recopiez-le. Si un essai partiel précédent doit être remplacé, utilisez ce même préfixe suivi de down, puis répétez la commande de démarrage affichée. Cela ne supprime que les conteneurs de l’application, pas le bureau de réception ni son moteur.
Passez à Receiving Exhibition, rechargez et utilisez les quatre objets, leurs illustrations, détails et téléchargements de fiches de terrain. Il s’agit du service de réception, pas d’une copie de la page source.
Passez à Workstation. docker stop demande l’arrêt d’un conteneur nommé. Arrêtez uniquement ces deux services sources, en laissant le moteur de réception et receiving-desk actifs :
docker --context default stop dk03-source-web dk03-source-api
Passez à Source Exhibition et rechargez : la page doit maintenant indiquer Exhibition not running. Passez à Receiving Exhibition, rechargez, ouvrez Pocket compass et Crossing ledger, puis téléchargez de nouveau leurs fiches. Le destinataire doit toujours fournir la bonne édition, les quatre objets, chaque illustration et chaque téléchargement complet. Son lecteur n’a aucun repli vers la source. Une nouvelle session de navigateur doit aussi fonctionner sans pages précédemment mises en cache.
Voici la collection River edition 2 reçue, toujours disponible après l’arrêt de la source :
Laissez l’application reçue active. Les vérifications observent cet état réel et le préservent ; une réexécution isolée supplémentaire charge votre paquet inchangé dans un nouveau magasin sans réseau pour vérifier la reproductibilité de la livraison. Aucune vérification ne complète pour vous des fichiers ou images manquants sur l’environnement réel.
Résumé
Vous avez utilisé des contextes explicites pour cibler des moteurs Docker indépendants, réparé un paquet à deux images et l’avez chargé sur le destinataire isolé du registre. Compose a démarré avec la configuration et les ressources côté destinataire, en interdisant le téléchargement et la construction. L’exposition complète est restée disponible après l’arrêt des deux services sources.
