Recommencer ou nettoyer un lab dsoxlab : reset, clean, destroy

Trois commandes défont ce qu'un lab a fait, et elles ne vont pas aussi loin l'une que l'autre : reset remet le lab à son état de départ et efface les indices pris, clean supprime ce que le lab a créé, et destroy démonte les machines. Aucune ne touche à vos notes enregistrées. Cette leçon s'adresse à qui joue des labs et veut repartir de zéro sans perdre son historique, ou finir une séance sans laisser de machines consommer mémoire et disque.

Ce que vous allez apprendre

• Choisir entre reset, clean et destroy selon ce que l'on veut défaire.
• Dire ce que chaque commande laisse en place : indices, notes, machines.
• Repartir de zéro sur un lab shell et sur un lab vm.
• Confirmer ou refuser une suppression, au clavier ou avec --yes.
• Reconnaître les machines orphelines que destroy retire.

Prérequis

Il vous faut la CLI dsoxlab en version 0.8.0 ou plus récente et un lab déjà joué, comme le décrit la leçon Faire valider son travail. Pour destroy, un catalogue de labs vm dont les machines ont été montées par dsoxlab provision ou dsoxlab start, comme l'explique la leçon Démarrer un lab.

Quelle commande défait quoi : reset, clean ou destroy ?

reset remet le lab à zéro pour le rejouer, clean retire ce qu'il a créé, destroy ne parle pas du lab mais des machines. Le tableau ci-dessous dit, pour chaque commande, ce qu'elle défait et ce qu'elle laisse. Une note est ici le score que check a enregistré. Lisez la colonne « Notes enregistrées » : c'est la raison pour laquelle on peut s'en servir sans crainte pour son historique.

Commande	État du lab	Indices pris	Notes enregistrées	Machines
dsoxlab reset <id>	Remis à l'état initial, puis préparé à nouveau	Effacés	Conservées	Conservées
dsoxlab clean <id>	Ressources créées par le lab supprimées	Laissés	Conservées	Conservées
dsoxlab destroy	Plus rien à jouer sans reprovisionner	Laissés	Conservées	Détruites

Glissez pour voir

Trois commandes emportent en revanche vos notes avec le reste : dsoxlab demo --force, dsoxlab catalog remove et dsoxlab catalog add --force, puisque la progression vit dans le fichier .dsoxlab.db du catalogue. Elles effacent aussi les indices pris.

Une règle pratique résume le choix : pour recommencer le même lab, tapez reset ; pour libérer ce que le lab a laissé sans le rejouer, tapez clean ; pour finir la séance d'un lab vm, tapez destroy.

Comment repartir de zéro avec dsoxlab reset ?

dsoxlab reset <id> remet le lab dans l'état où run l'avait laissé au départ, et efface les indices que vous aviez pris. Il efface donc plus que clean, qui laisse les indices. Sur un lab shell, il vaut un clean suivi d'un redémarrage : le répertoire de travail est supprimé puis recréé avec les fichiers de départ du lab (ses fixtures), ce qui vide aussi vos fichiers, reponses/ pour le lab de démonstration premiers-pas.

Sur un lab vm, reset rejoue le playbook de nettoyage puis celui de préparation. Quand le lab exige un point de reprise disque (un instantané du disque de la machine), il ramène la machine à ce point puis rejoue la préparation.

dsoxlab reset epreuve-livrer-une-image

Avant de toucher à quoi que ce soit, reset pose une question et attend votre réponse. Voici ce qui s'affiche sur le lab vm epreuve-livrer-une-image quand on répond n :

$ dsoxlab reset epreuve-livrer-une-image
Réinitialiser le lab epreuve-livrer-une-image ? Le travail en cours est perdu. [y/N]: n
Aborted.

La question rappelle que le travail en cours est perdu, et [y/N] dit que la réponse par défaut est non : taper seulement Entrée annule aussi. La commande sort alors en code 1, et rien n'a été défait. Avec --yes, la question disparaît et le déroulé complet s'affiche. Sur ce lab vm, la sortie est longue : elle est abrégée ici pour montrer la forme :

$ dsoxlab reset epreuve-livrer-une-image --yes
ℹ Réinitialisation de epreuve-livrer-une-image…
  ✔ docker-client.lab: Gathering Facts (ok)
  ✔ docker.lab: Gathering Facts (ok)
  ✔ docker.lab: Retirer les conteneurs et les images de l'épreuve (ok)
[...]
  ✔ docker.lab: Retirer l'atelier et le relevé du banc (ok)
  ✔ docker-client.lab: Retirer l'atelier et le relevé du banc (ok)
  ✔ docker-client.lab: Gathering Facts (ok)
  ✔ docker.lab: Gathering Facts (ok)
  ✔ docker.lab: Installer les outils bornés (ok)
[...]
  ● docker.lab: Créer le fichier de livraison, vide, que la mission demande de
remplir (changed)
⠋ cleanup.yaml terminé ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 53/? 0:00:21
✔ Lab réinitialisé.

Lisez le déroulé en deux temps : les tâches de nettoyage (« Retirer… ») passent d'abord, puis celles de préparation (« Installer… », « Créer… ») repartent de zéro. C'est l'ordre annoncé plus haut : reset rejoue le nettoyage, puis la préparation. La puce pleine ● marque une tâche qui a changé quelque chose, la coche ✔ une tâche déjà conforme. La commande a pris environ vingt et une secondes sur le poste de test.

Sur un lab shell comme lire-du-code, la sortie tient en deux lignes :

$ dsoxlab reset lire-du-code --yes
ℹ Réinitialisation de lire-du-code…
✔ Lab réinitialisé.

Dans les deux cas, le critère de réussite est le message « Lab réinitialisé » : le lab est de nouveau dans son état de départ.

reset ne touche pas aux notes : dsoxlab status affiche la même chose avant et après, et un lab déjà noté reste « validé » avec sa meilleure note (100 / 100 pour lire-du-code). Les indices étant effacés, le coût de hint repart de zéro pour les prochains check ; les tentatives déjà enregistrées gardent pourtant la liste des indices que vous aviez vus à leur date.

Comment supprimer ce que le lab a créé avec dsoxlab clean ?

dsoxlab clean <id> supprime toutes les ressources que le lab a créées, y compris les conteneurs de ses services, et ne touche ni aux indices ni aux notes. Sur un lab shell, il joue le cleanup.yaml du lab s'il existe puis supprime le répertoire de travail. Sur un lab vm, il joue le playbook de nettoyage sur la machine cible et, quand le lab exige un point de reprise disque, retire ce point : la machine elle-même reste en place. Un lab vm sans playbook de nettoyage fait échouer la commande en code 2, avec un message qui nomme le fichier cleanup.yaml attendu.

dsoxlab clean epreuve-livrer-une-image

La question posée avant est « Supprimer les ressources du lab » suivie du nom du lab. Voici la réponse n sur le lab vm epreuve-livrer-une-image, puis le nettoyage réel avec --yes :

$ dsoxlab clean epreuve-livrer-une-image
Supprimer les ressources du lab epreuve-livrer-une-image ? [y/N]: n
Aborted.

$ dsoxlab clean epreuve-livrer-une-image --yes
ℹ Nettoyage de epreuve-livrer-une-image…
  ✔ docker-client.lab: Gathering Facts (ok)
  ✔ docker.lab: Gathering Facts (ok)
  ✔ docker-client.lab: Retirer les conteneurs et les images de l'épreuve (ok)
  ✔ docker.lab: Retirer les conteneurs et les images de l'épreuve (ok)
  ✔ docker.lab: Retirer le cache de construction, qui survivrait aux images (ok)
  ✔ docker-client.lab: Retirer le cache de construction, qui survivrait aux
images (ok)
  ✔ docker-client.lab: Rendre les deux images publiques du banc (ok)
  ✔ docker.lab: Rendre les deux images publiques du banc (ok)
  ● docker-client.lab: Retirer la confiance installée pour le moteur (changed)
  ● docker.lab: Retirer la confiance installée pour le moteur (changed)
  ● docker-client.lab: Retirer la résolution du registre (changed)
  ● docker.lab: Retirer la résolution du registre (changed)
  ● docker.lab: Retirer l'atelier et le relevé du banc (changed)
  ● docker-client.lab: Retirer l'atelier et le relevé du banc (changed)
⠹ cleanup.yaml terminé ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 14/? 0:00:03
✔ Nettoyage terminé.

Regardez les lignes ● : ce sont les tâches qui ont réellement retiré quelque chose, la confiance installée pour le moteur, la résolution du registre et l'atelier. Relancé aussitôt après, le même clean --yes passe toutes ses tâches en ✔ (ok), et conclut par le même « Nettoyage terminé » : clean se rejoue sans risque.

C'est aussi clean qui retire /opt/lab-livraison, l'atelier que le setup.yaml du lab refuse de trouver déjà posé. La leçon Démarrer un lab montre ce refus à l'étape 4 de start.

Sur un lab shell, la sortie est plus courte :

$ dsoxlab clean lire-du-code --yes
ℹ Nettoyage de lire-du-code…
✔ Nettoyage terminé.

clean ne touche pas non plus aux notes, et status ne change pas : un lab déjà noté reste « validé » avec sa meilleure note, et un lab sans note reste « en cours », puisque le marqueur de préparation survit au nettoyage. Ne lisez donc pas status comme un indicateur d'état de la machine : il dit où en est votre note.

La différence entre reset et clean se lit sur la machine, pas dans status. reset remet le lab à son départ, prêt à rejouer. clean le libère sans le rejouer.

Comment démonter les machines avec dsoxlab destroy ?

dsoxlab destroy détruit l'infrastructure du catalogue, après confirmation, y compris les machines orphelines. Une machine orpheline est une machine qu'un provision en échec a laissée hors de l'état Terraform, c'est-à-dire hors de la liste que Terraform tient de ses machines. C'est la commande de fin de séance sur un lab vm : sans elle, les machines consomment mémoire et disque bien après la fin du lab. La question posée nomme le provider (ce qui fait tourner les machines, ici kvm), et --yes la supprime.

dsoxlab destroy
dsoxlab destroy --yes
dsoxlab destroy --host docker.lab

Voici la question, avec la réponse n, puis la destruction réelle avec --yes sur les deux machines du catalogue containers :

$ dsoxlab destroy
Détruire toute l'infrastructure du provider kvm ? Les données des VM seront perdues [y/N]: n
Aborted.

$ dsoxlab destroy --yes
ℹ Destruction de l'infrastructure (provider : kvm)…

  ✔ host["docker.lab"] (1s)
  ✔ host["docker-client.lab"] (1s)
  ✔ cloudinit["docker.lab"] (0s)
  ✔ cloudinit["docker-client.lab"] (0s)
  ✔ host["docker-client.lab"] (0s)
  ✔ host["docker.lab"] (0s)
  ✔ host["docker-client.lab"] (0s)
  ✔ host["docker.lab"] (0s)
  ✔ lab (0s)
  ✔ base_image["debian13"] (0s)
  Destroying terminé ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 10/10 0:00:02
ℹ Fragment SSH de containers-dsoxlab-training retiré : il pointait des machines
détruites.
ℹ Le socle du catalogue est oublié : le prochain provision le reposera.
✔ Infrastructure détruite.

Regardez les trois dernières lignes. Le fragment SSH du catalogue est retiré (ssh <machine> ne marche plus), le socle du catalogue est oublié, donc le prochain provision le rejoue, et l'infrastructure est détruite. Le compteur 10/10 compte les ressources Terraform détruites, machines comprises.

La commande purge d'abord les points de reprise disque, puis joue terraform destroy. Elle contrôle ensuite l'hyperviseur (le logiciel qui fait tourner les machines virtuelles) : Terraform ne voit pas les machines orphelines, mais destroy les retire elles aussi, après une confirmation séparée. Elle nomme les machines, demande confirmation (sauf avec --yes) et, si l'une d'elles ne peut pas être retirée, sort en code 6 en donnant la commande sudo virsh undefine à taper à la main. Un destroy qui annoncerait un succès en laissant des machines debout serait pire qu'un échec.

L'option --host cible une machine, et il faut savoir ce qu'elle promet vraiment : Terraform détruit la cible et tout ce qui en dépend. Les volumes et les disques étant chaînés aux machines, cibler un hôte peut emporter les autres, et la commande l'avertit avant d'agir. destroy n'efface jamais vos notes ni vos indices : status redit « validé, 75 / 100 » sur un lab noté avant la destruction des machines.

Comment confirmer sans terminal, avec --yes ?

reset, clean et destroy demandent une confirmation, et --yes (ou -y) répond à votre place. Dans un script, sans terminal pour répondre, reset et clean sans --yes ne font rien : ils expliquent qu'ils ont besoin de --yes et sortent en code 2. Voici clean, lancé avec l'entrée standard branchée sur un tube :

$ dsoxlab clean epreuve-livrer-une-image
✘ Cette commande demande une confirmation, et il n'y a pas de terminal pour la
donner. Relancez-la avec --yes pour confirmer sans question.

Le message dit la cause (pas de terminal) et le remède (--yes), et la commande sort en code 2. Dans un script, ajoutez donc --yes aux trois commandes (les deux premières visent ici le lab de démonstration premiers-pas) :

dsoxlab reset premiers-pas --yes
dsoxlab clean premiers-pas --yes
dsoxlab destroy --yes

Réservez --yes aux scripts et aux cas où vous savez exactement ce qui sera supprimé. Au clavier, la question est une protection utile : un destroy tapé dans le mauvais dépôt effacerait tout le parc sans elle.

Un dernier point : ces trois commandes prennent un verrou d'écriture sur le catalogue, après la confirmation. Si une autre commande dsoxlab écrit déjà dans le même catalogue, vous obtenez le code 7 et le message nomme cette commande, qu'il suffit d'attendre.

Dépannage

Aucun de ces cas n'est une panne : la commande demande une confirmation, un verrou ou un fichier que le lab ne déclare pas.

Symptôme	Cause	Solution
clean ou reset sort en code 2 en parlant de --yes	Aucun terminal pour répondre à la confirmation	Relancer avec --yes
clean d'un lab vm échoue	Le lab ne déclare pas de playbook cleanup.yaml	Le signaler à l'auteur du catalogue ; destroy démonte les machines
destroy sort en code 6	Une machine orpheline n'a pas pu être retirée	Taper la commande sudo virsh undefine que le message donne
Une commande sort en code 7	Une autre commande dsoxlab écrit dans ce catalogue	Attendre la fin de la commande nommée, puis relancer
Les indices ont disparu après reset	reset efface les indices du lab	C'est voulu ; clean les aurait laissés
L'historique a disparu	demo --force, catalog remove ou catalog add --force	Prévenir : ces commandes emportent le .dsoxlab.db avec les notes

Glissez pour voir

À retenir

• reset remet le lab à son état initial et efface les indices pris ; clean supprime ce que le lab a créé et laisse les indices.
• Ni reset, ni clean, ni destroy ne touchent aux notes enregistrées.
• demo --force, catalog remove et catalog add --force emportent notes et indices.
• destroy démonte les machines, orphelines comprises, et sort en code 6 s'il en reste.
• destroy --host ne cible pas finement : Terraform détruit aussi ce qui dépend de la cible.
• --yes répond à la confirmation ; sans terminal et sans --yes, reset et clean sortent en code 2.
• Après destroy, le prochain provision rejoue le socle du catalogue.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →