Écrivez votre infrastructure en code avant de cliquer sur un autre bouton

Vous avez une application qui nécessite un serveur et une base de données. L'approche habituelle consiste à vous connecter à la console de votre fournisseur cloud, à naviguer dans quelques pages, à sélectionner des types d'instances, à configurer le stockage, à paramétrer le réseau, et à espérer n'avoir oublié aucune étape. Quand vous devez refaire la même chose pour l'environnement de staging, vous répétez tout le processus. Quand un membre de l'équipe demande quelle infrastructure tourne en production, vous lui envoyez des captures d'écran.

Ce workflow fonctionne jusqu'au jour où il ne fonctionne plus. Une case à cocher oubliée, une mauvaise sélection de région, une règle de groupe de sécurité manquante, et votre application soit ne démarre pas, soit tourne avec une vulnérabilité que vous n'aviez pas prévue.

Il existe une meilleure façon : écrivez votre infrastructure en code.

Ce que signifie réellement Infrastructure as Code

L'Infrastructure as Code (IaC) est la pratique qui consiste à définir vos serveurs, bases de données, réseaux et autres ressources cloud dans des fichiers texte plutôt qu'en cliquant dans une interface graphique. Ces fichiers décrivent l'état souhaité de votre infrastructure. Vous les stockez dans un système de gestion de versions, vous les révisez comme du code applicatif, et vous les appliquez de manière cohérente entre les environnements.

L'idée clé est que vous n'écrivez pas un script qui dit « étape un, créer un serveur, étape deux, attendre, étape trois, créer une base de données ». Au lieu de cela, vous déclarez l'état final que vous voulez atteindre. L'outil détermine lui-même l'ordre des opérations en fonction des dépendances entre les ressources.

Écrire votre première configuration

Terraform est l'un des outils IaC les plus utilisés. Vous écrivez des fichiers de configuration avec l'extension .tf. Chaque fichier déclare les ressources dont vous avez besoin et comment elles sont connectées.

Commencez par un fichier nommé main.tf. La première chose à définir est le provider. Un provider est un plugin qui permet à Terraform de communiquer avec une plateforme spécifique comme AWS, Google Cloud ou Azure. Il indique à Terraform où créer les ressources et quelles informations d'identification utiliser.

provider "aws" {
  region = "ap-southeast-1"
}

Une fois le provider configuré, vous définissez les ressources. Chaque ressource suit ce modèle : resource "type" "nom_local". Le nom local est utilisé uniquement à l'intérieur de votre configuration. Ce n'est pas le nom qui apparaît dans la console de votre fournisseur cloud.

Voici comment créer un serveur virtuel, qu'AWS appelle une instance EC2 :

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "app-server"
  }
}

Et voici une base de données PostgreSQL utilisant RDS :

resource "aws_db_instance" "app_database" {
  allocated_storage    = 20
  engine               = "postgres"
  engine_version       = "15"
  instance_class       = "db.t3.micro"
  db_name              = "myapp"
  username             = "admin"
  password             = var.db_password
  skip_final_snapshot  = true
}

Remarquez un point important : vous n'avez pas écrit d'étapes. Vous n'avez pas dit « crée d'abord le serveur, puis attends qu'il soit prêt, puis crée la base de données ». Vous avez déclaré ce que vous voulez. Terraform analyse la configuration, détermine que la base de données ne dépend pas du serveur, et les crée en parallèle. Si une ressource dépend d'une autre, Terraform gère l'ordre automatiquement.

Pourquoi cela semble plus lourd au début

Écrire des fichiers de configuration prend plus de temps au départ que de cliquer dans une console. Vous devez connaître les types de ressources exacts, leurs arguments obligatoires, et comment structurer les fichiers. La console vous montre des menus déroulants et des cases à cocher. Le fichier de configuration attend de vous que vous sachiez ce que signifie ami-0c55b159cbfafe1f0 ou à quoi correspond db.t3.micro.

Mais ce coût initial est rentabilisé dès que vous devez reproduire la configuration. Vous voulez un environnement de staging qui reflète la production ? Copiez les fichiers, modifiez quelques valeurs, et exécutez la même configuration. Vous voulez comprendre quelle infrastructure est déployée ? Lisez les fichiers au lieu de fouiller dans la console. Vous voulez examiner un changement avant qu'il ne soit appliqué ? Ouvrez une pull request et laissez votre équipe commenter la différence.

Stockez la configuration dans un système de gestion de versions

Vos fichiers .tf doivent vivre dans un dépôt Git. Cela peut être le même dépôt que celui de votre code applicatif ou un dépôt d'infrastructure séparé. Dans les deux cas, chaque modification de l'infrastructure suit le même workflow que les changements de code : écrire, commit, réviser, merger, appliquer.

Cela vous offre plusieurs avantages :

• Chaque changement d'infrastructure est enregistré avec l'auteur et la raison.
• Vous pouvez revenir à un état précédent si quelque chose se passe mal.
• Les nouveaux membres de l'équipe peuvent voir l'intégralité de la configuration de l'infrastructure en lisant le dépôt.
• Des vérifications automatisées peuvent valider la configuration avant qu'elle n'atteigne la production.

Ce que vous ne faites pas

Quand vous écrivez l'infrastructure en code, vous n'écrivez pas un script de déploiement. Un script exécute des commandes en séquence. Si l'étape trois échoue, le script s'arrête et vous vous retrouvez avec une infrastructure partiellement créée. Les outils IaC comme Terraform sont déclaratifs. Ils comparent l'état actuel de votre infrastructure avec l'état souhaité dans votre configuration et n'effectuent que les changements nécessaires pour atteindre cet état.

Cette différence est cruciale quand vous devez mettre à jour l'infrastructure. Au lieu d'écrire un nouveau script qui tient compte de l'état actuel, vous mettez à jour le fichier de configuration. Terraform détermine quoi ajouter, modifier ou supprimer.

Le workflow pratique

Le workflow typique de Terraform comporte trois phases : écrire, planifier, appliquer.

D'abord, vous écrivez ou modifiez vos fichiers .tf. C'est là que vous définissez l'infrastructure souhaitée.

Ensuite, vous exécutez terraform plan. Cette commande vous montre ce que Terraform va faire sans réellement le faire. Elle affiche un diff détaillé : quelles ressources seront créées, lesquelles seront modifiées, et lesquelles seront détruites. Vous examinez ce plan avant de continuer.

Troisièmement, vous exécutez terraform apply pour exécuter le plan. Terraform effectue les appels API à votre fournisseur cloud pour créer, mettre à jour ou supprimer des ressources jusqu'à ce que l'état réel corresponde à votre configuration.

Une checklist rapide pour votre première configuration IaC

• Choisissez un fournisseur cloud et installez le CLI Terraform.
• Créez un fichier main.tf avec votre bloc provider.
• Définissez au moins une ressource, comme une machine virtuelle ou une base de données.
• Exécutez terraform init pour télécharger le plugin provider.
• Exécutez terraform plan pour voir ce qui sera créé.
• Exécutez terraform apply pour créer les ressources.
• Stockez tous les fichiers .tf dans un dépôt Git et poussez-les.

La vraie valeur apparaît plus tard

Écrire l'infrastructure en code semble être un travail supplémentaire le premier jour. Au trentième jour, quand vous devez ajouter un nouvel environnement ou vous remettre d'une erreur, cela semble être la seule façon sensée de travailler. Les fichiers de configuration deviennent la source unique de vérité pour votre infrastructure. Fini les suppositions sur ce qui tourne en production. Fini les étapes manuelles que quelqu'un pourrait oublier. Fini l'infrastructure que seule une personne sait recréer.

Commencez par une ressource. Écrivez-la dans un fichier. Mettez-la dans Git. Puis ajoutez la ressource suivante. L'habitude se construit plus vite que vous ne le pensez, et la confiance qu'elle vous apporte vaut la friction initiale.