Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Le serveur “Snowflake” et le désastre ClickOps

Dans l’ancien temps de la culture SysAdmin, un serveur était un animal de compagnie. Vous l’avez nommé “Gandalf” ou “Zeus”. Un développeur se connecterait en SSH au serveur, exécuterait « apt-get install nginx », éditerait un fichier de configuration à l’aide de « vi », redémarrerait le service et modifierait peut-être un paramètre du noyau (sysctl.conf) pour optimiser le débit du réseau. Ils feraient ça pendant 5 ans. Le serveur est devenu un Snowflake. Unique. Beau. Fragile. Si « Gandalf » mourait (panne matérielle), la panique s’ensuivait. “Comment pouvons-nous le reconstruire?” “Je ne sais pas, Bob l’a créé en 2018 et il a quitté l’entreprise.” “Quelle était la configuration ?” “C’était sur le disque dur qui vient de brûler.” Il s’agit de ClickOps (configuration via la console/interface graphique) et d’une administration manuelle. C’est un désastre imminent. À l’ère du cloud, les serveurs sont du bétail, pas des animaux de compagnie. Vous les nommez « web-worker-01 », « web-worker-02 ». Si l’un d’entre eux tombe malade, vous lui tirez dessus et vous en générez un nouveau. Infrastructure as Code (IaC) est la méthodologie qui permet cela. Vous définissez votre infrastructure dans des fichiers texte (.tf). Vous les engagez dans Git. Vous les examinez. Vous les appliquez à l’aide d’une CLI. La machine construit le serveur. Idéalement, aucun humain ne se connectera plus jamais en SSH à une machine.

Pourquoi Maison Code discute de Terraform

Chez Maison Code, nous gérons l’infrastructure de plusieurs clients à forte croissance. Un client gère les ventes Flash (pics de trafic 100x). Un autre gère les données médicales (conformité HIPAA, cryptage strict). Nous ne pouvons pas compter sur la mémoire humaine pour garantir que ces environnements sont corrects. « Ai-je activé le chiffrement sur ce compartiment S3 ? » Si vous comptez sur la mémoire, la réponse est « Peut-être ». Nous utilisons Terraform pour nous assurer que la réponse est « Oui, c’est à la ligne 42 de storage.tf”. Nous construisons des Modules réutilisables. Nous disposons d’un module standard « Maison Code Safe Bucket » qui applique le cryptage, la journalisation et la gestion des versions. Nous l’utilisons pour chaque client. Cela garantit la standardisation et la sécurité à grande échelle. On ne résout pas deux fois le même problème. Nous le résolvons une fois dans Terraform et le déployons partout.

L’outil : HashiCorp Terraform

Terraform est la référence car il est Cloud Agnostic. Vous pouvez l’utiliser pour gérer AWS, Google Cloud, Azure, Cloudflare, GitHub et même votre commande Domino’s Pizza (oui, il existe un fournisseur). Comparez cela à CloudFormation (AWS uniquement) ou aux Modèles ARM (Azure uniquement). Learning Terraform vous donne un super pouvoir dans l’ensemble du secteur. Il utilise HCL (HashiCorp Configuration Language). C’est déclaratif. Vous décrivez la destination, pas le voyage. “Je veux 5 serveurs.” (Terraform découvre comment passer de 2 à 5). Au lieu de “Créer 3 serveurs”. (Impératif).

Exemple : Création d’un compartiment S3

fournisseur "aws" {
  région = "us-east-1"
}

ressource "aws_s3_bucket" "actifs" {
  bucket = "maison-code-assets-prod"
  
  balises = {
    Environnement = "Production"
    Projet = "Maison"
    GéréBy = "Terraform"
  }
}

ressource "aws_s3_bucket_public_access_block" "bloc" {
  seau = aws_s3_bucket.assets.id
  
  block_public_acls = vrai
  block_public_policy = vrai
  ignore_public_acls = vrai
  restrict_public_buckets = vrai
}

ressource "aws_s3_bucket_versioning" "versioning" {
  seau = aws_s3_bucket.assets.id
  configuration_versioning {
    statut = "Activé"
  }
}

Ce code est Documentation. Quiconque le lit sait : “Nous avons un compartiment. Il est explicitement privé. Le contrôle de version est activé (afin que nous puissions récupérer les fichiers supprimés).” C’est mieux qu’un document Word de 50 pages décrivant la configuration du serveur (qui est toujours obsolète).

Le fichier d’état : le cerveau de Terraform

Terraform suit ce qu’il a créé dans un fichier appelé « terraform.tfstate ». Il s’agit d’un fichier JSON qui mappe vos ressources de code (« ressource “aws_instance” “app”) à des identifiants du monde réel (i-0a1b2c3d4e5f). **État actuel par rapport à l'état souhaité**. Lorsque vous exécutez terraform plan`, Terraform :

Lit votre code (État souhaité).
Lit le fichier d’état (dernier état connu).
Actualise l’état (vérifie les API AWS pour voir si les choses ont changé).
Calcule le « Delta » (Diff). Ensuite, il vous dit : “Je prévois d’ajouter 1 ressource, de modifier 2 ressources et de détruire 0 ressource.” Danger : Le fichier d’état contient des secrets (mots de passe, clés privées) en texte brut. Meilleure pratique : ne validez jamais « terraform.tfstate » dans Git. Utilisez un Backend à distance. Stockez l’état dans un compartiment S3 avec le chiffrement côté serveur activé. Utilisez une table DynamoDB pour le verrouillage d’état. Cela empêche deux développeurs d’exécuter « terraform apply » en même temps et de corrompre l’état.

Modules : le principe de NE PAS VOUS RÉPÉTER (À SEC)

Si vous copiez-collez le bloc aws_instance 10 fois pour 10 serveurs, vous vous trompez. Créez un Module.

Définition du module (modules/web-server/main.tf) :

variable "taille" { 
  type = chaîne
  par défaut = "t2.micro" 
}
variable "nom" { type = chaîne }

ressource "aws_instance" "application" {
  ami = "ami-12345678"
  instance_type = var.size
  balises = {
    Nom = var.name
  }
}

Utilisation (main.tf) :

module "frontend" {
  source = "./modules/serveur web"
  taille = "t3.small"
  nom = "Frontend-01"
}

module "back-end" {
  source = "./modules/serveur web"
  taille = "m5.large"
  nom = "API backend"
}

Si vous décidez de modifier l’ID AMI (mettre à niveau la version Ubuntu), vous le modifiez à un seul endroit (le module) et il met à jour tous les serveurs.

Détection de dérive : le test de la réalité

Que se passe-t-il si un développeur malveillant se connecte à la console AWS et modifie manuellement le groupe de sécurité pour ouvrir le port 22 (SSH) au monde ? Il s’agit d’une dérive de configuration. La Réalité ne correspond plus au Code. La prochaine fois que vous exécuterez « terraform plan », Terraform le verra. “Sortie : la règle d’entrée du groupe de sécurité est passée du port 22 (0.0.0.0/0) à NULL.” Il proposera de réparer l’environnement à l’état défini dans le code. Cela impose la discipline. Les modifications de « ClickOps » sont temporaires et seront effacées lors du prochain déploiement.

Espaces de travail Terraform : multi-environnements

Vous avez besoin de développement, de mise en scène et de production. Ne répliquez pas les structures de dossiers (/dev, /prod). Utilisez Espaces de travail. nouvelle étape de l'espace de travail Terraform. terraform workspace nouvelle production. Vous utilisez les mêmes fichiers .tf, mais des fichiers d’état différents (terraform.tfstate.d/staging, terraform.tfstate.d/prod). Dans votre code, vous pouvez utiliser la logique : count = terraform.workspace == "prod" ? 5 : 1. Prod obtient 5 serveurs. Le développeur obtient 1.

Politique en tant que code (Sentinel / OPA)

Dans les grandes organisations, vous souhaitez empêcher les développeurs de commettre des erreurs. “Personne ne peut créer un compartiment S3 public.” “Personne ne peut provisionner une instance plus grande que “grande” (trop chère).” Vous pouvez utiliser Open Policy Agent (OPA) ou HashiCorp Sentinel. Il s’exécute avant terraform apply. Si le plan enfreint la stratégie, il bloque le déploiement. Il s’agit de Gouvernance automatisée.

Le point de vue du sceptique

“C’est trop passe-partout. Je peux simplement cliquer sur le bouton plus rapidement.” Contre-point : Cliquer est plus rapide une fois. Mais vous devez le maintenir pour toujours. Si vous devez répliquer l’environnement dans une autre région (reprise après sinistre), cliquer prend des jours et est sujet aux erreurs. Terraform prend quelques minutes (region = "eu-west-1"). De plus, « ClickOps » ne peut pas faire l’objet d’une révision de code. Vous ne pouvez pas ouvrir une Pull Request pour un clic de souris. Vous ne pouvez pas annuler un clic de souris (facilement). Le code est auditable. Le code, c’est la raison.

##FAQ

Q : Terraform contre Ansible ? R : Terraform provisionne l’infrastructure (le matériel : VPC, EC2, RDS). Ansible configure le logiciel (Le logiciel : Apache, MySQL Config, Users). Dans le monde moderne de « l’infrastructure immuable » (Docker), Ansible est moins nécessaire. Nous intégrons le logiciel dans l’image Docker. Terraform déploie le service de conteneur (ECS/EKS). Utilisez Terraform pour le cloud. Utilisez Ansible pour le système d’exploitation (si vous n’utilisez pas de conteneurs).

Q : Qu’est-ce que main.tf, variables.tf, outputs.tf ? R : C’est une convention. Terraform lit tous les fichiers .tf du répertoire.

main.tf : Les ressources.
variables.tf : arguments d’entrée.
outputs.tf : ce qu’il faut imprimer à la fin (par exemple, l’URL de l’équilibreur de charge).

Q : Actions Terraform Cloud contre Jenkins/GitHub ? R : Terraform Cloud offre des fonctionnalités intéressantes :

Gestion de l’état à distance (intégrée).
Registre de modules privés.
Estimation des coûts (« Ce changement augmentera votre facture de 50 € »). Cependant, vous pouvez exécuter gratuitement Terraform CLI dans GitHub Actions à l’aide d’un backend S3. Terraform Cloud est payant (par utilisateur). Nous commençons généralement par les actions GitHub et effectuons une mise à niveau si nécessaire.

Conclusion

L’Infrastructure as Code transforme les « Ops » en « Dev ». Il amène la discipline de l’ingénierie logicielle (Contrôle de version, Révision de code, Tests, CI/CD) au monde du matériel. Si ce n’est pas dans git, ça n’existe pas. Arrêtez de construire des flocons de neige. Commencez à construire des Legos.

Cliquer manuellement sur les boutons ?

Si votre infrastructure est un délicat flocon de neige que vous avez peur de toucher, Maison Code peut la terraformer. Nous effectuons une rétro-ingénierie de votre configuration « ClickOps » existante et la codifions en modules Terraform robustes et réutilisables. Nous mettons en œuvre des workflows de verrouillage d’état, de détection de dérive et de reprise après sinistre.

Engagez nos Architectes.