Challenge IaC : le socle de l'outil interne en code, et son démontage prouvé

Ce challenge ne vous donne aucune commande : il vous donne un socle à décrire, trois outils à faire coopérer, et vous demande les preuves. Il s'adresse à qui a suivi les leçons Terraform, Packer et Ansible du volet, et veut savoir s'il saurait les enchaîner sans la page sous les yeux. Vous en repartirez avec une image que vous avez construite, un état qui survit à votre poste, une flotte découverte par ses étiquettes, un playbook dont vous avez prouvé l'idempotence, et un compte revenu à zéro, restes de build compris. Le corrigé est replié en bas de page : ne l'ouvrez qu'après avoir livré, ou après une heure de blocage réel.

Ce que vous allez faire

Construire une image avec un marqueur daté, et savoir ce qu'elle laisse.
Déclarer deux Instances sur cette image, avec un état distant verrouillé.
Découvrir la flotte par ses étiquettes et prouver l'idempotence.
Détruire, puis retrouver par famille ce que Terraform ne connaît pas.

Le besoin

L'outil interne de l'équipe tient sur deux machines, un front et un worker, et personne ne veut plus les installer à la main. La dernière reconstruction a pris une journée, parce que la seule personne qui savait comment faire était en congé. L'équipe veut un socle rejouable par n'importe qui, depuis un dépôt, sur un projet vide.

Trois exigences viennent de l'expérience passée. L'image doit être la même pour les deux machines, avec la version du socle lisible depuis l'intérieur. L'état de l'infrastructure ne doit pas vivre sur un poste de travail, parce que c'est précisément ce qui s'est perdu la dernière fois. Et personne ne veut plus tenir une liste de machines : l'exploitation doit découvrir la flotte par ce qui existe réellement, pas par un fichier qu'on oublie de mettre à jour.

Rien n'a besoin de survivre à la session, sauf ce que vous aurez appris sur ce qui survit malgré vous.

Les contraintes

Chaque contrainte a une preuve associée, et c'est la preuve qui compte, pas la déclaration. Un Destroy complete! n'est pas une preuve, la leçon Terraform l'a établi sur cinquante ressources.

#	Contrainte	Preuve attendue
1	Les trois outils sont épinglés à une version exacte, le fichier de verrouillage de Terraform est versionné, et aucun identifiant ne figure dans le code	les trois blocs de contrainte, le fichier de verrouillage, et un `grep` du dépôt qui ne trouve aucune clé
2	L'image des deux machines vient d'un build Packer et porte un marqueur daté lisible depuis l'intérieur	la ligne de création de l'image, et la lecture du marqueur depuis chaque machine
3	L'état vit sur Object Storage, avec le verrou activé et le versionnage du seau	l'objet d'état listé dans le seau, et un second `apply` lancé pendant le premier qui attend ou refuse
4	Le plan est lu avant l'apply : le décompte des ressources par type est produit et commenté	le décompte, et le coût horaire déduit, poste par poste
5	La flotte est découverte par l'inventaire dynamique, groupée par étiquette, sans aucun nom de machine écrit à la main	la sortie de l'inventaire avec ses groupes, et le playbook qui s'exécute dessus
6	Le playbook est idempotent : première passe avec changement, seconde sans	les deux récapitulatifs, `changed=1` puis `changed=0`
7	Le destroy sort en code 0, l'état est vide, les onze listes de la leçon Terraform sont vides, et les trois restes du build Packer sont retrouvés par famille et supprimés dans le bon ordre	les listes, et les trois suppressions

Une huitième exigence se règle par une phrase : expliquez pourquoi les trois objets laissés par Packer n'apparaissent pas dans l'état Terraform, et pourquoi aucun ne porte le nom de votre build.

Ce que vous devez livrer

Un dossier de six éléments, lisibles par quelqu'un qui n'a pas assisté à la construction. Le format est libre, le contenu ne l'est pas.

Le dépôt : modèle Packer, HCL Terraform, inventaire et playbook Ansible, fichier de verrouillage, et rien d'autre. Un lecteur doit pouvoir le rejouer sur un projet vide avec ses propres identifiants.
Les sept preuves du tableau des contraintes, sous forme de sorties de commandes recopiées et datées.
Le plan commenté : le décompte par type avant l'apply, et ce que chaque ligne va coûter à l'heure, d'après les prix relevés par la CLI.
La trace de l'exploitation : l'inventaire découvert, les deux récapitulatifs du playbook, et la valeur du marqueur lue sur chaque machine.
La destruction : le code de retour, l'état vide, les onze listes, puis les trois restes de Packer retrouvés, nommés, et supprimés dans l'ordre que les dépendances imposent, avec le message du refus si vous l'avez provoqué.
Trois réponses écrites : pourquoi Packer laisse trois objets hors de l'état ; ce qui se passe si deux personnes lancent apply en même temps sans verrou ; pourquoi le playbook ne doit jamais créer ni détruire l'infrastructure, et qui le fait à sa place.

Comment vous auto-évaluer

La grille se lit ligne par ligne, et une ligne à zéro sur les contraintes 1, 3 ou 7 rend le reste secondaire : un socle non reproductible, un état perdu ou un compte qui facture encore ne sont pas « presque » de l'infrastructure as code.

Critère	Ce qui vaut les points	Points
Contraintes 1 à 7 prouvées	chaque preuve est une sortie de commande, datée, reliée à la contrainte	7 × 2
Plan commenté et coût	le décompte par type, et le coût horaire poste par poste	1
Restes de Packer	les trois objets retrouvés par famille, supprimés dans l'ordre	2
Les trois réponses	chacune s'appuie sur un fait d'une leçon, pas sur une intuition	3

Seuil : 14 sur 20. En dessous, rejouez le challenge une semaine plus tard, sans relire le corrigé entre-temps. Au-dessus, vous êtes prêt pour le lab fil rouge du volet, qui rejoue la même chaîne et vous montre ce qu'elle laisse.

La solution, repliée

N'ouvrez ce bloc qu'après avoir livré, ou après une heure de blocage réel. Il ne contient aucune commande nouvelle : chaque geste renvoie à la leçon qui l'a validée en lab, avec l'ancre exacte.

Le plan de construction, les pièges et l'ordre de destruction

Les épinglages viennent des trois leçons. Terraform épingle le provider à l'exact dans required_providers et versionne .terraform.lock.hcl ; Packer épingle le plugin dans required_plugins ; Ansible installe la collection en version précise, et sans --upgrade une version déjà présente reste en place sans erreur (configurer le provider sans clé dans le code, épingler et vérifier le plugin Packer, installer la collection). Aucun identifiant dans le code : le provider et la collection lisent le profil scw et les variables d'environnement, avec une précédence opposée entre les deux, ce que la leçon Terraform détaille.

L'image vient du modèle minimal de la leçon Packer, avec un marqueur posé par le provisionneur comme le fait le lab fil rouge. Retenez l'UUID de la ligne An image was created, pas le nom : c'est lui que Terraform attend et que la suppression exigera (un modèle Packer Scaleway minimal, Packer construit l'image).

L'état distant est le bloc backend "s3" de la leçon Terraform, avec use_lockfile = true et les quatre options skip_ sans lesquelles terraform init échoue sur des contrôles propres à AWS. Le versionnage du seau s'active à part, et c'est lui qui rend un état corrompu récupérable (où stocker l'état Terraform).

Les ressources sont celles du lab fil rouge : une adresse déclarée explicitement, une Instance qui démarre sur votre image, un réseau privé et une carte réseau privée. Déclarer l'adresse plutôt que la laisser à l'implicite rend visible une adresse facturée même détachée. Deux étiquettes, front et worker, deviendront les groupes de l'inventaire (Terraform provisionne sur cette image). Le décompte du plan par type est le garde-fou de coût de la leçon Terraform : lisez-le avant d'appliquer (que faut-il lire dans la sortie de terraform apply).

L'inventaire dynamique groupe par étiquette, sans un seul nom de machine : la configuration exacte publiée dans la leçon Ansible a été mesurée sur deux Instances étiquetées, et scaleway_address_source dit quelle adresse a été retenue. Le piège du projet neuf vient ensuite : les clés SSH appartiennent au projet, et un projet fraîchement créé n'en a aucune, d'où un Permission denied (publickey) qui ne dit rien de sa cause (découvrir une flotte avec l'inventaire dynamique, pourquoi la connexion SSH échoue dans un projet neuf).

L'idempotence se prouve en rejouant, jamais en lisant une promesse : la leçon Ansible montre la méthode, et le lab fil rouge l'assertion qui échoue si la seconde passe change quelque chose (vérifier qu'un module est vraiment idempotent, Ansible vérifie depuis l'intérieur). La troisième réponse écrite est là : la collection ne contient aucun module de création ni de suppression, et c'est un choix, Terraform possède la ressource et Ansible agit dessus.

La destruction se prouve par onze listes, pas par le message de Terraform ; puis les trois restes de Packer se cherchent par famille, jamais par nom : la famille historique instance snapshot est vide, le snapshot est dans block snapshot sous un nom généré, le volume orphelin porte le nom de l'image source. L'image se supprime avant le snapshot, qui la verrouille, et le volume en dernier (prouver qu'un compte est vraiment vide, où Packer range ce qu'il produit, dans quel ordre supprimer une image et son snapshot). C'est la première réponse écrite : Terraform ne détruit que ce qu'il a créé, et Packer s'est retiré après avoir créé les siens.

Le budget : deux DEV1-S à environ 0,009 € par heure et deux adresses à 0,005 €, relevés le 2026-09-08, soit 0,028 € par heure, plus un build Packer d'une minute et quelques gigaoctets d'image, de snapshot et de volume tant qu'ils existent.

À retenir

Épingler à l'exact et versionner le verrou rend le socle reproductible ; une contrainte flottante laisse une régression amont modifier votre déploiement.
Aucun identifiant dans le code : profil scw et variables d'environnement, avec une précédence opposée entre le provider et la collection.
L'état vit sur Object Storage avec use_lockfile = true et quatre options skip_ ; le versionnage du seau se demande à part.
Le décompte du plan par type se lit avant l'apply : c'est ce qui va tourner au compteur.
L'inventaire dynamique groupe par étiquette, et les clés SSH appartiennent au projet.
Une idempotence se prouve en rejouant : changed=1 puis changed=0.
Le destroy se prouve par onze listes, et les trois restes de Packer se retrouvent par famille, image d'abord, snapshot ensuite, volume en dernier.

Pour aller plus loin

Container Registry : pousser une image, et savoir qui peut la tirer : l'artefact suivant à distribuer, quand l'application quitte l'image de machine pour le conteneur.
Créer un cluster Kapsule, survivre à la perte d'un nœud, et tout détruire : le même réflexe de destruction prouvée, sur un cluster.

Ressources externes

Documentation du provider Scaleway sur le registre Terraform : la référence des ressources et de leurs arguments, version par version.
Plugin Packer Scaleway : les sources, les options du builder et les notes de version.
Collection Ansible stephrobert.scaleway : les modules, l'inventaire et leur documentation.