Module 1 — L’infrastructure as code

Durée indicative du cours : 1 h 15
Durée indicative de l’atelier : 45 min — série neutre ou série Azure
Durée totale (cours + atelier) : environ 2 h

Ce module couvre les objectifs d’examen 1a, 1b et 1c. Vous y apprenez ce qu’est l’infrastructure as code, pourquoi ce modèle est utilisé, et comment Terraform applique le même workflow à plusieurs clouds, à un environnement hybride, ou à des services qui ne sont pas des machines virtuelles.

Les providers, le détail de chaque commande et le state d’équipe viennent dans les modules suivants. Ici, un exemple court vous montre déjà la forme d’une configuration. L’atelier du module vous le fait exécuter.

Le fil conducteur des quatre jours

Une équipe doit décrire un petit environnement, le faire évoluer, et permettre à un collègue de le reprendre sans repartir de la mémoire de quelqu’un.

Pendant quatre jours, c’est le même environnement.

Dans les modules, il est décrit avec les providers local et random. Ce sont des providers neutres. Ils ne demandent pas de compte cloud. local écrit des fichiers sur la machine. random produit des valeurs aléatoires stables une fois qu’elles sont enregistrées.

À l’atelier, vous choisissez une série.

La série neutre reste sur ces deux providers.
La série Azure reprend les mêmes étapes sur un groupe de ressources Azure.

Le geste Terraform est le même. Seule la cible change.

Qu’est-ce que l’infrastructure as code ?

HashiCorp définit l’infrastructure as code ainsi. Les outils d’infrastructure as code permettent de gérer l’infrastructure avec des fichiers de configuration, plutôt qu’avec une interface graphique. Vous construisez, modifiez et gérez l’infrastructure de façon sûre, cohérente et reproductible. Vous définissez des ressources que vous pouvez versionner, réutiliser et partager.

En pratique, vous écrivez l’état souhaité dans des fichiers texte. Avec Terraform, ces fichiers sont en HCL et portent l’extension .tf. Vous les rangez dans un dépôt, comme le code d’une application. Terraform calcule ensuite l’écart entre cet écrit et ce qui existe, puis il appelle les interfaces des providers pour rapprocher le réel de l’écrit.

Ce n’est pas un script qui dit « clique ici, puis là ». C’est une description de ce qui doit exister.

Sans fichiers de configuration

Quand l’environnement vit dans une console et dans des scripts lancés une fois, l’équipe rencontre toujours les mêmes difficultés.

La réalité s’écarte de ce que l’on croyait avoir construit. Quelqu’un a modifié un réglage dans la console. Le fichier qui aurait dû le décrire n’existe pas, ou il est faux.
Reconstruire le même environnement dépend des personnes présentes ce jour-là.
Avant d’appliquer un changement, il y a peu de revue. Le changement est déjà fait quand on le découvre.
Une personne qui arrive dans l’équipe doit interroger les autres au lieu de lire un dépôt.

Avec l’infrastructure as code

Le modèle inverse ces difficultés. Chaque avantage ci-dessous est un point que l’examen peut formuler à part.

La même description, appliquée dans les mêmes conditions, reconstruit le même résultat. C’est la reproductibilité.
Le dépôt garde l’historique. On voit qui a changé quoi, et on peut revenir à une version précédente de la description.
Une relecture du fichier a lieu avant l’application, comme une relecture de code.
Une personne nouvelle lit le dépôt. Elle n’a pas besoin du récit oral de la première mise en place.
Une brique décrite une fois est rappelée ailleurs. Les modules, au jour 3, sont cette réutilisation. Le principe commence déjà ici.
Le fichier est la documentation. S’il est appliqué, il décrit ce que l’outil cherche à maintenir. Il ne vieillit pas comme une page de wiki oubliée.
Recréer un environnement de lab ou en préparer un second ne recommence pas au clic.

L’infrastructure as code ne remplace pas le cloud, ni le disque de votre machine. Elle le pilote à partir d’une description.

Déclaratif, et ce que cela change

Terraform est déclaratif. Vous écrivez le résultat attendu. Vous n’écrivez pas la liste des appels pour y arriver. Terraform calcule les actions.

Approche	Ce que vous écrivez	Exemple dans le fil conducteur
Impérative	Les étapes	« Crée le fichier, puis ajoute une ligne, puis renomme-le. »
Déclarative	L’état cible	« Ce fichier existe, avec ce contenu. »

L’idempotence suit ce modèle. Appliquer deux fois la même description, sans changement entre les deux, ne doit ni recréer ni casser ce qui est déjà conforme. Le plan annonce qu’il n’y a pas de changement.

Cette garantie tient tant que trois choses restent alignées. La configuration écrite. Le state, qui est le carnet de Terraform. La réalité, fichier ou cloud. Si quelqu’un modifie la réalité à côté, l’alignement casse. Le jour 2 montre comment le voir et le réparer. Aujourd’hui, retenez le modèle et observez-le sur l’exemple.

Un workflow pour plusieurs cibles

L’examen demande d’expliquer comment Terraform traite le multi-cloud, l’hybride, et les services qui ne sont pas liés à un seul fournisseur de machines.

Terraform ne contient pas Azure, AWS ou votre disque dans le même binaire. Il parle à des providers. Un provider est un plugin. Il sait créer, lire, modifier et détruire un type d’objet auprès d’une interface précise.

Le workflow que vous lancez reste le même. Vous écrivez des blocs resource. Vous initialisez. Vous lisez un plan. Vous appliquez. Seul le provider change derrière le bloc.

Situation	Ce que cela veut dire	Exemple de provider
Multi-cloud	Le même dépôt peut décrire Azure et AWS, avec le même type de workflow	`azurerm`, `aws`
Hybride	Le cloud et un système hors de ce cloud sont décrits ensemble	un provider cloud et un provider de virtualisation, ou `local` pour un fichier qui accompagne le cloud
Indépendant d’un service précis	Terraform ne gère pas seulement des machines. Il gère aussi des fichiers, des identifiants, un dépôt Git, un enregistrement DNS, un service SaaS	`local`, `random`, `github`

Une configuration peut citer plusieurs providers. L’exemple de ce module en utilise deux. random choisit un suffixe. local écrit une fiche qui contient ce suffixe. Ni l’un ni l’autre n’est un compte cloud. La forme du fichier est pourtant celle que vous réutiliserez sur Azure.

Les outils liés à un seul cloud, comme Bicep pour Azure ou CloudFormation pour AWS, sont très intégrés à ce cloud. Ansible est souvent orienté vers la configuration de machines déjà là. Terraform se place autrement. Un langage, beaucoup de providers, un workflow.

Exemple — la fiche de l’environnement

Voici la première description du fil conducteur. Elle tient dans un seul fichier main.tf. Elle demande Terraform 1.16.5 ou plus récent.

Le bloc terraform fixe la version de Terraform et les providers. random_id tire quatre caractères hexadécimaux et les garde. local_file écrit une fiche texte. Le contenu de la fiche dépend du suffixe. C’est une référence entre deux ressources. Terraform crée donc l’identifiant avant le fichier.

terraform {
  required_version = ">= 1.16.5"

  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.7"
    }
  }
}

resource "random_id" "suffixe" {
  byte_length = 2
}

resource "local_file" "fiche_environnement" {
  filename = "${path.module}/fiche-environnement.txt"
  content  = "nom=lab-equipe\nsuffixe=${random_id.suffixe.hex}\n"
}

path.module est le dossier de cette configuration. La fiche est écrite à côté de main.tf.

Après un apply, vous devez voir trois choses.

Un fichier fiche-environnement.txt avec un suffixe, par exemple suffixe=a1b2.
Un fichier terraform.tfstate. C’est le carnet local. Il relie le nom random_id.suffixe à la valeur tirée, et le nom local_file.fiche_environnement au fichier créé.
Un second apply qui ne change rien, tant que vous ne modifiez pas main.tf.

Le pas à pas, avec le résultat à vérifier à chaque commande, est dans l’atelier 1 — série neutre. La même histoire sur Azure est dans l’atelier 1 — série Azure.

Pourquoi cet exemple n’est pas un groupe de ressources

Le but du module est le modèle, pas un cloud particulier. Le fichier joue le rôle de la ressource. Le suffixe joue le rôle d’un nom unique. Sur Azure, le groupe de ressources jouera le même rôle au même endroit du fil conducteur.

Ce que l’examen veut pour ce module

Objectif	Vous devez pouvoir l’expliquer
1a	L’infrastructure as code, c’est gérer l’infrastructure par des fichiers de configuration plutôt que par une console.
1b	Les avantages. Reproductibilité, historique, revue, reprise par un collègue, réutilisation, description qui reste la référence.
1c	Le même workflow sert plusieurs cibles parce que les providers sont des plugins. Multi-cloud, hybride, et services qui ne sont pas des machines.

Points à retenir

Vous décrivez l’état voulu. Terraform calcule les actions.
Appliquer deux fois sans changement ne doit pas casser un environnement déjà conforme.
La configuration, le state et la réalité sont trois choses distinctes.
Un provider est le plugin qui parle à une cible. Le workflow devant le provider reste le même.
Le fil conducteur de la semaine est un environnement à faire évoluer et à rendre reprisable. Les modules l’écrivent avec local et random.

Suite

Poursuivre avec le module 2 — Prise en main. Les providers y sont installés, versionnés et combinés plus en détail. Vous pouvez aussi faire l’atelier de ce module maintenant. Il suffit pour voir le modèle tourner.