dsoxlab : jouer et valider les labs des formations

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.

Ce guide vous fait jouer un lab complet de bout en bout, puis brancher les catalogues des formations. Il 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 la boucle cours, mission, indice, validation, et le calcul du score.
Brancher les catalogues de labs Linux, Ansible, Terraform et Kubernetes.
Diagnostiquer les deux erreurs qui reviennent le plus souvent au démarrage.

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.

Ce que dsoxlab fait, et ce qu'il ne fait 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.

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.

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.

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.1.87 :

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 encore 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

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 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

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.

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é. 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.
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.1.87.
Un lab en runtime vm se détruit après usage avec dsoxlab destroy.

Prochaines étapes

Valider ses compétences Linux Exercices, labs et examens blancs du parcours Linux

Formation Linux Le parcours complet, de la première commande aux certifications

Formation Kubernetes 64 labs vérifiables pour CKA, CKAD et CKS

Conventions du site Comment lire les guides, les labs et les quiz