Lab OpenTofu : l’infrastructure en code, avec plan, apply et état, dans une VM

Ce lab donne à chaque élève OpenTofu sur sa propre machine Ubuntu. L’infrastructure as code consiste à décrire dans des fichiers ce qui doit exister et à laisser un outil trouver comment y arriver : il compare les fichiers avec la mémoire de ce qu’il a déjà construit, montre la différence sous forme de plan, et ne change rien avant. L’élève écrit un petit projet, lit des plans, regarde l’état et répare un projet cassé.

OpenTofu est libre et gratuit, aucune licence n’est nécessaire. Rien n’est installé sur l’ordinateur de l’élève. Une seule chose manque au lab : un vrai cloud. Il le dit lui-même, et cette page aussi.

Ce que les élèves apprennent

Les gestes de l’infrastructure as code, en six parties. Un premier plan et un premier apply, et le fichier d’état qu’ils laissent. Des variables et des sorties. Plusieurs exemplaires d’une chose à partir d’une description, avec count et avec for_each, et pourquoi for_each est celui qui garde les noms. Lire un plan après un changement et dire ce qui sera créé, modifié ou détruit avant que quoi que ce soit arrive. À quoi sert l’état, en le supprimant et en voyant le plan vouloir tout recréer. Et trouver trois erreurs dans un projet, un mauvais type, une variable manquante et un cycle, avec tofu validate. En chemin : tofu fmt, tofu console et les dépendances entre ressources.

Ce qui est réel ici, et ce qui ne l’est pas

Les vrais clouds et services s’atteignent par des providers, des modules qu’OpenTofu télécharge depuis un registre. La VM d’un élève n’atteint que l’archive d’Ubuntu, PyPI, npm et GitHub : aucun provider ne peut donc être téléchargé et rien de réel n’est jamais créé dans ce lab. Ce qui est intégré à OpenTofu n’a besoin d’aucun téléchargement : la ressource terraform_data, qui garde seulement une valeur et la rend. Avec elle, les variables, les sorties, count, for_each, les dépendances, plan, apply, destroy et l’état sont la vraie chose. Un provider comme AWS ou Docker ne change que ce que fabrique un bloc de ressource. Le README en montre un comme texte à lire et le lab ne l’exécute jamais.

Les trois dossiers

Trois dossiers se trouvent dans le dossier personnel. hello fonctionne tel quel, pour le premier plan et apply, une variable et l’état. campus est le projet de l’élève, écrit à partir de rien selon une liste du README : trois variables, des serveurs faits avec for_each, des salles faites avec count, un résumé qui les lit tous les deux, et deux sorties. fix est un projet avec trois erreurs à trouver et à corriger.

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. La machine est petite : un processeur, 1 Go de mémoire et 10 Go de disque. OpenTofu lui-même utilise environ 80 Mo quand il travaille.

  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 OpenTofu. 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 quelques outils depuis l’archive d’Ubuntu, télécharge OpenTofu 1.13.2 depuis sa publication sur GitHub, vérifie le fichier avec une somme de contrôle fixée et l’installe, au premier démarrage de la VM, en une minute ou deux. Le téléchargement demande un compte : la VM d’un visiteur n’atteint que l’archive d’Ubuntu.
  4. Ouvrir le terminal. Ouvrez son terminal et lisez README.md dans le dossier personnel : il dit quoi faire en six parties et ne donne aucune réponse.

Une leçon de base sur ce lab

OpenTofu 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 mise en route, une vérification après les idées, une erreur fréquente 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 lit un projet, lance init et plan, applique et liste l’état, change une valeur et lit le plan, puis supprime l’état et voit le plan vouloir créer ce qui existe.

La leçon explore et laisse à l’élève la tâche propre du lab, le projet et le projet cassé : elle ne donne donc aucune réponse.

Comment il est noté

Le lab a une vérification. Elle copie les deux dossiers de l’élève ailleurs, si bien que son propre état ne compte pas, et refuse les providers et les provisioners. Puis elle valide et exige des fichiers bien rangés (tofu fmt). Pour le projet campus, elle choisit ses propres valeurs pour les variables, un nom d’établissement que personne n’a vu et ses propres serveurs et salles, planifie, puis applique. L’état doit contenir un serveur par nom, chacun avec le site et le nom comme entrée, les salles numérotées à partir de un, et une sortie summary qui lit une ressource au lieu d’être tapée, ainsi que les noms. Une ressource sans entrée échoue, de même qu’une sortie qui ne suit pas les variables. La vérification retire ensuite un serveur et en ajoute deux, replanifie, et exige que seul celui-là soit détruit et que seuls les deux soient créés. Elle applique, exige qu’il ne reste rien à changer, et détruit. Enfin, le projet cassé doit être valide, s’appliquer, garder ses ressources et suivre sa variable. La première ligne de ce que la vérification 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 des serveurs qui ne correspondent pas aux variables, un résumé qui ne lit pas les serveurs, ou un plan qui veut encore changer quelque chose après l’apply. 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, la commande tofulab, les trois projets, README et vérification. Copiez-le et changez le projet, les variables ou les erreurs 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 OpenTofu demande-t-il une licence ?
Non. OpenTofu est libre, sous la Mozilla Public Licence 2.0, un projet de la Linux Foundation né d’un fork de Terraform. Le lab utilise OpenTofu et jamais Terraform, dont la licence n’est pas libre. Il est téléchargé depuis la publication du projet au démarrage de la VM de l’élève, et nous n’en distribuons rien.
Pourquoi les élèves ne peuvent-ils pas créer un vrai serveur ?
Un vrai serveur se crée par un provider, et les providers se téléchargent depuis un registre que la VM d’un élève ne peut pas atteindre : elle n’atteint que l’archive d’Ubuntu, PyPI, npm et GitHub. Le lab enseigne donc tout sauf le provider, avec la seule ressource qu’OpenTofu intègre. Plan, apply et état se comportent de la même façon avec une vraie, ce qui est l’intérêt de les apprendre ici.
Qui peut le lancer ?
Quelqu’un qui a un compte, gratuit ou dans un établissement. Le lab télécharge OpenTofu depuis GitHub au premier démarrage de la VM, et la VM d’un visiteur, qui n’atteint que l’archive d’Ubuntu, ne le peut pas. Si un téléchargement échoue, sudo tofulab install réessaie, et la vérification dit qu’OpenTofu manque au lieu d’échouer pour une autre raison.
Les élèves peuvent-ils casser quelque chose ?
Seulement leur propre copie. Rien de ce que fait le lab n’est en dehors de l’état d’OpenTofu, et la VM atteint l’archive d’Ubuntu, PyPI, npm et GitHub, rien d’autre. Si un élève abîme un dossier, sudo tofulab reset remet ses fichiers.
Le lab a-t-il été testé dans une vraie VM d’élève ?
Le script setup, avec le vrai téléchargement et sa somme de contrôle, les commandes de la leçon et la vérification ont été exécutés dans un vrai Ubuntu 26.04, dans un conteneur qui remplace la VM, sans réseau nécessaire après le téléchargement. Une VM d’élève réellement démarrée derrière le proxy à liste autorisée de la plateforme, que doit franchir le téléchargement depuis GitHub, mérite un essai avant un cours.