Construire le guide des sentiers

Introduction

Pine & Path envoie son guide de visite d’Alder Ridge à un autre centre d’accueil. L’image actuelle fonctionne, mais elle emporte le compilateur Go, les fichiers sources et les résidus de compilation avec l’application. Livrez une image d’exécution allégée qui conserve les quatre sentiers, les filtres de difficulté, les pages détaillées, les illustrations locales et les téléchargements complets des itinéraires GPX.

Vous devez déjà savoir construire et exécuter une image Docker simple, et reconnaître les instructions Dockerfile FROM, COPY ainsi que la publication de ports. Aucune programmation Go n’est nécessaire : l’application complète et ses ressources sont fournies. Ce TP explique la compilation, les étapes de construction, l’organisation des fichiers d’exécution et la syntaxe d’écriture de fichiers du shell avant leur utilisation. Le parc et les itinéraires sont des supports pédagogiques fictifs.

Docker, l’image de compilation et le service de référence fourni sont prêts. Utilisez Workstation pour les commandes, Reference Guide pour l’exemple fonctionnel et Your Guide pour votre livraison. Ce TP est indépendant du défi. Prévoyez environ 60 minutes, lecture, constructions et erreurs ordinaires comprises ; il s’agit d’une estimation de l’auteur.

Construire l’image de départ fonctionnelle

Dans cette étape, vous allez observer ce que fait un guide complet, puis construire l’image de départ fournie. Commencez dans Reference Guide. Il affiche quatre sentiers. Sélectionnez Easy, ouvrez Cedar Loop, lisez sa distance et son dénivelé, puis utilisez Download GPX. GPX est un format XML contenant une trace nommée et des points géographiques ; ce téléchargement est un véritable fichier d’itinéraire. Sélectionnez Back to trails, puis Moderate, et ouvrez Ridge Path. Revenez à tous les sentiers. Remarquez aussi la feuille de style et la carte schématique : ce sont également des ressources d’exécution.

Passez à Workstation, qui démarre dans /home/labex/project/trail-guide. pwd affiche le répertoire courant et ls en liste les éléments. Si vous quittez le projet, la commande cd suivante permet d’y revenir :

cd /home/labex/project/trail-guide

ls

L’organisation fournie est la suivante :

Conservez ces ressources et le service de référence inchangés. Vous allez modifier Dockerfile, ajouter .dockerignore et créer les images et conteneurs du cours. Dockerfile.incomplete est un exemple d’échec fourni pour l’étape suivante.

cat affiche un fichier texte. Lisez le Dockerfile existant :

cat Dockerfile

Il part de dk02-go-builder:1, une image préparée contenant le compilateur Go. WORKDIR /guide sélectionne le répertoire de travail dans l’image. COPY . . copie le contexte de construction courant dans ce répertoire, y compris les fichiers inutiles à l’application finale. Le dernier ENTRYPOINT est un tableau JSON qui démarre directement le programme compilé.

La commande de construction définit CGO_ENABLED=0 pour cette commande afin que cet exemple Go, qui utilise la bibliothèque standard, n’ait pas besoin de bibliothèques C. go build compile le programme fourni ; -trimpath retire de l’exécutable les détails du répertoire source local, et -o /guide/guide lui donne son nom. Cela rend ce programme précis compatible avec une base d’exécution vide. D’autres programmes peuvent avoir besoin de bibliothèques partagées, de certificats ou d’autres données ; une base vide n’est pas une solution universelle.

Lisez d’abord la version du compilateur. docker run --rm crée un conteneur temporaire et le supprime après la fin de la commande. Les mots après le nom de l’image choisissent la commande à exécuter :

docker run --rm dk02-go-builder:1 go version

La sortie indique Go 1.26 sous Linux. Le compilateur s’exécute dans un conteneur, pas sur Workstation.

Construisez l’image de départ. docker build lit le Dockerfile ; -t attribue une étiquette au résultat, et le . final sélectionne le répertoire courant comme contexte de construction :

docker build -t trail-guide:sample .

Attendez la confirmation de réussite. L’étiquette identifie une image, pas un conteneur en cours d’exécution. Pour voir sa taille en octets, docker image inspect lit les métadonnées et --format sélectionne un champ. Les apostrophes transmettent le modèle littéralement :

docker image inspect trail-guide:sample --format '{{.Size}}'

Le nombre varie selon l’image de compilation préparée. L’image de départ fonctionne, mais contient encore le compilateur et les sources. Une petite taille ne suffira pas à prouver que son remplacement est complet.

Séparer les fichiers de construction des fichiers d’exécution

Dans cette étape, vous allez construire le programme dans une étape et ne livrer que son exécutable et ses ressources d’exécution dans une autre. Commencez dans Workstation, dans le même répertoire de projet. Une étape commence par une instruction FROM. La nommer avec AS build permet ensuite à COPY --from=build de récupérer un résultat sans hériter du compilateur ni des couches précédentes du système de fichiers.

Examinez d’abord une véritable livraison incomplète. Le fichier fourni Dockerfile.incomplete compile le programme et copie les illustrations publiques, mais omet les données des sentiers :

cat Dockerfile.incomplete

L’option -f sélectionne cet autre Dockerfile :

docker build -f Dockerfile.incomplete -t trail-guide:incomplete .

La construction réussit car la compilation ne lit pas la collection de sentiers. L’exécution suivante doit volontairement échouer avec le code de sortie 1 :

docker run --rm trail-guide:incomplete

Lisez l’erreur : open content/trails.json: no such file or directory. L’exécutable existe, mais ses données d’exécution manquent. Une construction réussie et une application complète sont deux résultats différents. Le conteneur temporaire ayant échoué a été supprimé. Corrigez le Dockerfile normal, plutôt que de réparer ce conteneur ou de modifier l’application.

Un here-document enregistre un bloc de texte complet. Ci-dessous, cat fournit les lignes, > écrit Dockerfile, et <<'DOCKERFILE' délimite un bloc littéral terminé par une ligne contenant uniquement DOCKERFILE. Les apostrophes du marqueur d’ouverture empêchent les substitutions du shell pendant l’enregistrement. Remplacez uniquement le Dockerfile modifiable :

cat > Dockerfile <<'DOCKERFILE'
FROM dk02-go-builder:1 AS build
WORKDIR /src
COPY app/main.go ./main.go
RUN CGO_ENABLED=0 go build -trimpath -o /out/guide main.go

FROM scratch
WORKDIR /guide
COPY --from=build /out/guide ./guide
COPY content/ ./content/
COPY public/ ./public/
ENTRYPOINT ["/guide/guide"]
DOCKERFILE

Suivez les fichiers : la première étape compile le source dans /out/guide. Le second FROM part de scratch, la base au système de fichiers vide de Docker, sans hériter de la première étape. L’exécutable devient /guide/guide ; les données et fichiers GPX conservent leur organisation content ; les styles et illustrations conservent leur organisation public. Le programme lit ces chemins relatifs depuis son répertoire de travail. Voilà pourquoi copier seulement l’exécutable ne suffisait pas.

L’image finale ne contient ni shell ni compilateur. C’est prévu ici. Inspectez son application plutôt que d’essayer d’y exécuter un shell.

Le contexte de construction est une question distincte. .dockerignore exclut les chemins correspondants avant de les envoyer au constructeur. Le point initial en fait un nom de fichier caché. Ces règles excluent les brouillons et le cache périmé sans exclure l’application ni ses ressources d’exécution :

cat > .dockerignore <<'IGNORE'
author-notes/
build-cache/
IGNORE

Le Dockerfile à deux étapes sélectionne explicitement les fichiers d’exécution ; le fichier d’exclusion évite aussi d’envoyer des éléments inutiles. Exclure un fichier du contexte ne peut pas retirer des octets déjà stockés dans des couches héritées. C’est l’étape d’exécution séparée qui laisse de côté les couches de construction.

Construisez l’image à livrer :

docker build -t trail-guide:lean .

docker image inspect trail-guide:lean --format '{{.Size}}'

Comparez sa taille avec celle de l’exemple. Le résultat utile est un environnement d’exécution plus petit avec un guide complet, pas le nombre le plus faible possible. Si une instruction COPY échoue, lisez le chemin source manquant et comparez-le au tableau d’organisation et au répertoire courant. Corrigez le Dockerfile ou la règle d’exclusion, puis reconstruisez. Ne créez pas de données de remplacement et ne montez pas le dossier source pour masquer une image incomplète.

Exécuter et recréer le guide livré

Dans cette étape, vous allez exécuter l’image indépendamment du dossier source et utiliser le guide complet. Commencez dans Workstation. Le programme écoute sur le port 8080 du conteneur. Publier 8090:8080 le rend accessible sur le port 8090 de Workstation, affiché par Your Guide. -d laisse le serveur en arrière-plan ; --name nomme ce conteneur du cours. N’ajoutez pas de montages : l’image doit contenir ses propres ressources.

docker run -d --name trail-guide -p 8090:8080 trail-guide:lean

La sortie est un identifiant de conteneur. Ce conteneur reste actif pour servir le guide. docker logs lit la sortie du programme ; --tail 5 la limite aux cinq dernières lignes :

docker logs --tail 5 trail-guide

Vous devez voir Guide listening on :8080, le port du conteneur plutôt que le port publié sur l’hôte. Si le nom du conteneur est déjà utilisé par un essai antérieur, utilisez la commande de suppression limitée au cours ci-dessous, puis relancez la commande de démarrage. Une erreur de ressource manquante impose d’abord de corriger le Dockerfile et de reconstruire.

Passez à Your Guide et rechargez. Les quatre sentiers doivent apparaître. Sélectionnez Easy : seuls Cedar Loop et River Walk apparaissent. Ouvrez Cedar Loop, examinez ses informations et sa carte, puis téléchargez son GPX. Utilisez Back to trails, choisissez Moderate, ouvrez Ridge Path et téléchargez aussi cet itinéraire. Revenez à tous les sentiers. Les illustrations et styles locaux doivent se charger, et les traces doivent correspondre aux sentiers sélectionnés. Reference Guide reste disponible indépendamment.

Démontrez maintenant le remplacement du conteneur avec la même image. Passez à Workstation. docker rm -f arrête et supprime uniquement le conteneur nommé du cours ; l’image n’est pas supprimée. Laissez dk02-reference en cours d’exécution :

docker rm -f trail-guide

Créez une nouvelle instance sans montage :

docker run -d --name trail-guide -p 8090:8080 trail-guide:lean

Passez à Your Guide, rechargez et répétez les visites et téléchargements Easy/Cedar Loop et Moderate/Ridge Path. Ce nouveau conteneur n’a jamais reçu le dossier source du poste de travail. Son environnement d’exécution provient de l’image.

Laissez le conteneur en cours d’exécution. Après de futures modifications du Dockerfile, reconstruire une étiquette ne met pas à jour un conteneur existant ; supprimez et recréez uniquement votre conteneur du cours pour exécuter la nouvelle image. Un service arrêté ou un échec de connexion diffère de la page Trail not found du guide pour un itinéraire inconnu.

Résumé

Vous avez séparé une étape de compilation d’une étape d’exécution vide, copié les ressources réellement nécessaires à l’application et exclu les brouillons du contexte de construction. Votre image allégée fournit l’ensemble de la collection, des filtres, des détails, des illustrations et des téléchargements GPX sans montage depuis le poste de travail. Recréer son conteneur a montré que l’image constitue une livraison réutilisable, et non un processus qui emprunte le dossier source.