Quand l'état de votre infrastructure ne correspond pas à la réalité

Vous avez mis en place votre infrastructure en tant que code. Terraform, Pulumi, ou l'outil de votre choix. Tout est tracé, versionné et reproductible. Votre fichier d'état indique que le serveur de production a 4 CPU et 16 Go de RAM. Tout va bien.

Puis un jour, quelqu'un se connecte à la console cloud et redimensionne ce serveur manuellement. Peut-être y avait-il un problème de performance et l'équipe support devait agir vite. Peut-être que quelqu'un a exécuté un script qui n'était pas dans votre code. Quelle qu'en soit la raison, votre fichier d'état indique toujours 4 CPU et 16 Go, mais le serveur tourne maintenant avec 8 CPU et 32 Go.

Cet écart entre ce que dit votre état et ce qui existe réellement s'appelle le drift. Et c'est un problème plus grave que la plupart des équipes ne le pensent.

Pourquoi le drift se produit

Le drift n'est pas rare. Il arrive plus souvent qu'on ne le croit, généralement pour des raisons compréhensibles :

  • Quelqu'un effectue une modification rapide dans la console cloud pendant un incident
  • Une autre équipe exécute sa propre automatisation qui touche à vos ressources
  • Un outil de monitoring scale automatiquement quelque chose sans mettre à jour l'état
  • Un développeur modifie directement une ressource pour tester quelque chose et oublie de revenir en arrière

L'intention n'est presque jamais malveillante. Mais le résultat est le même : votre état devient peu fiable. Et quand l'état n'est pas fiable, chaque déploiement suivant devient un pari. Vous pourriez essayer de mettre à jour une ressource qui ne correspond plus à votre configuration. Ou découvrir que des ressources que vous pensiez exister ont été modifiées ou supprimées. La prochaine fois que vous exécuterez votre pipeline, vous aurez des surprises au lieu de résultats prévisibles.

Le vrai coût du drift

Le drift ne casse pas seulement votre automatisation. Il brise la confiance dans l'ensemble de votre processus de livraison. Quand votre équipe ne peut pas faire confiance au fait que l'infrastructure en tant que code reflète la réalité, elle recommence à faire des modifications manuelles. Et les modifications manuelles entraînent plus de drift. C'est une spirale descendante.

Pour les environnements de production, le drift est particulièrement dangereux. Une ressource modifiée en dehors de votre processus peut se comporter différemment sous charge. Des groupes de sécurité modifiés manuellement peuvent laisser des failles. Des instances de base de données redimensionnées sans mise à jour de l'état peuvent entraîner des coûts ou des problèmes de performance inattendus. Et quand quelque chose tourne mal, vous n'avez aucun enregistrement fiable de ce qui a réellement changé.

Détecter le drift : la méthode simple

L'approche la plus basique pour la détection de drift est la comparaison manuelle. Avec Terraform, exécuter terraform plan montre la différence entre votre code, votre état et l'infrastructure réelle. Toute ressource qui a été modifiée en dehors de votre code apparaîtra comme une modification inattendue.

Voici la commande à exécuter et ce qu'il faut rechercher :

# Exécutez terraform plan sans modification de code pour détecter le drift
terraform plan

# Exemple de sortie montrant un drift (aucune modification de code n'a été faite)
# Terraform va effectuer les actions suivantes :
#
#   # aws_instance.web_server sera mis à jour sur place
#   ~ resource "aws_instance" "web_server" {
#       ~ instance_type = "t3.large" -> "t3.medium"
#         id            = "i-0abcd1234efgh5678"
#         tags          = {}
#         # (12 attributs inchangés masqués)
#     }
#
# Plan: 0 to add, 1 to change, 0 to destroy.

# Toute modification affichée alors que vous n'avez pas modifié votre code = drift

Cette méthode fonctionne pour des vérifications occasionnelles. Mais la détection manuelle a un problème fondamental : vous ne trouvez le drift que lorsque vous le cherchez. Si vous vérifiez une fois par semaine, le drift peut exister pendant des jours avant que vous ne le remarquiez. Et pendant ce temps, il peut causer de vrais problèmes.

Automatiser la détection du drift

Pour les environnements qui nécessitent un contrôle cohérent, la détection du drift doit être automatisée. De nombreuses équipes mettent en place des pipelines planifiés qui exécutent terraform plan ou des commandes équivalentes régulièrement. Quand un drift est détecté, le pipeline envoie une notification à l'équipe.

Certains outils intègrent cette fonctionnalité nativement. Terraform Cloud et Atlantis proposent tous deux une détection automatisée du drift. Pulumi a des capacités similaires. Mais même sans ces outils, vous pouvez configurer un simple cron job ou un pipeline CI planifié qui exécute votre validation d'infrastructure et alerte quand les choses ne correspondent pas.

La détection automatisée est particulièrement importante pour les environnements de production. Le drift en production n'attend pas votre vérification hebdomadaire. Il affecte les utilisateurs immédiatement.

Que faire quand vous trouvez un drift

La détection n'est que la moitié du problème. Une fois que vous savez qu'un drift existe, vous devez décider quoi faire. Vous avez deux options principales :

Le diagramme suivant résume les deux chemins principaux pour gérer le drift :

flowchart TD A[Drift détecté] --> B{La modification était-elle intentionnelle ?} B -->|Non| C[Reconcilier avec le code] B -->|Oui| D{Doit-elle devenir le nouveau standard ?} D -->|Non| C D -->|Oui| E[Mettre à jour l'état pour correspondre à la réalité] C --> F[Exécuter apply pour restaurer l'état désiré] E --> G[Importer la ressource et mettre à jour le code] F --> H[Vérifier qu'il n'y a plus de drift] G --> H H --> I[Documenter le changement]

Option 1 : Revenir à votre code. Exécutez à nouveau votre configuration pour ramener l'infrastructure à l'état désiré. C'est le choix le plus sûr pour les environnements de production. Cela renforce le fait que votre code est la source de vérité et que les modifications manuelles ne persistent pas.

Option 2 : Mettre à jour votre état pour correspondre à la réalité. Importez l'infrastructure actuelle dans votre état, puis mettez à jour votre code pour correspondre. Cela a du sens quand la modification manuelle était intentionnelle et doit devenir le nouveau standard. Mais attention : accepter le drift dans votre état signifie que vous acceptez que l'infrastructure puisse être modifiée en dehors de votre processus défini.

La plupart des équipes matures choisissent l'option un pour la production. Elles reconcilient l'infrastructure avec l'état désiré. Cette pratique s'appelle la réconciliation, et c'est l'idée centrale derrière des outils comme les opérateurs Kubernetes et les workflows GitOps. Le système vérifie en continu que la réalité correspond à l'état désiré et corrige automatiquement tout drift qu'il trouve.

Mettre en place une pratique de détection du drift

Si vous mettez en place la détection de drift pour la première fois, commencez simplement. Exécutez un plan planifié pour vos environnements les plus critiques. Envoyez les résultats dans un canal de discussion où l'équipe peut les voir. Rendez le drift visible avant d'essayer d'automatiser la réponse.

Une fois que l'équipe est habituée à voir les notifications de drift, commencez à automatiser la réponse pour les environnements non productifs. Laissez le pipeline reconcilier automatiquement les environnements de staging et de développement. Pour la production, gardez un humain dans la boucle jusqu'à ce que vous soyez confiant dans votre automatisation.

Et gardez toujours cela à l'esprit : la détection du drift ne consiste pas seulement à attraper les erreurs. Il s'agit de maintenir la confiance dans votre infrastructure en tant que code. Quand votre équipe sait que l'état est précis, elle peut effectuer des modifications en toute confiance. Quand ce n'est pas le cas, tout ralentit.

Checklist pratique

  • Exécutez terraform plan ou équivalent selon un planning pour les environnements de production
  • Envoyez les notifications de drift dans un canal d'équipe
  • Définissez une politique claire : reconcilier avec le code ou mettre à jour l'état
  • Automatisez d'abord la réconciliation pour les environnements non productifs
  • Documentez comment gérer les modifications manuelles intentionnelles
  • Examinez les tendances de drift mensuellement pour identifier les lacunes de processus

Ce qu'il faut retenir

Le drift n'est pas un échec de vos outils. C'est un signal que votre processus a une lacune. Quelqu'un avait besoin de faire une modification, et le processus défini n'a pas fonctionné pour lui. Peut-être était-il trop lent. Peut-être qu'il n'avait pas les accès nécessaires. Peut-être qu'il ne savait pas que le processus existait.

Quand vous trouvez un drift, ne vous contentez pas de corriger l'infrastructure. Corrigez le processus qui a permis au drift de se produire. Facilitez les modifications via le bon chemin plutôt qu'en le contournant. C'est ainsi que vous construisez un système qui reste cohérent sans une vigilance constante.