Créer votre première infrastructure Terraform en cinq minutes

Ce que vous allez obtenir

À la fin de ce guide, le vrai provider Terraform de Scaleway aura créé un serveur et une adresse IP sur votre machine, un second plan répondra qu'il n'y a rien à changer, et feint down aura tout détruit. Aucun compte n'aura été ouvert, aucune clé d'accès lue, et rien ne sera facturé.

Feint est un émulateur : un programme local qui imite le plan de contrôle d'un fournisseur cloud, c'est-à-dire l'API qui crée, décrit et supprime les ressources, sans rien démarrer derrière. Terraform croit parler au vrai fournisseur, et vous pouvez vous exercer sans risque.

Le tout prend environ cinq minutes, dont la moitié à télécharger le provider.

Pourquoi commencer par là

Un apply qui réussit est le premier signal, mais ce n'est pas celui qui compte. Le vrai test d'une infrastructure décrite en Terraform est qu'elle converge : après l'avoir créée, une seconde planification ne doit proposer aucun changement. Ce guide vous fait voir les deux dans cet ordre, parce que c'est le réflexe qui sert ensuite sur un vrai cloud.

Prérequis

• Terraform 1.7 ou plus récent, ou OpenTofu.
• Git, pour récupérer l'exemple.
• Feint, installé en une commande ci-dessous.

Rien d'autre : pas de compte, pas de clé d'API, pas de moteur de conteneurs. L'émulateur est un binaire statique qui tient son état en mémoire.

Le lab, pas à pas

1. Installer Feint.

   brew install stephrobert/feint/feint
   feint version

   La sortie doit afficher v0.13.0. Si vous préférez le binaire vérifié par signature, ou si vous n'utilisez pas Homebrew, la page d'installation donne les autres chemins.

2. Récupérer l'exemple, qui vit dans le dépôt du projet.

   git clone https://github.com/stephrobert/feint
   cd feint/examples/quickstart/scaleway

   Deux fichiers seulement s'y trouvent : un main.tf assez court pour être lu en entier, et un feint.yaml qui décrit l'environnement dont il a besoin.

3. Vérifier l'hôte avant de lancer quoi que ce soit.

   feint doctor

   Lancé depuis le répertoire de la stack, doctor fait plus que contrôler le port : il lit les fichiers Terraform présents et cherche les signatures connues d'un appel qui partirait vers le vrai cloud.

   ok    no variable measured to reroute outscale clients is set in this shell
   ok    no known escape signature in the 1 Terraform file(s) here

4. Tout monter en une commande.

   feint up

   feint up lit le feint.yaml, vérifie ce que l'hôte peut fournir, démarre l'émulateur, exporte ce qu'attend le client officiel, lance Terraform dans le répertoire, puis attend les conditions que le fichier déclare avant de rendre la main.

   feint.yaml: scaleway, runtime off, terraform in .
   feint listening on 127.0.0.1:4599 (pid 3774695)
   - terraform init in .
   - Installing scaleway/scaleway v2.81.0...
   - terraform apply in .
   Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
   - waiting: the emulator answers /instance/v1/zones/fr-par-1/servers
     ok: http:/instance/v1/zones/fr-par-1/servers
   - waiting: the emulator holds a instance/server
     ok: resource:instance/server:1
   - waiting: the emulator holds a instance/ip
     ok: resource:instance/ip:1

   La fin de la sortie récapitule où trouver quoi, ce qui évite d'avoir à retenir des commandes ou à les chercher dans un historique de shell :

   up: http://127.0.0.1:4599
     clients:  eval "$(feint env scaleway)"
     page:     http://127.0.0.1:4599/_feint/ui
     logs:     feint logs --addr 127.0.0.1:4599
     state:    feint status --addr 127.0.0.1:4599
     proved:   http:/instance/v1/zones/fr-par-1/servers, resource:instance/server:1, resource:instance/ip:1
     down:     feint down

5. Vérifier la convergence, qui est le vrai test.

   terraform plan

   No changes. Your infrastructure matches the configuration.

   Cette ligne dit quelque chose de fort : l'API a relu les ressources comme elle les avait acceptées. Si une seule valeur revenait sous une autre forme, Terraform proposerait ici une modification fantôme, et vous auriez le même problème sur le vrai cloud.

6. Regarder ce que l'émulateur a réellement servi.

   feint status

     provider    routes  driven by a client
     scaleway       193  12
     exoscale       104  0
     outscale       100  0

   La colonne de droite compte les routes qu'un vrai client a traversées pendant votre session : douze ici, celles que Terraform a appelées pour créer puis relire vos deux ressources.

7. Tout détruire.

   feint down

   Destroy complete! Resources: 2 destroyed.
   feint: discarding 1 resource(s) (started without --state); `feint snapshot save <name>` before stopping would have kept them

   La seconde ligne n'est pas une erreur : l'émulateur signale qu'il jette une ressource restée en mémoire, et vous dit comment l'auriez gardée. Un émulateur qui disparaît en silence avec vos données serait plus gênant.

Casser le lab exprès

Un guide de test doit montrer un échec, sinon il n'apprend rien du diagnostic. Le lab vient d'être détruit par feint down : l'émulateur est arrêté, et c'est feint up qui le relance. Ouvrez main.tf, remplacez le type du serveur (DEV1-S) par une valeur qui n'existe pas, DEV1-XXL par exemple, puis relancez toute la pile :

feint up

Le provider refuse, avec le message exact could not find a server type associated with DEV1-XXL in zone fr-par-1, et la ligne finale feint: terraform apply: exit status 1. C'est l'émulateur qui a refusé : le catalogue est une liste fermée, et un type absent est rejeté comme le ferait Scaleway. Notez ce qui s'est passé avant le refus : Terraform crée les ressources dans l'ordre de leurs dépendances, donc l'adresse IP a déjà été créée quand le serveur échoue. C'est un apply partiel, et il laisse un reste à nettoyer, exactement comme sur un vrai cloud. terraform state list ne renvoie d'ailleurs que scaleway_instance_ip.web, et l'émulateur reste en marche après l'échec.

Remettez la valeur d'origine avec git checkout -- main.tf, puis détruisez ce qui reste :

feint down

Destroy complete! Resources: 1 destroyed.

L'ordre compte : cet exercice se joue après l'étape 7. Rejoué alors que le lab tourne encore, le changement de type porte sur un serveur déjà créé, et l'erreur est un autre message (cannot change server type), sans IP créée avant l'échec.

En revanche, un identifiant d'image inexistant passerait, lui, et c'est une limite délibérée que la page sur les limites explique.

C'est déjà une leçon utile : ce lab prouve que votre configuration est bien formée, pas que toutes les valeurs qu'elle nomme existent quelque part.

Ce que ce lab prouve

Un lab n'a de valeur que par ce qu'il établit réellement. Quatre constats sont démontrés par les sept étapes ci-dessus :

• Le vrai provider Terraform sait parler à l'émulateur, dans sa version épinglée 2.81.0.
• Votre configuration crée puis relit ses ressources de façon cohérente.
• L'état converge : le second plan est vide.
• La destruction fonctionne, et le nettoyage est complet.

Ce qu'il ne prouve pas

Les limites comptent autant que les preuves, parce qu'elles disent où s'arrête ce que l'émulateur peut garantir. Trois choses ne sont pas établies :

• Aucune machine n'a démarré. Ce lab tourne en mode plan de contrôle : l'API décrit un serveur, rien ne s'exécute derrière. Le guide des machines réelles montre l'autre moitié.
• Les valeurs ne sont pas celles du vrai cloud : ni les prix, ni les quotas, ni la capacité disponible.
• Rien n'a été authentifié. Les identifiants exportés sont bien formés et fictifs, et l'émulateur ne vérifie aucune signature.

À retenir

• Un apply réussi ne suffit pas : le test qui compte est un second terraform plan qui répond « No changes ».
• Feint émule le plan de contrôle du fournisseur sur votre machine : le vrai provider Terraform tourne, sans compte ni clé d'accès.
• Le cycle feint up, terraform plan, feint down crée, vérifie la convergence, puis détruit sans reste.
• Le lab prouve que la configuration est bien formée et converge, pas que les valeurs nommées existent chez le vrai fournisseur ni qu'une machine a démarré.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →