Terraform a été conçu pour permettre aux utilisateurs de définir et de provisionner l'infrastructure à l'aide d'un langage de configuration simple et déclaratif. Cette approche visait à rendre les configurations reproductibles et à faciliter la gestion de versions, un élément indispensable.
Dans le cas de Terraform, le langage utilisé pour définir l’infrastructure est connu sous le nom de HashiCorp Configuration Langage (HCL).
L'objectif principal de Terraform est de déclarer des ressources, qui représentent des objets d'infrastructure. Toutes les autres fonctionnalités de son langage permettent de rendre la définition des ressources plus flexible et pratique.
Pour le moment nous allons nous concentrer sur la description du workflow de Terraform et l'écriture des fichiers de déclarations.

Le workflow de Terraform reposent sur cinq étapes clés : Write, Init, Plan, Apply et Destroy et sur l'enregistrement du state:
Ensuite, vous modifiez votre code, vous rebouclez par plan, apply et ainsi de suite. La phase de destroy n'intervenant que lorsque vous n'avez plus besoin de ces ressources.
La gestion de l'état est un aspect important du workflow de Terraform. L'état de l'infrastructure est stocké dans un fichier d'état, généralement stocké localement ou de manière centralisée via un backend distant. Il est important de gérer cet état avec soin pour assurer la cohérence de l'infrastructure et éviter les conflits.
Par défaut cet état est stocké dans un fichier local nommé terraform.tfstate, mais il peut également être stocké à distance, mais pas dans votre repository git, car il peut contenir des secrets.
Terraform utilise cet état pour créer des plans et apporter des modifications à votre infrastructure. Avant toute opération, Terraform effectue un rafraîchissement pour mettre à jour l'état avec celle de l'infrastructure réelle.
Pour les distributions Linux, HashiCorp fournit un dépôt officiel permettant d'installer Terraform avec des gestionnaires de paquets tels que apt (pour Ubuntu/Debian) et dnf (pour CentOS/RHEL).
sudo apt update && sudo apt install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform
Sur Windows, vous pouvez utiliser le gestionnaire de paquets Chocolatey pour installer Terraform. Assurez-vous que vous avez Chocolatey installé. Si ce n'est pas le cas, installez-le depuis https://chocolatey.org.
Ouvrez une invite de commandes ou PowerShell en tant qu'administrateur.
choco install terraform
Après avoir suivi ces étapes d'installation, vous pouvez vérifier que Terraform est correctement installé en exécutant la commande terraform version. Elle affichera la version de Terraform installée sur votre système.
La CLI de Terraform possède les commandes suivantes :
init : La commande init va initialiser le répertoire de travail et vérifier que les plugins utilisés sont correctement installés.plan : La commande plan permet de créer un plan d'exécution. Terraform va indiquer quelles actions il doit effectuer pour arriver au résultat décrit dans le fichier de configuration.apply : L'infrastructure voulue est mise en place.console : Cette commande permet de faire du débogage, avant de créer un plan ou de l'appliquer.destroy : L'infrastructure est détruitePour les utilisateurs de Terraform, la registry Terraform permet la distribution des modules Terraform, qui sont en fait des configurations réutilisables et de se fournir en providers. Comme avec docker, vous pouvez créer une registry locale pour y stocker votre propre code.
Pour un projet très simple, vous pouvez regrouper tout dans un seul fichier main.tf. Cependant, je vous conseille d'adopter une structure pour vous y retrouver facilement dans tous vos projets, voici la structure que j'ai adoptée :
.
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf
├── resources.tf
├── provider.tf
├── terraform.tfvars
├── modules/
└── module1/
└── README.md
└── variables.tf
└── main.tf
└── outputs.tf
main.tf qui est le fichier principal d'un projet terraformprovider.tf pour y définir les fournisseursvariables.tf pour les variables principalesterraform.tfvars pour les variables secrètes qui ne sera pas stocké dans votre repository gitoutputs.tf pour y définir tout ce qui sera affichéresources.tf pour un petit projet un simple fichier resources.tf suffira pour de plus prend vous pouvez en créer plusieurs avec des noms explicites..gitignore dont voici le contenu :# Local .terraform directories
**/.terraform/*
# .tfstate files
*.tfstate
*.tfstate.*
# Crash log files
crash.log
# Exclude all .tfvars files, which are likely to contain sentitive data, such as
# password, private keys, and other secrets. These should not be part of version
# control as they are data points which are potentially sensitive and subject
# to change depending on the environment.
#
*.tfvars
# Ignore override files as they are usually used to override resources locally and so
# are not checked in
override.tf
override.tf.json
*_override.tf
*_override.tf.json
# Include override files you do wish to add to version control using negated pattern
#
# !example_override.tf
# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
# example: *tfplan*
# Ignore CLI configuration files
.terraformrc
terraform.rc
L'ordre des blocs et des fichiers dans lesquels ils sont organisés ne sont généralement pas significatifs ; En effet Terraform utilise les relations implicites et explicites entre les ressources pour déterminer dans quel ordre les opérations vont s'exécuter.