Lab Ansible : configurer une machine avec un playbook, dans le navigateur

Ce lab donne à chaque élève une machine Ubuntu à lui et un playbook Ansible inachevé. Il le termine pour qu’il installe un paquet, crée un fichier à partir d’un modèle contenant une variable et écrive un fichier d’unité systemd, puis l’exécute une seconde fois et constate que rien ne change. Rien n’est installé sur l’ordinateur de l’élève, et un script note le résultat : vous n’avez pas à lire chaque machine.

Ce que les élèves apprennent

Ce qu’est un playbook : une liste de tâches en YAML, chacune nommant un module qui fait un seul travail. Les variables, et un modèle qui remplit un fichier à partir de l’une d’elles. La différence entre décrire l’état où une machine doit être et taper les commandes qui l’y amènent. Surtout l’idempotence : un bon playbook exécuté deux fois laisse la machine comme la première exécution l’a laissée, et le récapitulatif final indique changed=0.

La tâche

Le lab laisse dans le dossier personnel un projet : un inventaire avec cette seule machine en connexion locale, un fichier de réglages, un modèle contenant une variable et un playbook auquel il manque trois travaux. Le travail 1 est un paquet, tree. Le travail 2 est le fichier /etc/ansible-lab/welcome.txt, créé à partir du modèle, appartenant à root avec les droits 0644. Le travail 3 est le fichier d’unité /etc/systemd/system/lab-greeter.service, dont la description porte la variable. Le README dit quoi faire dans chacun et ne donne ni tâche, ni module, ni réponse. L’élève écrit seulement le fichier : le service n’est pas démarré.

Le lancer dans votre navigateur

Les labs VM se proposent comme une tâche de lab dans un module, et l’exemple se trouve sur la page du lab. La machine est petite : un processeur, 1 Go de mémoire et 10 Go de disque.

  1. Ajouter le lab. Dans un module que vous enseignez, ajoutez une tâche et choisissez la carte « Lab VM Ubuntu ». La page affiche une courte description de la machine au lieu d’un fichier compose.
  2. Partir de l’exemple. La page propose des labs prêts à l’emploi pour commencer. Choisissez Ansible basics. Utiliser un exemple remplace le texte, et « Annuler » rétablit le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis « Démarrer ». Le script d’installation du lab installe Ansible à partir de l’archive d’Ubuntu et écrit le projet et le README au premier démarrage de la VM, en une dizaine de secondes.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il indique les trois tâches à terminer dans le playbook et ne donne aucune réponse.

Une leçon de base sur ce lab

Ansible Basics est une petite leçon qui se fait dans ce lab, qui est une VM Ubuntu : chaque étape est expliquée et accompagnée d’un bouton Exécuter qui tape sa commande dans le terminal de la machine et montre ce qu’elle a affiché. L’élève liste le projet, lit le playbook inachevé, l’exécute et constate qu’il ne change rien, puis demande à un module si le dossier du lab existe déjà.

Elle se contente de regarder autour d’elle et laisse à l’élève la tâche propre du lab, terminer le playbook, si bien qu’elle ne donne aucune réponse. Elle est volontairement petite : elle montre à un enseignant ce qu’est une leçon qui se fait dans un lab, et le lab fait le reste. Copiez-la dans un module à vous pour la modifier.

Comment il est noté

Le lab a une vérification. Elle s’exécute sur une copie de la machine enregistrée après un démarrage à neuf : elle ne voit donc que ce que l’élève a enregistré. Elle lit le playbook et refuse celui qui n’est fait que de tâches shell, command, raw ou script, ou qui les cache dans un include ou un rôle. Elle lit le paquet et les fichiers enregistrés. Puis elle exécute le playbook de l’élève deux fois avec un nom de site que personne n’a vu : les fichiers produits doivent le porter, ce que ne fait pas un fichier tapé à la main, et la seconde exécution doit indiquer changed=0, ce que ne fait pas une tâche qui change quelque chose à chaque fois. La première ligne de ce que la vérification a affiché dit ce qui n’est pas correct.

Ce qu’elle ne peut pas empêcher, c’est un élève déterminé qui a les droits d’administrateur sur sa propre machine et pourrait modifier Ansible lui-même. C’est une vérification pour une classe, pas une preuve.

  1. Le distribuer. Attribuez le lab comme n’importe quelle tâche, avec une échéance si vous le souhaitez. Chaque élève reçoit sa propre VM, conservée d’une session à l’autre.
  2. Lancer la vérification. Sur la ligne d’un élève dans la liste de la classe, appuyez sur « Lancer la vérification ». Elle démarre une copie de sa machine enregistrée, sans rien enregistrer en retour, exécute le script de vérification du lab en root et indique s’il a réussi, ce qu’il a affiché et quand. L’élève n’est pas informé du résultat.
  3. Noter. Lisez la première ligne de ce que la vérification a affiché : elle dit ce qui n’est pas correct, par exemple un fichier qui ne porte pas la variable ou la tâche qui a changé à la deuxième exécution. Renvoyez le travail avec un motif s’il demande un complément.

La définition sur GitHub

Le fichier est la définition complète du lab, le même texte que celui que la plateforme exécute : taille, script d’installation, README et vérification. Copiez-le et changez le paquet, les chemins ou les travaux pour faire un lab à vous.

Questions fréquentes

La vérification démarre-t-elle le service ?
Non. Elle lit le fichier d’unité sans jamais le démarrer : le lab consiste à écrire le fichier avec Ansible, et ce qui est noté, c’est le propriétaire, les droits et le contenu du fichier.
Le lab peut-il aussi enseigner Terraform ?
Pas dans ce lab. La machine n’atteint que l’archive d’Ubuntu, PyPI, npm et GitHub, et Terraform télécharge ses fournisseurs depuis un registre que la machine ne peut pas atteindre : seul Ansible est proposé. Ansible est installé à partir de l’archive d’Ubuntu au démarrage de la VM.
Que gère le playbook ?
La VM elle-même, en connexion locale, puisque chaque élève a une seule machine. Les vraies commandes fonctionnent : ansible-playbook, ansible-doc et --check pour un essai à blanc.