Introduction
Paper & Pine doit maintenant terminer un programme communautaire de douze pages avant de s’arrêter. Son entrée transmet déjà correctement SIGTERM, mais un délai Compose d’une seconde interrompt le worker avant que son véritable PDF soit complet. Définissez un délai fini et réutilisable avec une marge suffisante, sans démarrer la tâche suivante.
Terminez d’abord Deliver the Stop Signal, ou connaissez son shell d’entrée, PID 1, la distinction TERM/KILL, les observations de tâches et les commandes Compose de base. Ce TP indépendant prépare son propre programme, PDF antérieur, file d’essai et file de livraison. Aucun fichier de VM précédente, programmation Python ou imprimante physique n’est requis.
Utilisez Workstation et Print Desk. La pause après la première page et le ralentissement de 0,5 seconde entre les pages restantes sont des comportements pédagogiques annoncés. Le délai d’arrêt commence avec la demande d’arrêt, pas quand le worker entre pour la première fois en pause. Prévoyez environ 45 minutes, lecture et erreurs ordinaires comprises ; il s’agit d’une estimation de l’auteur.
Laisser au programme courant le temps de se terminer
Dans cette étape, vous allez distinguer une transmission réussie du signal d’un temps de réalisation suffisant, puis terminer la tâche de livraison d’origine dans un délai Compose fini.
Identifier le travail et le budget actuel
Commencez dans Print Desk. Sous Delivery attempt, prévisualisez et téléchargez le document terminé Morning welcome handout. Le programme courant Community open day programme nécessite douze véritables pages PDF ; Volunteer notes est une tâche suivante qui doit rester en attente. L’essai et la livraison sont des files pédagogiques distinctes avec des fichiers séparés.
Passez à Workstation, qui démarre dans /home/labex/project/print-grace :
cd /home/labex/project/print-grace
cat entry.sh
cat compose.yaml
L’entrée utilise déjà exec python3 -B /app/worker.py : le worker fourni remplace donc le shell et reçoit la demande TERM de Docker. Le problème est stop_grace_period: 1s. Une fois la pause pédagogique terminée, onze intervalles restants de 0,5 seconde chacun, plus la finalisation du PDF, nécessitent davantage. Attendre plus longtemps avant de demander l’arrêt n’ajoutera rien au délai : le worker attend volontairement TERM avant d’achever sa tâche.
Conservez inchangés l’image préparée, les identifiants utilisateur, les montages, le programme d’entrée et les autres paramètres Compose. Vous ajusterez uniquement le budget d’arrêt fini ; une attente illimitée n’est pas le résultat souhaité.
Observer un véritable essai tronqué
Démarrez le projet d’essai fourni :
docker compose -f compose.trial.yaml -p print-trial up -d --pull never --no-build
Passez à Print Desk, rechargez et attendez que Practice attempt affiche sa pause pédagogique après la première page. Revenez à Workstation et demandez son arrêt avec un délai d’une seconde :
docker compose -f compose.trial.yaml -p print-trial stop worker
docker inspect print-trial --format '{{.State.ExitCode}}'
docker logs print-trial
L’opération d’arrêt Docker peut renvoyer 0, alors que le code de sortie du worker vaut 137. Contrairement à l’échec du mauvais shell du TP précédent, ce journal inclut stop-received et peut contenir certains événements de pages restantes, mais aucun PDF complet de douze pages ni terminaison normale. La transmission du signal a fonctionné ; le délai a expiré pendant le travail restant réel.
Passez à Print Desk et rechargez. L’essai n’a pas de téléchargement finalisé du programme courant. Les PDF antérieurs et la file de livraison intacte restent préservés. Ne lancez pas un autre processus pour compléter le PDF manquant : le worker d’origine doit terminer lui-même le document.
Enregistrer une surcharge Compose finie avant le démarrage de la livraison
Passez à Workstation. Une petite surcharge permet de préserver le fichier de base fourni et de ne changer que le budget d’arrêt. Deux arguments -f combinent les fichiers dans l’ordre ; la propriété ultérieure services.worker.stop_grace_period remplace uniquement cette propriété. Utilisez la même paire pour examiner la configuration, démarrer et arrêter.
Choisissez un délai fini en secondes entières ne dépassant pas 30 secondes. Quinze secondes donnent à ce programme pédagogique annoncé de la marge pour ses pages restantes et la surcharge ordinaire d’ordonnancement. C’est une marge pratique, pas l’affirmation que tous les PDF de production se terminent dans ce délai.
Utilisez le here-document littéral enseigné dans le premier TP guidé pour enregistrer compose.stop.yaml :
cat > compose.stop.yaml <<'COMPOSE'
services:
worker:
stop_grace_period: 15s
COMPOSE
docker compose -f compose.yaml -f compose.stop.yaml -p print-delivery config
Repérez stop_grace_period: 15s dans la configuration effective. L’image préparée, l’utilisateur numérique, le script d’entrée et l’entrée en lecture seule restent identiques. Si l’indentation YAML est incorrecte, corrigez le petit bloc et analysez de nouveau avant de démarrer. Un fichier modifié ne réécrit pas les paramètres par défaut d’un conteneur déjà créé ; enregistrez donc ce budget avant de démarrer la livraison.
Démarrez la livraison avec cette même paire de fichiers :
docker compose -f compose.yaml -f compose.stop.yaml -p print-delivery up -d --pull never --no-build
Passez à Print Desk, rechargez et attendez que Delivery attempt affiche la pause pédagogique. Passez ensuite à Workstation et utilisez la même configuration effective pour l’arrêter :
docker compose -f compose.yaml -f compose.stop.yaml -p print-delivery stop worker
docker inspect print-delivery --format '{{.State.ExitCode}}'
docker logs print-delivery
Le worker doit se terminer avec 0 après stop-received, les douze événements de pages, completed pour la tâche courante et worker-stopped. Son identité d’exécution et de processus reste la même entre la réception de la demande et la fin du programme. Conservez ce conteneur arrêté ; ne le supprimez pas comme raccourci de nettoyage.
Utiliser le PDF complet et préserver les autres travaux
Passez à Print Desk, rechargez et sélectionnez Preview text du programme courant sous Delivery attempt. L’aperçu décode le véritable PDF enregistré. Examinez la première et la dernière page, ainsi que tous les titres de sections et numéros de pages intermédiaires. Téléchargez le programme et ouvrez ses douze pages. Revenez au bureau et confirmez que le document du matin est inchangé et que Volunteer notes reste en attente sans PDF.
La livraison dispose maintenant d’un worker arrêté normalement et d’un véritable téléchargement de douze pages. L’essai reste visiblement en échec, tandis que la tâche suivante attend :
Les vérifications associent les faits Docker réels de TERM et de sortie, l’identité du worker d’origine, le contenu réel des pages décodées et la préservation de la file. Une réexécution jetable teste l’entrée enregistrée et le délai fini effectif sur un autre programme. Elle n’envoie pas de signal à votre worker réel et ne le répare pas.
Récupérer après une livraison infructueuse
Si votre tentative de livraison échoue, gardez le conteneur arrêté assez longtemps pour lire ses journaux et son code de sortie. Corrigez uniquement la configuration d’entrée ou du délai. L’action de récupération fournie refuse un conteneur actif ou terminé avec succès ; pour un worker du cours arrêté en échec, elle remet uniquement la tâche courante en file et conserve les artefacts échoués dans delivery/attempt-history/. Elle préserve le PDF antérieur, les entrées d’origine et la tâche suivante en attente :
python3 /opt/labex/dk05/source/retry.py
Après cette récupération explicite, supprimez uniquement les conteneurs du projet de livraison échoué avec docker compose -p print-delivery down, puis répétez la séquence affichée : démarrage de livraison, attente de la pause et arrêt. Aucun PDF source n’est régénéré, et cette récupération n’est jamais exécutée par un onglet ou une vérification de score. Ne réinitialisez pas la VM et ne changez pas le JSON de la file pour masquer un essai échoué.
Résumé
Vous avez distingué la réception d’une demande d’arrêt du temps nécessaire pour achever une tâche. Un délai Compose fini enregistré a permis au worker d’origine de terminer les douze pages PDF, de se terminer normalement et de préserver à la fois la sortie antérieure et la tâche suivante en attente.
