Séparer les réservations d’essai du service actif

Introduction

STILL STUDIO organise de petits ateliers de poterie. Les participants choisissent un atelier, réservent une place et retrouvent leur nom sur la liste. L’équipe veut essayer une session dans Garden Room sans prendre de places sur la liste réelle de Riverside Room. Vous allez créer un environnement de préproduction pour la même application : un site d’essai clairement identifié, avec des données de réservation distinctes.

Les bases du terminal suffisent. Docker Compose, la configuration, les chemins, les ports et les volumes de données sont expliqués ici. L’application et son image sont fournies ; vous n’écrivez pas de code et n’installez pas d’outils. Toutes les réservations sont fictives. Aucun courriel, paiement, compte externe ou renseignement personnel réel n’est utilisé.

Utilisez Live Bookings pour le site préparé sur le port 8081, Preview Bookings pour votre préproduction sur le port 8082 et Workstation pour les commandes. Preview Bookings est indisponible jusqu’à son démarrage à l’étape 2. Cette unité commence indépendamment.

Découvrir le service et configurer la préproduction

Dans cette étape, vous suivrez le parcours normal de réservation, puis préparerez un ensemble de paramètres distinct. Commencez dans Live Bookings.

Réserver une place sur le service normal

L’accueil présente l’atelier et affiche LIVE BOOKINGS, Riverside Room et 4 of 6 places left. Sélectionnez Explore the clay workshop. La page décrit la session et contient le champ Guest name. Saisissez le nom fictif Live guest, puis sélectionnez Reserve a place.

Le navigateur ouvre Guest list avec Maria, Jun et Live guest. Le nombre restant devient 3 of 6 places left. Il s’agit d’une véritable écriture en base, pas d’un message de réussite décoratif. Sélectionnez STILL STUDIO pour revenir à l’accueil. Conservez les trois réservations.

Si vous soumettez deux fois le même nom par erreur, le site indique que la réservation existe et n’en ajoute pas d’autre. Si vous avez mal saisi votre propre nom, ouvrez Guest list, sélectionnez Cancel uniquement à côté de votre réservation erronée et réservez à nouveau avec Live guest. N’annulez jamais Maria ou Jun et ne videz pas toute la liste pour corriger une faute.

Comprendre la frontière de configuration

Passez dans Workstation, déjà situé dans /home/labex/project/booking. Un chemin désigne un fichier ou un répertoire. pwd affiche le répertoire courant et ls en liste le contenu :

pwd

/home/labex/project/booking

ls

Vous devriez voir compose.yaml et live.env. cat affiche un fichier texte :

cat live.env

PORT=8081
APP_ENV=live
VENUE=Riverside Room
CAPACITY=6
DATA_VOLUME=still-live-data

La configuration fournit des choix à une application sans modifier son code. Ces lignes KEY=value choisissent le port publié, l’indication d’environnement, le lieu, la capacité et le volume de données. VENUE modifie le lieu réel affiché sur tout le site. CAPACITY limite les réservations acceptées au lieu de modifier seulement une étiquette.

Docker exécute une application dans un conteneur créé à partir d’une image enregistrée. Les deux sites utiliseront l’image fournie still-booking:1. Chaque conteneur reçoit ses propres variables d’environnement lors de sa création. Un volume nommé conserve la base hors du conteneur remplaçable. Plusieurs conteneurs peuvent partager un volume : un nom de conteneur différent ne sépare donc pas leurs enregistrements à lui seul.

Les ressources préparées sont :

Le nom du volume choisit un stockage réel. Ne sélectionnez jamais le volume actif pour les réservations d’essai.

Comprendre le petit fichier Compose

Docker Compose décrit des conteneurs liés dans un fichier YAML. YAML regroupe les paramètres par indentation : conservez l’espacement fourni et utilisez des espaces plutôt que des tabulations. Lisez le fichier fourni :

cat compose.yaml

Sous services, booking utilise still-booking:1. La section environment transmet les valeurs à l’application. ${VENUE} signifie que Compose remplace la valeur appelée VENUE avant de créer le conteneur. Un fichier d’environnement alimente cette substitution ; il ne modifie pas automatiquement un processus déjà lancé.

ports établit la correspondance ${PORT}:8000 : le nombre avant les deux-points est le port publié de l’instance du laboratoire ; 8000 est celui où l’application écoute dans le conteneur. Les deux sites nécessitent des ports publiés distincts.

Le service monte booking-data dans /data, où l’application conserve sa base. L’entrée de volume de premier niveau résout cet alias en ${DATA_VOLUME}. external: true signifie que le volume existe déjà et que Compose doit utiliser cette ressource précise. Un nom de projet regroupe les conteneurs Compose ; il ne renomme pas un volume externe sélectionné explicitement.

Écrire et résoudre les valeurs de préproduction

Ne modifiez pas live.env. Créez preview.env avec les valeurs ci-dessous. cat > preview.env remplace ce fichier. Le ENV entre guillemets ouvre un here-document : collez tout le bloc, y compris le dernier ENV sur sa propre ligne. Les guillemets préservent le texte littéralement.

cat > preview.env <<'ENV'
PORT=8082
APP_ENV=staging
VENUE=Garden Room
CAPACITY=3
DATA_VOLUME=still-trial-data
ENV

Un port identifie un service réseau. Ici, 8082 appartient à Preview Bookings ; 8081 reste Live Bookings. APP_ENV=staging active l’indication visible d’essai. Cette valeur ne choisit pas, à elle seule, un stockage distinct : c’est le rôle de DATA_VOLUME.

--env-file preview.env indique les valeurs à substituer. -p still-preview sélectionne le projet. config affiche la configuration résolue sans démarrer ni modifier de conteneurs :

docker compose --env-file preview.env -p still-preview config

Retrouvez APP_ENV: staging, VENUE: Garden Room, la capacité 3, le port publié 8082 et le volume still-trial-data. La mise en forme varie selon la version de Compose. Les valeurs résolues constituent la preuve, pas seulement la réussite de la commande.

Si Compose signale une variable ou un fichier absent, vérifiez pwd et cat preview.env, corrigez l’orthographe en répétant le here-document complet, puis relancez config. Si le shell exporte déjà une variable comme VENUE, elle peut prévaloir sur le fichier. unset VENUE supprime cette valeur du shell ; appliquez cette méthode seulement à une clé conflictuelle que vous avez volontairement exportée. Ne démarrez pas la préproduction avant que les valeurs résolues soient correctes.

Démarrer la préproduction et tester sa capacité réelle

Dans cette étape, vous démarrerez la copie de préproduction et prouverez que ses réservations utilisent une liste distincte. Commencez dans Workstation.

Démarrer l’application configurée

up crée ou met à jour les conteneurs du projet. -d les laisse tourner en arrière-plan tout en gardant le terminal disponible :

docker compose --env-file preview.env -p still-preview up -d

La sortie nomme le conteneur créé. ps affiche l’état réel du projet et son port publié :

docker compose --env-file preview.env -p still-preview ps

Repérez le service booking en cours d’exécution et le port 8082 relié à 8000. Si le démarrage échoue, logs affiche les messages de l’application :

docker compose --env-file preview.env -p still-preview logs

Un volume externe indisponible indique souvent une faute dans le nom de ressource. Corrigez preview.env, relancez config, puis up -d. Ne créez pas un volume de remplacement pour masquer une cible erronée. Un conflit de port signifie souvent que vous avez choisi le port actif : préservez 8081 et utilisez 8082 pour cette préproduction.

Effectuer une réservation d’essai

Passez dans Preview Bookings et rechargez si nécessaire. L’accueil doit afficher STAGING · TEST BOOKINGS ONLY, Garden Room et 3 of 3 places left. Sélectionnez Explore the clay workshop, saisissez Trial guest, puis Reserve a place. Guest list affiche maintenant seulement Trial guest, avec 2 of 3 places left.

Passez dans Live Bookings, sélectionnez Guest list et rechargez. La liste doit toujours contenir Maria, Jun et Live guest, avec 3 of 6 places left. Si des données d’essai apparaissent ici, cessez d’ajouter des réservations d’essai. Dans Workstation, corrigez le volume de préproduction, appliquez up -d, puis annulez uniquement votre réservation d’essai identifiable dans la liste active. Préservez toutes les réservations légitimes. Ouvrez Preview Bookings et créez-y Trial guest après correction de l’isolation.

Cette comparaison compte davantage que l’indication d’environnement. Une étiquette staging avec une base partagée consommerait quand même les places réelles.

Tester la capacité réduite

Restez dans Preview Bookings. Suivez Back to the workshop et réservez Capacity A. Revenez à l’atelier et réservez Capacity B. La liste compte alors trois participants et 0 of 3 places left.

Essayez une réservation supplémentaire, Overflow guest. La page doit indiquer Every place is taken. et No booking was added. Suivez View the guest list : Overflow guest doit être absent. La capacité réduite a changé le comportement de l’application.

Annulez uniquement Capacity A et Capacity B, en conservant Trial guest. La préproduction revient à 2 of 3 places left. En cas de faute de nom, annulez cette réservation d’essai précise et recommencez ; inutile de vider la base. Revenez dans Live Bookings et confirmez que sa liste et ses places restantes n’ont pas changé.

Comparer les résultats lisibles par une machine

Passez dans Workstation. HTTP est le protocole de requête et de réponse du navigateur. curl envoie une requête ; -sS masque la progression et affiche les erreurs de connexion. Depuis Workstation, 127.0.0.1 désigne cette instance du laboratoire. Une URL combine protocole, adresse, port et chemin de ressource. /api/info renvoie la configuration réelle et la liste de la base en JSON, un format de texte structuré. Aucun langage de requête n’est nécessaire.

curl -sS http://127.0.0.1:8081/api/info

Lisez live, Riverside Room, la capacité 6, le nombre restant 3 et les trois noms du service actif. Les identifiants peuvent varier.

curl -sS http://127.0.0.1:8082/api/info

Lisez staging, Garden Room, la capacité 3, le nombre restant 2 et seulement Trial guest. Ce sont deux points d’accès distincts, pas deux étiquettes sur une même liste.

Remplacer la préproduction sans perdre ses réservations

Dans cette étape, vous remplacerez le conteneur de préproduction et confirmerez la conservation de ses données distinctes. Commencez dans Workstation.

Vérifier le montage réel du stockage

ps -q affiche uniquement l’identifiant du conteneur du projet. docker inspect lit les paramètres réels d’un conteneur. --format sélectionne un champ ; le modèle entre guillemets convertit les montages en JSON. L’expression shell $(...) exécute la commande intérieure et insère sa sortie comme argument du conteneur :

docker inspect $(docker compose --env-file preview.env -p still-preview ps -q booking) --format '{{json .Mounts}}'

Repérez un montage de type volume, nommé still-trial-data, avec pour destination /data. Un autre nom de projet ne protégerait pas les données actives si ce montage désignait still-live-data.

Recréer uniquement le conteneur de préproduction

--force-recreate demande à up de remplacer le conteneur même si sa configuration est inchangée. Les volumes nommés montés restent présents. Cela montre aussi comment la configuration atteint un nouveau processus : modifier seulement le fichier d’environnement ne mettrait pas à jour un conteneur déjà lancé.

docker compose --env-file preview.env -p still-preview up -d --force-recreate

Attendez que ps affiche le service en cours d’exécution :

docker compose --env-file preview.env -p still-preview ps

Passez dans Preview Bookings et rechargez Guest list. Trial guest doit rester dans Garden Room, avec 2 of 3 places left. Passez dans Live Bookings et rechargez sa liste. Maria, Jun et Live guest doivent rester dans Riverside Room, avec 3 of 6 places left. Ni le remplacement du conteneur ni une réservation d’essai ne doit effacer l’autre environnement.

N’utilisez pas la suppression de volumes ou down -v pour récupérer le service. Si la préproduction ne démarre pas, utilisez logs du même projet, corrigez les valeurs et appliquez à nouveau up -d. L’environnement actif préparé est hors de votre périmètre de modification.

Vérifier ensemble les pages et les réponses

Dans Preview Bookings, sélectionnez STILL STUDIO, ouvrez l’atelier puis Guest list. L’illustration locale, les détails et la navigation doivent fonctionner. Un accueil réussi ne représente pas l’ensemble du service de réservation.

Passez dans Workstation. Le statut HTTP 200 indique une réponse réussie ; 404 signifie que le chemin demandé n’existe pas. -o /dev/null élimine le corps de la réponse ; -w affiche le format entre guillemets. %{http_code} est le statut HTTP et \n termine sa ligne :

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8082/bookings

Le résultat attendu est 200 ; confirmez aussi la bonne liste dans le navigateur. Un 200 contenant la mauvaise page ne suffit pas.

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/workshop

Attendez 200 : l’atelier actif reste disponible. Un échec de connexion diffère d’une réponse HTTP d’erreur ; inspectez ps et logs si aucun serveur ne répond. Vous avez maintenant une image, deux processus configurés indépendamment et deux listes de participants distinctes et durables. C’est une isolation pédagogique sur une seule instance, pas une frontière de sécurité face à un administrateur ayant accès à Docker.

Résumé

Vous avez configuré et démarré une copie de préproduction de la même application, choisi un volume nommé distinct, testé sa capacité réelle et comparé les deux listes. Recréer la préproduction a conservé sa réservation, tandis que le service actif a gardé ses participants d’origine. Une autre étiquette ou un autre projet Compose facilitait l’organisation ; la cible réelle des données établissait l’isolation.