Organisez le partage de l’état Terraform, les droits et les validations pour modifier votre infrastructure cloud en équipe sans perdre son suivi.
Deux personnes travaillent sur le même environnement cloud. Chacune dispose du code Terraform, mais une seule possède le fichier d’état à jour sur son ordinateur. Avant de lancer une nouvelle modification, l’équipe doit savoir quelle copie décrit les ressources déjà gérées. Copier ce fichier par messagerie rend cette vérification difficile à répéter.
Le partage de l’état demande une décision sur son stockage et sur les personnes autorisées à l’utiliser. Pour une petite équipe, il faut aussi prévoir le départ d’un prestataire, l’indisponibilité d’un compte et l’échec d’une exécution.
Désigner une référence commune
La documentation Terraform sur le stockage distant explique comment un backend permet aux membres d’une équipe d’accéder à un état partagé. Ses capacités dépendent du backend retenu. Vérifiez sa documentation avant de supposer qu’il fournit chiffrement, historique ou verrouillage.
Inscrivez dans le dossier du projet l’emplacement de l’état utilisé pour chaque environnement et l’identité qui y accède depuis le pipeline. Évitez une désignation telle que « bucket de Paul ». Le compte de stockage doit appartenir à l’organisation qui exploite l’infrastructure.
Avant une migration d’un état local, arrêtez les modifications sur le périmètre concerné. Identifiez la copie de référence, sauvegardez-la dans un emplacement protégé et préparez les étapes de migration correspondant à votre backend. Vérifiez ensuite que le prochain plan vise les ressources attendues. Un plan qui propose soudain de tout créer mérite une investigation avant toute application.
Vérifier ce que protège le verrou
Terraform peut verrouiller l’état pour les opérations qui risquent de l’écrire, lorsque le backend prend en charge cette fonction. Un échec d’acquisition du verrou doit conduire à vérifier l’exécution en cours. La documentation déconseille de désactiver ce mécanisme et réserve le déverrouillage forcé aux situations où le verrou n’est plus légitimement utilisé.
Dans votre procédure, demandez à l’opérateur d’identifier le lancement précédent : pipeline, machine, personne et heure. Un message d’erreur ne prouve pas à lui seul que le traitement s’est arrêté. Conservez le lien vers l’exécution qui possède le verrou dans le ticket d’intervention.
Le verrou ne remplace pas la coordination des changements. Deux demandes peuvent être appliquées successivement tout en poursuivant des objectifs incompatibles. Affectez donc un responsable au périmètre et faites relire les changements de ressources partagées, même lorsque l’outil n’annonce aucun conflit technique.
Traiter l’état comme un fichier sensible
HashiCorp précise que les valeurs sensibles peuvent être conservées dans l’état et les plans. Marquer une variable sensitive limite son affichage dans certaines sorties ; ce marquage ne suffit pas à retirer sa valeur de l’état. Les fonctionnalités qui omettent certaines données ont leurs propres conditions de version et d’utilisation.
Examinez donc les accès au stockage et aux artefacts du pipeline ensemble. Une personne qui ne peut pas télécharger l’état peut encore recevoir un fichier de plan par un autre canal. Prévoyez des droits adaptés aux tâches, une durée de conservation des artefacts et la révocation des accès à la fin d’une mission.
Pour la revue, utilisez un compte d’équipe nominatif lorsque c’est possible. Pour l’exécution automatisée, documentez l’identité technique et son propriétaire. Évitez de dépendre d’un jeton conservé dans le compte personnel d’un intervenant qui pourrait quitter le projet.
Séparer les périmètres selon les responsabilités
Une PME peut commencer avec des états distincts pour ses environnements de test et de production. Ce découpage doit correspondre aux droits et au rythme des changements. Multiplier les états sans raison crée ensuite un travail de coordination entre leurs dépendances.
Posez quelques questions avant de séparer davantage : qui peut modifier ce groupe de ressources ? Peut-il évoluer sans les autres ? Comment les valeurs dont il dépend sont-elles transmises ? Qui intervient si un changement casse un service partagé ?
Pour un réseau utilisé par plusieurs applications, préparez une demande dédiée avec une liste des services concernés. Pour une ressource propre à une application, faites participer son responsable à la revue. Le dossier de transfert d’un logiciel doit reprendre ces responsabilités si un nouveau prestataire prend la maintenance.
Relire un changement avant son application
La revue doit mentionner l’environnement ciblé, les ressources ajoutées ou supprimées et la raison des remplacements. Les changements inattendus restent à expliquer, même s’ils concernent une ressource jugée secondaire. Vérifiez aussi que le code relu correspond à la version qui sera exécutée.
Si un collègue applique un autre changement après la revue, réexaminez le plan selon votre procédure. Notez l’état de la demande dans un seul endroit partagé pour éviter qu’une validation ancienne soit interprétée comme un accord permanent.
L’état Terraform ne remplace pas une sauvegarde des données applicatives. Pour une base de données, prévoyez la récupération des données et la vérification métier dans un exercice distinct. Notre guide de test de restauration propose ce déroulement.
Préparer le premier incident
Avant la première modification de production, désignez la personne qui peut suspendre les exécutions et celle qui peut consulter l’historique du stockage. Testez leurs accès dans les conditions prévues, sans dépendre du poste du développeur initial.
Rédigez enfin une fiche courte pour une exécution interrompue : vérifier le processus encore actif, recueillir les sorties disponibles, comparer les ressources concernées et décider de la reprise. Gardez toute intervention manuelle sur l’état dans une procédure distincte, relue par une personne qui connaît ce périmètre. Le compte rendu doit permettre au prochain opérateur de comprendre exactement ce qui a changé.