Lab de rôles Ansible : un rôle, des handlers et Vault dans une VM Ubuntu

Ce lab est le deuxième niveau du lab Les bases d’Ansible. Chaque élève reçoit sa propre VM Ubuntu avec ansible-core installé, un petit projet et un README, et construit un rôle à partir de rien : ses variables, un modèle, des tâches avec des étiquettes, un handler et un jeton gardé dans Ansible Vault. La machine elle-même est la cible, par une connexion locale : rien d’autre n’est nécessaire.

Rien n’est installé sur l’ordinateur de l’élève. Les bases d’Ansible passent d’abord : elles enseignent un playbook, un paquet, un modèle et le double lancement d’un playbook, et ce lab ne les répète pas.

Ce que les élèves apprennent

Comment un playbook devient un rôle. L’élève crée les dossiers standard avec ansible-galaxy role init, qui marche sans réseau, et remplit tasks, defaults, vars, templates, handlers et meta. Il découvre dans quel ordre les variables gagnent : les defaults du rôle perdent contre une variable posée sur le play, les vars propres du rôle la battent, et une valeur donnée avec -e bat tout. Il écrit un modèle Jinja2 avec une boucle et une condition et le voit avec --check et --diff, utilise loop, register et when, et n’exécute que certaines tâches avec --tags et --limit.

Un handler que trois tâches demandent doit s’exécuter une seule fois, et l’élève doit faire exécuter ses handlers en cours de route par le rôle. La dernière partie est Ansible Vault : un fichier créé avec ansible-vault, ouvert avec un fichier de mot de passe, et un jeton qui n’est écrit en clair nulle part ailleurs. Tout se fait avec les modules d’Ansible, sur des fichiers, des dossiers et un utilisateur système, ce qu’une vérification peut voir.

Le projet

L’élève part d’un dossier avec un inventaire de deux noms pour cette seule machine, un playbook qui utilise un rôle qui n’existe pas encore, et un faux mot de passe vault qui dit n’être pas un secret. Le playbook pose déjà deux variables sur le play : l’ordre de priorité, l’élève doit le maîtriser et non le lire. La machine est petite : un processeur, 1 Go de mémoire et 10 Go de disque.

Le lancer dans votre navigateur

Les labs VM se donnent comme tâche de lab dans un module, et l’exemple se trouve sur la page du lab. Le lab n’utilise que l’archive d’Ubuntu : la VM d’un compte gratuit le fait donc tourner aussi.

  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 démarrer. Choisissez Ansible roles, handlers and vault. Utiliser un exemple remplace le texte, et Annuler rend le vôtre.
  3. Publier et démarrer votre propre copie. Publiez, puis Démarrez. Le script setup du lab installe ansible-core depuis l’archive d’Ubuntu et écrit le projet, le playbook, un faux mot de passe vault et le README, au premier démarrage de la VM, en une ou deux minutes.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il dit quoi faire en sept étapes et ne donne aucune réponse.

Une leçon de base sur ce lab

Ansible Roles Basics est une petite leçon donnée dans ce lab, une VM Ubuntu. Elle a une accroche, un objectif « Je peux », des mots-clés, une question de départ, une vérification après chaque idée, une erreur courante et une vérification finale, et chaque étape a un bouton Exécuter qui tape sa commande dans le terminal de la machine. L’élève crée un rôle jetable pour voir ses dossiers, lance deux fois un petit playbook pour voir une variable battue par -e, voit un seul handler s’exécuter pour deux demandes, et chiffre une valeur avec Vault.

La leçon regarde autour d’elle et laisse à l’élève le rôle propre au lab : elle ne donne donc aucune réponse.

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 lit d’abord le rôle : les dossiers standard, un fichier meta rempli, six tâches dans le rôle et non dans le playbook, un handler, une boucle, des étiquettes, et un modèle avec une boucle for et un if. Elle refuse shell, command, raw et script, ainsi qu’une recherche qui lance un programme. Elle ouvre le fichier vault avec le mot de passe du lab et refuse un jeton écrit en clair dans le projet.

Ensuite elle exécute sept fois le playbook de l’élève avec des valeurs que personne n’a vues : sur une machine propre, de nouveau sans rien à changer, à blanc, dont la sortie doit montrer le changement sans rien écrire, avec d’autres valeurs, avec chaque étiquette, et avec --limit sur la machine que le play n’utilise pas. Elle compte les exécutions du handler dans la vraie sortie, si bien qu’un handler exécuté trois fois est refusé, et lit les fichiers produits. La première ligne de ce qu’elle a affiché dit pourquoi.

  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 une VM à lui, conservée d’une séance à 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, qui n’est pas sauvegardée ensuite, 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 ne va pas, par exemple un handler exécuté trois fois, une variable au mauvais endroit ou un fichier vault qui ne s’ouvre pas. Renvoyez le travail avec un motif s’il faut aller plus loin.

La définition sur GitHub

Le fichier est toute la définition du lab, le texte même que la plateforme exécute : taille, script setup, README et vérification. Copiez-le et changez le rôle, les variables ou le handler pour faire un lab plus long.

Essayer ce lab, et ce qu’il coûte

Un compte personnel gratuit permet de suivre les leçons de base de ce lab, avec chaque mois assez de crédit gratuit pour suivre la plupart des leçons, sans carte. Pour une classe, un établissement a ses 365 premiers jours gratuits pour 50 élèves au plus, puis paie par élève et par an, tous les labs compris et les enseignants gratuits.

Questions fréquentes

Le lab demande-t-il une licence ou un Ansible payant ?
Non. ansible-core est libre et dans l’archive d’Ubuntu, et il est installé au démarrage de la VM de l’élève. Nous n’en distribuons rien, et rien n’est téléchargé ailleurs.
Pourquoi n’y a-t-il aucun service à redémarrer ?
Le lab montre un handler par ce qu’une vérification peut voir : combien de fois il s’est exécuté, compté dans la sortie du vrai lancement, et un fichier qu’il écrit. Le redémarrage d’un vrai service, une vérification ne peut pas le prouver : le lab le laisse de côté et le dit.
Les élèves peuvent-ils casser quelque chose ?
Seulement leur propre copie. La machine joint l’archive d’Ubuntu, PyPI, npm et GitHub, et rien d’autre. Le mot de passe vault est un faux placé dans le projet pour le lab, et le jeton est une donnée de démonstration, jamais un vrai secret.
Le lab a-t-il été testé dans une vraie VM d’élève ?
Le script setup, les commandes de la leçon et la vérification, avec ce que lui font les fausses réponses, ont été exécutés dans un vrai Ubuntu 26.04, dans un conteneur qui tient lieu de VM. Une VM d’élève démarrée, qui part d’une image disque, mérite un essai avant un cours.