Ouvrir le catalogue après l’importation

DockerBeginner
Pratiquer maintenant

Introduction

The Riverside Archive peut se connecter à PostgreSQL, mais son site de catalogue démarre avant la fin de l’importation ponctuelle. Ajoutez la dépendance métier manquante : le catalogue ne peut ouvrir qu’après une importation réussie et doit rester non démarré si l’entrée est invalide.

Terminez d’abord Wait for the Archive Database, ou connaissez son YAML, ses contrôles de santé, ses projets Compose, ses journaux et son redémarrage avec données neuves limité au périmètre du cours. Aucune programmation SQL ou applicative n’est requise. Ce TP prépare une base, des données sources et une référence indépendantes ; aucun fichier de VM précédente n’est nécessaire. La base initiale fournie possède déjà le bon contrôle de santé TCP final.

Utilisez Workstation, Reference Archive, Your Archive et Collection Notes. Les témoignages sont synthétiques. Les délais annoncés exposent les états pédagogiques ; la disponibilité réelle et les codes de sortie d’importation déterminent le résultat. Prévoyez environ 45 minutes, lecture et erreurs ordinaires comprises ; il s’agit d’une estimation de l’auteur.

Ouvrir uniquement après une importation réussie

Dans cette étape, vous allez conditionner le catalogue à une importation terminée, prouver qu’un véritable échec le bloque, puis récupérer avec l’entrée d’origine.

Comparer la disponibilité de la base et celle des données métier

Commencez dans Reference Archive. Recherchez Market morning, ouvrez les deux fiches correspondantes et téléchargez leurs transcriptions distinctes. Revenez avec Back to collection et examinez Ferry voices. Your Archive est indisponible, tandis que Collection Notes peut déjà présenter la collection sans lire de lignes importées.

Passez à Workstation, qui démarre dans /home/labex/project/archive-opening :

cd /home/labex/project/archive-opening
cat compose.yaml
docker compose -p archive ps -a
docker compose -p archive logs importer catalog

La base devient saine et l’importateur termine son travail réel. Mais le catalogue a tenté de lire la table trop tôt et s’est arrêté avec une erreur telle que relation "entries" does not exist. Une base qui accepte les connexions ne signifie pas que les données applicatives existent. Le site n’a volontairement aucune nouvelle tentative de démarrage cachée : la dépendance doit donc exprimer cette exigence.

Cet environnement utilise les mêmes quatre rôles et relations de ports que le TP guidé précédent. db possède déjà un contrôle de santé TCP et importer attend service_healthy. Le problème restant est catalog.depends_on.importer.condition: service_started. Cette condition permet au catalogue de démarrer dès le début du processus d’importation, alors que son délai pédagogique annoncé de six secondes et sa transaction réelle n’ont pas encore eu lieu.

Conditionner le véritable consommateur

Remplacez cette condition par service_completed_successfully. Elle vérifie la fin réussie, et pas simplement la fin du processus : un code d’importation non nul doit bloquer le catalogue. Un importateur ponctuel Exited 0 est correct et ne doit pas être maintenu à l’état Running ni recevoir une politique de redémarrage sans fin. Gardez welcome indépendant, car ses notes statiques sur la collection n’ont pas besoin de table importée.

Le here-document littéral complet préserve tous les paramètres fournis et le contrôle de santé existant de la base. Comme dans le TP précédent, > remplace uniquement compose.yaml ; le marqueur entre apostrophes maintient le contenu littéral :

cat > compose.yaml <<'COMPOSE'
services:
  db:
    image: dk04-postgres:16
    environment:
      POSTGRES_USER: archivist
      POSTGRES_PASSWORD: training-archive
      POSTGRES_DB: archive
      TRAINING_DB_DELAY: "8"
    volumes:
      - data:/var/lib/postgresql/data
      - ./scenario/slow-init.sh:/docker-entrypoint-initdb.d/10-training-delay.sh:ro
    healthcheck:
      test: ["CMD", "pg_isready", "-h", "127.0.0.1", "-U", "archivist", "-d", "archive"]
      interval: 1s
      timeout: 2s
      retries: 40
  importer:
    image: dk04-archive:1
    entrypoint: ["python3", "-B", "/app/importer.py"]
    environment:
      PGHOST: db
      PGUSER: archivist
      PGPASSWORD: training-archive
      PGDATABASE: archive
      TRAINING_IMPORT_DELAY: "6"
    volumes:
      - ./scenario:/scenario:ro
    depends_on:
      db:
        condition: service_healthy
  catalog:
    image: dk04-archive:1
    entrypoint: ["python3", "-B", "/app/archive.py", "catalog"]
    environment:
      PGHOST: db
      PGUSER: archivist
      PGPASSWORD: training-archive
      PGDATABASE: archive
      ARCHIVE_TITLE: "The Riverside Archive"
    ports:
      - "8090:8080"
    depends_on:
      importer:
        condition: service_completed_successfully
  welcome:
    image: dk04-archive:1
    entrypoint: ["python3", "-B", "/app/archive.py", "notes"]
    environment:
      ARCHIVE_TITLE: "The Riverside Archive"
    ports:
      - "8091:8080"
volumes:
  data:
    labels:
      labex.course: dk04
COMPOSE
docker compose -p archive config

Si l’analyse échoue, corrigez l’indentation signalée à l’aide du bloc affiché avant de démarrer les services. Conservez inchangés l’application, l’importateur, le CSV, l’authentification et les ports fournis.

Prouver qu’une importation échouée ne peut pas ouvrir le catalogue

compose.bad.yaml est un fichier de surcharge fourni qui dirige l’importateur vers un CSV invalide distinct. Son identifiant de fiche contient du texte là où la table PostgreSQL réelle exige un entier. L’importateur utilise une véritable transaction et propage le code non nul de la base ; il ne simule pas une réussite. Le scénario valide d’origine reste intact.

Examinez d’abord le volume de l’apprenant et confirmez les étiquettes de projet et de cours comme appris précédemment :

docker volume inspect archive_data --format '{{json .Labels}}'

Les valeurs attendues sont com.docker.compose.project: archive et labex.course: dk04. La commande suivante supprime délibérément uniquement les données pédagogiques jetables de ce projet, afin que le test d’entrée invalide ne puisse pas emprunter une table précédemment importée :

docker compose -p archive down --volumes

Deux arguments -f fusionnent la configuration normale et cette surcharge fournie, dans cet ordre. Le démarrage suivant doit volontairement échouer avec le code natif 1, car l’importateur se termine avec un code non nul :

docker compose -f compose.yaml -f compose.bad.yaml -p archive up -d --pull never --no-build
docker compose -f compose.yaml -f compose.bad.yaml -p archive ps -a
docker compose -f compose.yaml -f compose.bad.yaml -p archive logs importer

Lisez l’erreur d’entier invalide. La base peut rester saine, l’importateur est Exited avec un code non nul et le catalogue doit être Created, jamais démarré. Le service d’accueil reste actif. Un catalogue qui démarre puis plante donne un résultat différent : il a été autorisé à consommer une importation échouée.

Passez à Your Archive et rechargez : aucun catalogue ne doit être disponible. Passez à Collection Notes : sa page indépendante fonctionne toujours. Ce sont de véritables états de services, pas un affichage de réussite mis en scène.

Récupérer avec l’entrée valide et utiliser les fiches

Passez à Workstation. Vérifiez de nouveau les mêmes étiquettes de volume du cours avant le nettoyage :

docker volume inspect archive_data --format '{{json .Labels}}'
docker compose -f compose.yaml -f compose.bad.yaml -p archive down --volumes

Démarrez sans la surcharge pour revenir à l’entrée valide d’origine. Ce nouveau stockage de données doit importer à partir de zéro :

docker compose -p archive up -d --pull never --no-build
docker compose -p archive ps -a
docker compose -p archive logs importer

Vous devez obtenir une base Healthy, un importateur Exited 0 et les deux rôles web Running. Pour une erreur ordinaire de chemin manquant ou de YAML, revenez au répertoire de travail indiqué, lisez compose config ou le journal du service, corrigez la configuration modifiable et répétez uniquement le redémarrage limité à ce cours. Ne modifiez pas les lignes sources, ne masquez pas les erreurs et ne réinitialisez pas la VM pour cacher le problème.

Passez à Your Archive et rechargez. Recherchez Market morning : deux fiches doivent apparaître avec des identifiants, années, catégories et histoires différents. Ouvrez chacune et utilisez Download transcript, en revenant avec Back to collection. Recherchez Ferry, ouvrez Ferry voices et téléchargez sa transcription. Effacez la recherche pour afficher les quatre fiches. Examinez aussi The shared garden et son téléchargement. Une URL de fiche inconnue doit afficher Record not found, à distinguer d’un échec de connexion ou d’un catalogue indisponible.

Le catalogue complet conserve les quatre identités, y compris les deux fiches Market morning différentes :

Le catalogue importé après un démarrage à froid réussi

Passez à Collection Notes : sa page d’accueil indépendante doit rester disponible. Reference Archive doit toujours proposer la collection complète d’origine. Laissez votre archive finale active. Les vérifications observent d’abord votre base réelle, l’importation terminée et les résultats métier complets. Elles exécutent ensuite vos choix de santé et de dépendances inchangés dans de nouveaux stockages de données distincts et jetables, avec des délais pédagogiques annoncés différents et un échantillon d’importation invalide. Ces dispositifs n’initialisent ni ne réparent jamais votre archive réelle. Un test isolé distinct exécute aussi votre commande de santé inchangée sans aucun serveur de base ; elle doit refuser ce point de connexion indisponible.

Résumé

Vous avez distingué une base utilisable d’un catalogue produit avec succès. Le consommateur attend maintenant le code de sortie 0 de l’importateur, reste non démarré après un véritable échec d’importation et ouvre un nouveau catalogue complet après restauration de l’entrée valide. La page d’accueil indépendante reste utile tout au long du processus.