Introduction
Marsh House envoie Along the waterline, River edition 1, à une borne de réception qui ne peut pas accéder à un registre d’images. L’exposition comprend un service web, une API de fiches et un répertoire de fichiers de collection. Préparez un dossier contenant tout le nécessaire pour exécuter ailleurs cette version exacte.
Vous devez connaître les bases de la construction et de l’exécution Docker, les ports publiés et les chemins dans le terminal. Ce TP enseigne le petit fichier Compose, les archives d’images et le rassemblement portable des fichiers. Aucune connaissance en programmation ou en muséologie n’est requise. Docker et les deux images de l’application sont préparés. Les fiches et les illustrations schématiques originales sont des supports pédagogiques fictifs.
Utilisez Workstation pour les commandes et Source Exhibition pour l’exemple fonctionnel. Receiving Exhibition est vide au départ ; vous utiliserez cette frontière de livraison dans le TP indépendant suivant. Le résultat de ce TP est un paquet complet, plutôt qu’un destinataire en cours d’exécution. Prévoyez environ 45 minutes, lecture et erreurs ordinaires comprises ; il s’agit d’une estimation de l’auteur.
Identifier l’exposition complète
Dans cette étape, vous allez déterminer ce qui doit survivre au transfert et sauvegarder la paire exacte d’images. Commencez dans Source Exhibition. La page affiche quatre objets. Ouvrez Pocket compass, examinez son illustration et son histoire, puis sélectionnez Download field sheet. Cela télécharge une véritable fiche texte avec une édition, un identifiant d’objet et une description. Utilisez Back to collection, ouvrez Crossing ledger et téléchargez aussi sa fiche. Ce sont des objets distincts, chacun avec sa propre fiche et ses fichiers.
La collection relie chaque objet à sa page détaillée et au téléchargement de sa fiche :
Passez à Workstation. Il démarre dans /home/labex/project/exhibition-release. pwd affiche le dossier courant, ls en liste le contenu et cd permet d’y revenir si vous vous en éloignez :
cd /home/labex/project/exhibition-release
ls
compose.yaml décrit les deux services actifs. release.json identifie cette édition et les identifiants immuables des images derrière ses étiquettes. collection/ contient les fiches JSON publiées, les illustrations SVG originales et les téléchargements texte. author-notes/ contient des brouillons non publiés qui doivent rester hors du paquet. Conservez inchangés tous les éléments fournis et les services sources actifs.
cat affiche un fichier texte. Lisez le descriptif de version :
cat release.json
Repérez les entrées web et api. Leurs étiquettes sont field-notes/web:pack et field-notes/api:pack ; chacune possède aussi un identifiant d’image commençant par sha256:. Une étiquette est un nom qui peut changer de cible. L’identifiant désigne ces contenus d’image précis. Livrez les entrées de la version ensemble ; une image web fonctionnelle seule ne peut fournir ni les fiches ni les fichiers.
mkdir crée un répertoire ; -p crée les parents manquants et accepte un répertoire existant. Si packet existe déjà à la suite de votre propre essai, examinez-le avec ls packet et continuez à le compléter ; ne supprimez pas les dossiers sources fournis.
mkdir -p packet
--context default cible explicitement le moteur source. Un contexte nomme une connexion à un démon Docker ; ce n’est pas une seconde machine physique. docker image save écrit la configuration, les étiquettes et les couches du système de fichiers des images. -o nomme le fichier de sortie. Incluez les deux étiquettes de la version dans cette archive unique :
docker --context default image save -o packet/images.tar field-notes/web:pack field-notes/api:pack
L’opération peut prendre un moment et ne produit normalement aucune sortie en cas de réussite. docker container export est différent : il exporte le système de fichiers d’un conteneur, omet les métadonnées d’image et ne rassemble pas les fichiers des montages liés. Il ne peut pas remplacer ce transfert d’images.
Comprendre les relations entre fichiers d’exécution
Dans cette étape, vous allez relier le fichier Compose à l’exposition que vous venez d’utiliser et copier sa configuration portable. Commencez dans Workstation et affichez-le :
cat compose.yaml
YAML utilise l’indentation pour exprimer les relations. services: contient gallery et records. Chaque image: sélectionne une image préparée ; ce fichier ne contient aucune recette de construction. gallery fournit les pages au navigateur et demande sa collection à records, l’API qui lit les ressources publiées.
Les deux services utilisent network_mode: host : ils partagent l’espace de noms réseau de l’hôte de leur moteur. Ici, le service web écoute sur le port 9100 et son API sur 9101. Le moteur source utilise le réseau de Workstation. Le moteur de réception s’exécute dans son propre espace de noms réseau de conteneur isolé ; les mêmes numéros n’y désignent donc pas la source. Il s’agit d’un dispositif pédagogique local volontairement limité, pas d’une recette générale de sécurité réseau.
API_ORIGIN est une variable d’environnement, une valeur nommée transmise au programme de galerie. Sa valeur http://127.0.0.1:9101 désigne l’API dans ce même espace de noms. records.volumes lie ./collection à /collection en lecture seule, ce qu’indique :ro. Le chemin ./ est relatif au répertoire du projet Compose, à côté de compose.yaml. Il s’agit d’une dépendance d’exécution externe : les images ne la contiennent pas.
Demandez à Compose d’analyser le fichier sans démarrer ni modifier les services :
docker --context default compose config
--context default sélectionne explicitement le moteur source préparé ; un contexte est une connexion nommée à un démon Docker, pas un second ordinateur physique. La sortie développe le chemin relatif de la collection en chemin absolu du dossier source courant. Conservez le chemin relatif du fichier original pour la livraison : copier ce chemin source développé dans le paquet maintiendrait une dépendance à l’ancien emplacement sur Workstation.
L’ensemble nécessaire est maintenant clair : deux contenus d’image, une configuration Compose et la collection publiée complète. Le compilateur, le répertoire de construction source, les brouillons et les conteneurs sources actifs ne sont pas nécessaires pour démarrer l’édition reçue.
cp copie un fichier ; -r copie récursivement un répertoire et ses enfants. Copiez la configuration portable d’origine et la collection publiée :
cp compose.yaml packet/compose.yaml
Assembler un paquet portable
Dans cette étape, vous allez compléter le paquet avec sa collection publiée et l’examiner comme une livraison déplaçable. Commencez dans Workstation. Créez le dossier de collection du paquet, puis copiez récursivement le contenu du répertoire source. /. désigne son contenu : répéter cette commande n’imbrique donc pas un autre répertoire de collection :
mkdir -p packet/collection
cp -r collection/. packet/collection/
Examinez le résultat :
ls packet
ls packet/collection
cat packet/compose.yaml
Le premier niveau contient exactement compose.yaml, images.tar et collection. La collection contient exhibits.json, art/ et download/. Le montage Compose commence toujours par ./collection, jamais par le chemin absolu de la source. Ne copiez ni author-notes ni release.json dans le paquet d’exécution : ce dernier est votre preuve de sélection côté source.
La présence d’un fichier ou la grande taille d’une archive ne prouvent pas qu’ils sont complets. La vérification charge vos deux images sauvegardées dans un magasin d’images indépendant jetable et y exécute le paquet, sans réseau, montage source, téléchargement ni construction. Elle lit toutes les fiches, illustrations et tous les octets téléchargés, puis supprime ses ressources de test isolées. Elle ne démarre ni ne modifie votre exposition de réception réelle.
Si la vérification signale une image manquante, relisez release.json et répétez la même commande de sauvegarde avec les deux étiquettes. Si un fichier de collection manque, comparez les deux résultats de ls et copiez correctement le répertoire publié. Si un chemin est incorrect, restaurez packet/compose.yaml à partir du fichier portable fourni. Gardez le paquet ici pour ce TP ; le suivant démarre avec ses propres fichiers indépendants.
Résumé
Vous avez identifié l’ensemble des éléments d’exécution d’une application à deux services, sauvegardé sa paire exacte d’images et rassemblé sa collection externe à côté d’un fichier Compose portable. Le paquet peut démarrer dans un magasin d’images indépendant sans emprunter le répertoire source. Les couches d’images seules ne représentaient qu’une partie de ce livrable.
