Formation dsoxlab : jouer et valider les labs du site

dsoxlab est la ligne de commande qui fait tourner les labs des formations de ce site. Elle prépare un environnement jetable, vous confie une mission, puis vérifie l'état réel du système pour dire si la compétence est acquise et calculer un score. Elle s'installe en une commande, et le lab de démonstration livré avec elle ne demande ni machine virtuelle, ni conteneur, ni Docker.

Cette page vous fait jouer un lab complet de bout en bout, puis brancher les catalogues des formations. Elle ouvre aussi la formation dsoxlab : trois volets qui vont de l'installation à l'écriture de votre propre catalogue de challenges. Elle s'adresse à toute personne qui suit un parcours du site et veut prouver ce qu'elle sait faire, pas seulement le lire.

Ce que vous allez apprendre

Installer la CLI dsoxlab et vérifier que votre poste est prêt.
Jouer un lab complet sans provisionner la moindre machine.
Comprendre le modèle challenge, check, score, et le calcul de la note.
Brancher les catalogues de labs Linux, Ansible, Terraform et Kubernetes.
Diagnostiquer les deux erreurs qui reviennent le plus souvent au démarrage.
Situer chaque leçon de la formation, de l'appliance à la création d'un cours.

Prérequis

Il en faut peu, et c'est voulu : Python 3.11 ou plus récent, et l'un des deux installeurs d'outils Python, uv ou pipx. Rien à cloner, rien à compiler. Les labs qui réclament des machines virtuelles ont des prérequis supplémentaires, traités plus bas, mais aucun n'est nécessaire pour commencer.

Qu'est-ce qu'un lab vérifiable ?

Un lab vérifiable est un exercice dont la réussite se mesure sur l'état d'un système, par des tests automatiques, et non sur la lecture d'un corrigé. C'est ce que dsoxlab apporte aux formations de ce site : un quiz vérifie ce qu'on a compris, un lab vérifiable prouve ce qu'on sait faire, et les deux ne se remplacent pas.

dsoxlab est un moteur, pas un cours. Il lit un catalogue déclaratif : un fichier meta.yml à la racine dit ce que le catalogue offre, et un lab.yaml par lab dit ce que ce lab réclame. Le moteur provisionne ce qui est demandé, ouvre la session, puis exécute des tests.

Ces tests sont sa raison d'être. Ils lisent l'état du système, jamais les commandes tapées. Un lab qui exige un service actif vérifie que ce service tourne, peu importe le chemin emprunté pour y arriver. Cette règle a une conséquence agréable : toute façon de réussir compte, y compris celle que l'auteur du lab n'avait pas prévue.

En revanche, dsoxlab ne porte aucun contenu pédagogique propre. Les guides vivent sur ce site, les labs dans des dépôts compagnons, et le moteur ne sait rien de Linux, d'Ansible ou de Kubernetes en particulier.

Le modèle challenge, check, score

Chaque lab repose sur trois pièces, et chacune correspond à une commande. Le challenge est la mission, écrite dans challenge/README.md : elle dit ce qu'il faut produire, avec un barème annoncé tâche par tâche. Le check est la validation : dsoxlab check lance des tests pytest qui inspectent le système, puis enregistre le résultat. Le score part de 100 points, ou du barème que le lab déclare, et chaque indice pris en retire une part connue d'avance.

Deux détails de ce modèle méritent d'être sus avant de commencer. D'abord, un lab déclaré comme examen blanc porte un seuil de réussite, et dsoxlab submit rend alors un verdict réussi ou échoué face à ce seuil. Ensuite, tant que ni check ni submit n'a été lancé, rien n'est écrit : un lab se recommence sans laisser de trace dans l'historique.

Installer dsoxlab

Une seule commande, et rien n'est posé dans votre système en dehors de l'outil lui-même :

uv tool install dsoxlab      # ou : pipx install dsoxlab

Vérifiez ensuite que votre poste a ce qu'il faut. La commande doctor sépare ce qui est requis de ce qui est seulement informatif, ce qui évite de courir après un composant dont vous n'avez aucun besoin :

dsoxlab doctor

                              Requis pour ce dépôt
┃ Composant     ┃ Statut ┃ Détail
│ Python        │  ✔ OK  │ 3.14.2
│ pytest        │  ✔ OK  │ embarqué avec dsoxlab (celui qu'utilise « check »)
│ ShellRuntime  │  ✔ OK  │ toujours disponible
│ git           │  ✔ OK  │ git version 2.43.0
│ Labs détectés │  ✔ OK  │ 1 lab(s) dans ~/.local/share/dsoxlab/demo

Le tableau informatif qui suit celui-ci liste Docker, KVM et Incus. Aucun ne bloque quoi que ce soit tant que vous ne jouez pas un lab qui le réclame. La leçon Installer dsoxlab en local détaille les prérequis, la mise à jour et l'auto-complétion.

Jouer un premier lab, sans rien provisionner

La commande demo installe un catalogue d'un seul lab, dont le sujet est dsoxlab lui-même. Il tourne en runtime shell : ni machine virtuelle, ni conteneur, donc il fonctionne partout où la CLI fonctionne.

Terminal : dsoxlab installe le catalogue de démonstration, liste son lab, puis affiche le score obtenu après validation

La séquence ci-dessus tient en trois commandes, et c'est exactement ce que vous allez taper :

dsoxlab demo
cd ~/.local/share/dsoxlab/demo
dsoxlab list-labs

Le tableau affiché porte une ligne par lab, avec sa section, son identifiant, son type, son runtime, sa durée et son score :

Section	ID	Titre	Type	Runtime	Durée	Score
demo	`premiers-pas`	Premiers pas	lab	shell	5m	vide

La colonne Score reste vide tant que le lab n'a pas été validé. C'est elle qui vous dira, plus tard, où vous en êtes sur un catalogue de soixante labs, et lesquels restent à rejouer.

La boucle d'un lab : cours, mission, indice, validation

Quatre commandes suffisent, et elles se suivent toujours dans le même ordre.

Le cours donne la matière. Sur les catalogues des formations, il renvoie vers la leçon correspondante de ce site :

dsoxlab course premiers-pas

La mission dit ce qu'il faut produire, et surtout ce qui sera vérifié :

dsoxlab challenge premiers-pas

Le lab de démonstration réclame trois fichiers dans reponses/, et sa mission annonce noir sur blanc sa règle de correction : « Les fichiers, et rien d'autre. Ni votre historique, ni les commandes tapées. Toute façon de les créer compte. »

L'indice est disponible à tout moment, et son coût est annoncé avant d'être consommé. Sur ce lab, il retire 20 points sur 100 :

dsoxlab hint premiers-pas

La validation exécute les tests, affiche le détail de chacun et enregistre le résultat :

dsoxlab check premiers-pas

Le panneau de fin résume les trois chiffres qui comptent. Voici celui obtenu en jouant ce lab avec un indice pris :

Ligne du panneau	Valeur obtenue
Tests	3 / 3
Hints	1 utilisé, pénalité de 20 points
Score	80 / 100 pts

Le barème est donc lisible : la réussite vaut les points, l'indice les réduit, et dsoxlab scores garde l'historique complet, y compris les tentatives ratées.

Le piège du répertoire de travail

Voici l'erreur qui coûte le plus de temps, et elle ne se devine pas. dsoxlab run ne se contente pas d'afficher des instructions : il prépare un répertoire de travail isolé, challenge/work/, et vous y place.

dsoxlab run premiers-pas

✔ Lab premiers-pas prêt. Vous êtes dans challenge/work/, votre répertoire de
travail isolé.

Les tests lisent des chemins relatifs à ce répertoire. Si vous créez vos fichiers ailleurs, par exemple directement dans challenge/, ils ne les trouvent pas, le score tombe à zéro, et le message vous invite à créer un fichier que vous venez pourtant de créer :

E     Crée le fichier, par exemple : mkdir -p reponses && echo <le mot> > reponses/indice.txt
E     assert False
E      +  where False = exists()

La règle tient en une phrase : passez toujours par dsoxlab run avant de travailler, et restez là où il vous dépose. Tapez exit pour quitter la session sans rien enregistrer.

Brancher les catalogues de labs des formations

Le lab de démonstration ne sert qu'à comprendre la mécanique. Les vrais labs vivent dans des catalogues, un par formation, que la CLI sait installer et tenir à jour :

dsoxlab catalog list
dsoxlab catalog add linux
dsoxlab catalog use linux

Trois catalogues sont connus par leur identifiant en version 0.2.5, celle que cette formation documente :

Identifiant	Description
`linux`	Administration Linux, RHCSA et LFCS
`ansible`	Ansible, du premier playbook aux collections
`terraform`	Terraform et l'infrastructure as code

Le catalogue Kubernetes ne figure pas dans ce registre. Il s'installe par l'URL de son dépôt, que catalog add accepte aussi bien qu'un identifiant :

dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

La page Tous les labs liste le contenu intégral de ces catalogues, filtrable par compétence et par certification, avec pour chaque lab le guide du site qui enseigne ce qu'il mesure. C'est par là qu'il faut passer pour choisir un catalogue en connaissance de cause plutôt qu'au nom.

Une fois un catalogue actif, dsoxlab next recommande le lab suivant et dsoxlab progress affiche l'avancement par bloc. C'est le point de vue qui manque le plus quand on suit une formation longue : savoir ce qui reste à prouver. Les pages qui rattachent ces labs à leurs leçons sont la validation des compétences Linux, la formation Linux et la formation Kubernetes, et les conventions du site expliquent comment lire un bloc de lab dans un guide.

Les labs qui réclament des machines

Certaines compétences ne se prouvent pas dans un conteneur, parce que le noyau est partagé avec l'hôte. Un profil AppArmor, une montée de version kubeadm, un kubelet cassé ou une restauration d'etcd exigent de vraies machines. Ces labs déclarent alors un runtime vm, et deux commandes encadrent leur cycle de vie :

dsoxlab provision   # crée l'infrastructure du lab
dsoxlab destroy     # la détruit, machines hors état comprises

Introduite en 0.1.101, la veille du jalon 0.2.0, dsoxlab start <id> joue toute la séquence d'un lab, contexte, prérequis, infrastructure puis session, en annonçant chaque étape avec la commande qui la rejoue seule. C'est la commande à apprendre en premier sur un catalogue de labs vm : quand une étape échoue, elle nomme laquelle, et rien au-delà n'est tenté.

La commande doctor vous dira si le fournisseur attendu, KVM ou Incus, est présent. Détruisez toujours l'infrastructure après coup : ces machines consomment mémoire et disque bien après la fin du lab. La leçon Dimensionner sa machine pour les labs chiffre ce que chaque catalogue réclame.

Ce que contient cette formation

La formation suit l'ordre dans lequel un apprenant rencontre les questions : où installer l'outil, combien de ressources prévoir, quel enchaînement de commandes retenir, puis comment rédiger ses propres labs. Chaque leçon se lit seule, mais le volet 3 suppose qu'on a joué au moins un lab avec le volet 2.

Volet	Leçons	Lecture
Volet 1 · Installer et préparer sa machine	Installer dsoxlab en local ; L'appliance : une machine virtuelle prête à jouer ; Dimensionner sa machine pour les labs	50 min
Volet 2 · Les commandes au quotidien	Les principales commandes de dsoxlab ; Fichiers, variables d'environnement et codes de sortie	40 min
Volet 3 · Côté formateur	Créer un cours et ses challenges de A à Z ; Monter l'infrastructure des labs vm	55 min

Aucune leçon de cette formation ne porte de quiz ni de bloc de lab : c'est une formation sur l'outil qui fait tourner les labs des autres. La mise en pratique consiste à jouer le lab de démonstration ci-dessus, puis un catalogue réel. La page Mon parcours permet de cocher les leçons au fil de la lecture.

Dépannage

Les deux premières lignes couvrent l'essentiel des blocages rencontrés au démarrage. La troisième est plus rare, mais son message n'oriente pas vers sa cause, ce qui la rend coûteuse.

Symptôme	Cause	Solution
Les tests réclament un fichier qui existe déjà	Fichiers créés hors du répertoire de travail du lab	Lancer `dsoxlab run <id>` et travailler là où il dépose
`Aucun catalogue installé`	La CLI est installée, mais aucun catalogue n'est branché	`dsoxlab catalog add <id>` puis `dsoxlab catalog use <id>`
Un lab reste bloqué au provisionnement	Fournisseur KVM ou Incus absent ou arrêté	`dsoxlab doctor`, puis installer le fournisseur attendu

En cas de doute, dsoxlab support produit un rapport de diagnostic anonymisé, à coller dans une issue du dépôt du catalogue concerné, et dsoxlab support --issue l'y dépose directement. Le journal complet est de toute façon écrit dans ~/.local/state/dsoxlab/dsoxlab.log.

À retenir

dsoxlab est un moteur de labs, sans contenu propre : les guides sont sur ce site, les labs dans des dépôts compagnons.
Un lab tient en trois pièces : le challenge dit la mission, le check lance les tests, le score part de 100 et paie chaque indice.
Les tests lisent l'état du système, jamais les commandes tapées : toute façon de réussir compte.
Le lab de démonstration ne demande aucune infrastructure et fait parcourir toute la boucle en cinq minutes.
dsoxlab run place dans un répertoire de travail isolé, où les tests lisent des chemins relatifs : c'est le piège le plus coûteux.
Un indice coûte des points, et son prix est annoncé avant d'être consommé.
Les catalogues linux, ansible et terraform s'installent par leur identifiant, Kubernetes par l'URL de son dépôt en version 0.2.5.
Un lab en runtime vm se joue avec dsoxlab start et se détruit après usage avec dsoxlab destroy.

Pour aller plus loin

Installer dsoxlab en local : Les prérequis exacts, la mise à jour, l'auto-complétion et les deux erreurs d'installation qui reviennent.
Dimensionner sa machine pour les labs : Combien de mémoire, de processeurs et de disque chaque catalogue déclare réellement, Kubernetes compris.
Les principales commandes de dsoxlab : Chaque commande, ce qu'elle fait, et l'ordre dans lequel on les enchaîne.
Créer un cours et ses challenges de A à Z : Écrire son propre catalogue, du meta.yml aux tests qui prouvent.