25-1 · Chapitre 25 · 6 min de lecture

Infrastructure as Code : pourquoi la configuration de vos serveurs doit être dans Git

Découvrez pourquoi l'Infrastructure as Code (IaC) est essentielle pour vos pipelines CI/CD. Apprenez à gérer vos serveurs, réseaux et bases de données comme du code, avec des exemples Terraform.

Infrastructure as Code : pourquoi la configuration de vos serveurs doit être dans Git

Vous vous apprêtez à déployer une nouvelle fonctionnalité. Le code applicatif est prêt, les tests passent, la pull request a été approuvée. Mais soudain, quelqu'un demande : « Est-ce qu'on a mis à jour la configuration du load balancer pour le nouvel endpoint ? » Personne n'en est sûr. La personne qui a fait la dernière modification du load balancer est en congé. Le tableau de bord du cloud affiche la configuration actuelle, mais personne ne sait ce qui a changé la semaine dernière ni pourquoi.

Ce scénario se joue tous les jours dans les équipes. Les changements d'infrastructure dépendent de connaissances tribales, d'étapes manuelles et de la disponibilité de certaines personnes. Si cette personne n'est pas là, le changement attend. Si elle oublie une étape, le serveur tombe en silence. Et quand quelque chose tourne mal, trouver la cause racine signifie fouiller les logs de chat, les e-mails et la mémoire.

Il existe une meilleure façon. Écrivez votre infrastructure comme du code.

Ce que signifie réellement Infrastructure as Code

L'Infrastructure as Code (IaC) est la pratique qui consiste à définir vos serveurs, réseaux, bases de données, load balancers et tous les autres composants d'infrastructure dans des fichiers texte. Ces fichiers vivent dans un dépôt de contrôle de version, exactement comme votre code applicatif.

Le changement clé réside dans la façon dont vous décrivez l'infrastructure. Au lieu d'écrire des commandes étape par étape comme « SSH dans le serveur, exécute cette commande pour installer Nginx, puis édite ce fichier de configuration », vous écrivez une déclaration de ce à quoi l'infrastructure devrait ressembler. Par exemple : « Je veux un serveur exécutant Nginx version 1.24, écoutant sur le port 443, avec ce certificat TLS et ces règles de proxy. »

L'outil qui traite ces fichiers lit votre déclaration, la compare à l'état actuel de votre infrastructure et effectue les modifications nécessaires pour correspondre. C'est ce qu'on appelle la gestion par état désiré.

Voici à quoi ressemble une configuration déclarative simple en Terraform :

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  user_data = <<-EOF
              #!/bin/bash
              apt-get update
              apt-get install -y nginx
              systemctl enable nginx
              systemctl start nginx
              EOF

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

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Allow HTTP and SSH"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ce fichier déclare exactement ce que vous voulez : une instance EC2 avec Nginx installé et un groupe de sécurité qui autorise le trafic web. Terraform compare cette déclaration à l'état actuel de votre compte AWS et n'effectue que les modifications nécessaires pour correspondre.

Comment cela change votre travail quotidien

Quand l'infrastructure est du code, modifier la configuration d'un serveur ne signifie plus se connecter à une machine et taper des commandes. Cela signifie éditer un fichier, ouvrir une pull request, obtenir une revue et fusionner le changement. Le serveur se met à jour automatiquement lorsque la nouvelle configuration est appliquée.

Cela transforme l'ensemble du flux de travail :

Chaque changement est tracé. L'historique des commits dans votre dépôt vous dit exactement à quoi ressemblait la configuration du load balancer de production mardi dernier. Fini les suppositions, fini les « Je crois que quelqu'un a changé ce paramètre. »
Les changements sont révisables. Avant qu'un changement d'infrastructure n'atteigne la production, il passe par le même processus de revue de code que les changements applicatifs. Les membres de l'équipe peuvent commenter, suggérer des améliorations et détecter les erreurs avant qu'elles ne causent une indisponibilité.
N'importe qui peut proposer des changements. Un développeur qui a besoin d'un nouveau pool de connexions à la base de données peut écrire la configuration et soumettre une pull request. Il n'a pas besoin d'attendre que l'équipe d'exploitation ait du temps libre. L'équipe d'exploitation révise le changement au lieu de l'exécuter.
Les rollbacks sont simples. Si un changement de configuration pose problème, vous revenez sur le commit et réappliquez. Vous n'avez pas besoin de vous souvenir de la séquence exacte des étapes manuelles pour annuler le changement.

Le concept d'état désiré

L'idée la plus importante dans l'infrastructure as code est l'état désiré. Vos fichiers de configuration décrivent l'état idéal de votre infrastructure. L'outil IaC s'assure en continu que l'état réel correspond à l'état désiré.

Si quelqu'un modifie manuellement un paramètre sur un serveur, l'outil détecte la dérive et le rétablit. Si un serveur plante et est remplacé, l'outil provisionne le nouveau serveur avec la configuration correcte automatiquement. Vous n'écrivez pas des scripts qui s'exécutent une seule fois. Vous définissez une cible, et le système maintient cette cible.

C'est fondamentalement différent de l'ancienne approche où vous écriviez un script pour configurer un serveur, l'exécutiez une fois, et espériez que rien ne change après. Avec l'état désiré, le système est auto-cicatrisant et auto-auditeur.

Ce que l'Infrastructure as Code n'est pas

L'Infrastructure as Code n'est pas un outil spécifique. Terraform, AWS CloudFormation, Ansible, Pulumi et bien d'autres sont des implémentations du concept. L'outil importe moins que la pratique de traiter la configuration d'infrastructure comme du code versionné, révisable et déclaratif.

Ce n'est pas non plus une question d'éliminer complètement le travail manuel. Vous devez toujours comprendre votre infrastructure. Vous prenez toujours des décisions de conception concernant le réseau, la sécurité et la mise à l'échelle. Mais ces décisions sont encodées dans des fichiers qui peuvent être révisés, testés et reproduits.

Pourquoi c'est important pour le CI/CD

L'Infrastructure as Code est le fondement pour traiter les changements d'infrastructure de la même manière que vous traitez les changements applicatifs dans votre pipeline CI/CD. Quand votre infrastructure est du code, vous pouvez :

Exécuter des tests automatisés sur les changements d'infrastructure avant de les appliquer
Valider que les fichiers de configuration sont syntaxiquement corrects
Vérifier automatiquement les violations de politique de sécurité
Appliquer les changements via le même pipeline qui déploie votre application
Assurer la cohérence entre les environnements

Sans infrastructure as code, votre pipeline CI/CD ne peut gérer que le code applicatif. Les changements d'infrastructure restent manuels, sujets aux erreurs et invisibles pour le pipeline. Cela crée un fossé où les déploiements applicatifs sont automatisés mais l'infrastructure sur laquelle ils tournent ne l'est pas.

Checklist pratique pour démarrer

Si vous envisagez d'adopter l'infrastructure as code, voici un point de départ pratique :

Choisissez un environnement pour commencer. N'essayez pas de convertir toute votre infrastructure d'un coup. Commencez par un environnement de staging ou de développement.
Écrivez des fichiers déclaratifs, pas des scripts. Concentrez-vous sur ce que vous voulez, pas sur comment y parvenir. Les fichiers déclaratifs sont plus faciles à réviser et à maintenir.
Stockez tout dans le contrôle de version. Votre dépôt doit contenir tous les fichiers de configuration, pas seulement ceux qui changent fréquemment.
Révisez les changements d'infrastructure comme du code. Exigez des pull requests et des approbations pour les changements d'infrastructure, comme vous le faites pour les changements applicatifs.
Testez avant d'appliquer. Utilisez des outils qui peuvent valider vos fichiers de configuration et simuler les changements avant qu'ils n'atteignent les vrais serveurs.
Documentez l'état désiré, pas les étapes. Vos fichiers doivent décrire la configuration cible, pas la séquence de commandes pour y parvenir.

Ce qu'il faut retenir

L'Infrastructure as Code transforme les serveurs de boîtes noires comprises par quelques personnes en composants documentés, reproductibles et gérables. Chaque changement de configuration laisse une trace dans votre historique de commits. Chaque serveur peut être reconstruit à partir de zéro avec des résultats cohérents. Chaque membre de l'équipe peut proposer des améliorations d'infrastructure sans avoir besoin d'un accès opérationnel profond.

La prochaine fois que quelqu'un demandera ce qui a changé en production la semaine dernière, vous n'aurez pas à deviner. Vous ouvrirez le dépôt et vérifierez le journal des commits. C'est la différence entre l'infrastructure comme art et l'infrastructure comme code.