Quand l'infrastructure change en dehors de votre pipeline : un exercice de détection de dérive

Vous avez une configuration Terraform qui définit un groupe de sécurité. Il a le bon nom, les bonnes règles d'entrée et les bonnes étiquettes. Votre pipeline s'est exécuté avec succès, la ressource a été créée et votre fichier d'état est propre. Tout semble correct.

Puis quelqu'un se connecte à la console cloud et effectue une petite modification. Peut-être renomme-t-il le groupe de sécurité parce qu'il était ambigu. Peut-être ajoute-t-il une règle d'entrée pour tester rapidement quelque chose. Peut-être supprime-t-il une étiquette qui semblait inutile. Aucune modification de code. Aucune exécution de pipeline. Juste un ajustement manuel dans la console.

Votre infrastructure est désormais différente de ce que votre code indique qu'elle devrait être. Cette différence s'appelle la dérive. Et si vous ne savez pas qu'elle s'est produite, votre prochain déploiement pourrait casser des choses de manière inattendue.

À quoi ressemble réellement la dérive

La dérive se produit lorsque l'état réel de votre infrastructure s'écarte de l'état souhaité défini dans votre code. Ce n'est pas un problème théorique. Cela arrive tout le temps dans les équipes réelles :

  • Quelqu'un corrige un problème urgent directement en production parce que le pipeline prendrait trop de temps.
  • Un fournisseur cloud fait automatiquement tourner un certificat ou modifie un paramètre par défaut.
  • Un membre de l'équipe supprime accidentellement une ressource en nettoyant autre chose.
  • Une politique automatisée en dehors de votre pipeline modifie une ressource pour des raisons de conformité.

Le problème n'est pas que la dérive existe. Le problème est que vous n'êtes pas au courant jusqu'à ce que quelque chose casse.

Un exercice simple pour voir la dérive en action

Vous pouvez simuler la dérive dans votre propre environnement avec une configuration minimale. Vous avez besoin d'un compte cloud avec des ressources de niveau gratuit, ou vous pouvez utiliser un simulateur local comme LocalStack. Même un fichier d'état factice fonctionnera à des fins d'apprentissage.

Commencez par créer une ressource avec Terraform. Un groupe de sécurité dans AWS ou un bucket de stockage chez n'importe quel fournisseur cloud fonctionne bien. Exécutez votre pipeline jusqu'à ce que la ressource soit créée et que le fichier d'état soit enregistré. Assurez-vous de pouvoir voir la ressource dans la console cloud.

Voici une configuration Terraform minimale que vous pouvez utiliser pour suivre l'exercice :

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Autoriser le trafic HTTP et 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"]
  }

  tags = {
    Name = "web-server-sg"
    Env  = "test"
  }
}

Exécutez terraform init et terraform apply pour créer le groupe de sécurité. Ensuite, dans la console AWS, renommez manuellement le groupe de sécurité en web-server-sg-manual et supprimez l'étiquette Env. Enfin, exécutez terraform plan pour voir la dérive :

$ terraform plan
aws_security_group.web_sg: Refreshing state... [id=sg-0123456789abcdef0]

Terraform va effectuer les actions suivantes :

  # aws_security_group.web_sg sera mis à jour sur place
  ~ resource "aws_security_group" "web_sg" {
        id          = "sg-0123456789abcdef0"
      ~ name        = "web-server-sg-manual" -> "web-server-sg"
        tags        = {
          - "Env"  = "test" -> null
            "Name" = "web-server-sg"
        }
        # (6 attributs inchangés masqués)
    }

Plan : 0 à ajouter, 1 à modifier, 0 à détruire.

Le plan montre que Terraform va rétablir le nom et rajouter l'étiquette manquante. C'est la dérive en action.

Maintenant, sans toucher à votre code Terraform, ouvrez la console cloud et effectuez une modification manuelle. Voici quelques choses que vous pouvez essayer :

  • Renommer le groupe de sécurité.
  • Ajouter une règle d'entrée qui n'existe pas dans votre code.
  • Supprimer une étiquette que votre code définit.
  • Modifier le paramètre d'accès public du bucket.

L'objectif est de créer une situation où la ressource réelle ne correspond plus à votre code. C'est la dérive.

Le diagramme suivant illustre la séquence des événements dans cet exercice de détection de dérive :

flowchart TD A[État souhaité : Config Terraform] --> B[Pipeline crée la ressource] B --> C[État réel correspond à la config] C --> D[Modification manuelle dans la console] D --> E[État réel dérive de la config] E --> F[Exécuter terraform plan] F --> G{Le plan montre des changements ?} G -- Oui --> H[Dérive détectée] G -- Non --> I[Aucune dérive] H --> J{Décision de réconciliation} J -- Accepter le changement --> K[Mettre à jour le code Terraform] J -- Restaurer la config --> L[Exécuter terraform apply] K --> M[Pipeline s'exécute, état correspond] L --> M

Exécuter Terraform Plan après la dérive

Une fois que vous avez effectué la modification manuelle, exécutez terraform plan dans votre terminal. Examinez attentivement la sortie. Terraform va comparer votre fichier d'état avec la ressource réelle et vous montrer ce qu'il changerait si vous exécutiez apply.

Remarquez quelque chose d'important : le plan peut montrer des changements auxquels vous ne vous attendiez pas. Peut-être veut-il renommer le groupe de sécurité pour revenir au nom d'origine. Peut-être veut-il supprimer la règle que quelqu'un a ajoutée. Mais il peut aussi montrer des changements sur d'autres ressources qui dépendent de celle que vous avez modifiée. Un simple renommage pourrait affecter un équilibreur de charge, un groupe cible ou une politique IAM qui référence le groupe de sécurité par son nom.

C'est pourquoi vous ne pouvez pas faire aveuglément confiance à un plan après une dérive. Le plan peut être correct, mais vous devez vérifier chaque changement proposé. Un plan qui semble propre en surface pourrait cacher des effets en cascade qui cassent d'autres parties de votre infrastructure.

Détecter la dérive explicitement

Terraform a une commande appelée terraform refresh qui met à jour votre fichier d'état avec l'état réel de vos ressources. Exécutez-la, puis exécutez terraform plan à nouveau. Vous verrez la même dérive, mais maintenant votre fichier d'état reflète la réalité. C'est utile pour comprendre ce qui a changé, mais cela ne corrige pas la dérive. Cela ne fait que la reconnaître.

Certaines plateformes comme Spacelift ou Terragrunt ont une détection de dérive intégrée qui s'exécute selon un planning. Elles peuvent vous notifier lorsqu'une dérive est détectée, et certaines peuvent même déclencher une réconciliation automatique. Mais pour cet exercice, la détection manuelle suffit pour comprendre les mécanismes.

Notez quelles ressources ont dérivé et ce qui a changé. Cet enregistrement vous aidera à réfléchir à l'étape suivante.

Prendre une décision de réconciliation

Vous avez maintenant un choix. Vous savez que l'infrastructure a dérivé. Vous savez ce qui a changé. Que faites-vous à ce sujet ?

Posez-vous ces questions :

  • La modification manuelle était-elle intentionnelle ? Quelqu'un l'a-t-il faite pour une raison légitime, comme corriger un problème urgent ?
  • Le changement est-il toujours nécessaire ? Peut-être que l'urgence est terminée et que la ressource devrait revenir à son état d'origine.
  • Est-il sûr d'annuler le changement ? L'annulation pourrait casser quelque chose qui dépend maintenant de la nouvelle configuration.
  • Quelqu'un dans l'équipe sait-il pourquoi le changement a été fait ? Y a-t-il une trace dans un ticket ou un journal de discussion ?

Si vous décidez de réconcilier, exécutez terraform apply. La ressource devrait revenir à l'état défini dans votre code. Vérifiez que tout fonctionne comme prévu.

Si vous décidez d'adopter le changement, mettez à jour votre code Terraform pour correspondre à l'état réel. Exécutez ensuite votre pipeline normalement. La dérive est maintenant résolue car votre code et votre infrastructure sont à nouveau en accord.

Variations à essayer

Une fois que vous avez compris le scénario de base, essayez des variations plus complexes :

  • Effectuez un changement temporaire, comme augmenter la capacité d'une instance lors d'un pic de trafic. Voyez comment la détection de dérive le rattrape après la fin du pic.
  • Modifiez une ressource qui a des dépendances, comme changer la configuration d'un équilibreur de charge qui se connecte à un groupe cible. Observez comment le plan montre les effets en cascade.
  • Créez un changement difficile à annuler, comme supprimer une ressource dont d'autres ressources dépendent. Voyez comment Terraform gère la chaîne de dépendances.

Chaque variation vous apprend quelque chose sur la façon dont la dérive se comporte dans les systèmes réels. Plus le scénario est complexe, plus il devient clair que la détection et la réconciliation de la dérive nécessitent une réflexion approfondie, pas seulement de l'automatisation.

Une liste de contrôle pratique pour la gestion de la dérive

Avant de continuer, voici une courte liste de contrôle à appliquer dans votre propre environnement :

  • Mettez en place une détection automatisée de la dérive sur vos ressources d'infrastructure critiques.
  • Définissez un processus clair pour gérer la dérive : qui est notifié, comment les décisions sont prises et quand la réconciliation est déclenchée.
  • Conservez un enregistrement des modifications manuelles, même temporaires, afin que l'équipe sache pourquoi la dérive existe.
  • Testez votre processus de réconciliation dans un environnement non production avant de l'appliquer à la production.
  • Examinez régulièrement les rapports de dérive, pas seulement quand quelque chose casse.

Ce que cet exercice vous apprend

La dérive n'est pas un concept théorique. C'est un problème opérationnel réel auquel chaque équipe est confrontée lorsque l'infrastructure est gérée via du code. L'exercice vous montre que la dérive peut se produire silencieusement, qu'elle peut affecter plus que la seule ressource modifiée, et que les décisions de réconciliation dépendent toujours du contexte.

Vous ne pouvez pas empêcher toute dérive. Les gens feront des modifications manuelles. Les fournisseurs cloud modifieront des ressources. Des urgences surviendront. Ce que vous pouvez faire, c'est détecter la dérive tôt, comprendre son impact et prendre des décisions éclairées sur le fait d'annuler ou d'adopter le changement.

La prochaine fois que quelqu'un dira "J'ai juste fait une correction rapide dans la console", vous saurez exactement ce que cela signifie pour votre infrastructure. Et vous aurez un processus prêt à gérer la situation.