Skip to main content

Gérer plusieurs environnements Terraform

Écrit par
Headshot of Stephane Jourdan

Stephane Jourdan

feature synk iac terraform blue

30 juin 2020

0 minutes de lecture

Note de la rédaction : Ce billet a d’abord été publié sur CloudSkiff.com. CloudSkiff a rejoint Snyk en octobre 2021.

Comment gérer la complexité liée à plusieurs environnements Terraform ? Avec plusieurs environnements et potentiellement plusieurs équipes, les choses peuvent se compliquer. Je vous explique ici comment vous lancer dans la gestion de plusieurs environnements Terraform comme un pro.

Bien démarrer avec les fichiers TF

Si vous devez gérer plusieurs environnements Terraform, plusieurs approches s’offrent à vous pour vous lancer et faire évoluer votre méthode.

Se lancer pas à pas avec des fichiers .tf individuels : au début, il peut être difficile de connaître les bonnes pratiques, et vous risquez au mieux de vous disperser, au pire de vous décourager. Vous pouvez donc commencer très simplement avec un seul TFState. Créez un fichier Terraform simple, appelez-le production.tf, puis ajoutez-y vos VPC, vos VM ou tout autre élément. Très vite, vous pourrez créer un autre environnement, que nous appellerons staging.tf. Vous aurez toujours un seul fichier d’état TF, ce qui n’est pas un problème en soi, mais cette approche ne sera pas évolutive. C’est toutefois une façon d’avancer progressivement.

Utiliser les espaces de travail Terraform

HashiCorp recommande d’utiliser ce qu’on appelle désormais les espaces de travail. workspaces est une sous-commande Terraform. Elle s’appelait auparavant environments.

Les espaces de travail permettent de séparer le fichier d’état TF de chaque environnement. Par exemple, si vous avez des environnements QA, de staging et de production, la sous-commande d’espace de travail Terraform vous permet de basculer d’un TFState à l’autre. C’est la méthode recommandée par HashiCorp, mais cela ne signifie pas que vous devez impérativement procéder ainsi.

Organiser les dossiers dans votre dépôt Git

Une autre méthode consiste à séparer vos fichiers d’état non pas avec des espaces de travail, mais à l’aide de dossiers. Il suffit de créer des dossiers dans votre dépôt Git, de leur donner un nom comme staging ou production, puis de générer des fichiers TFState distincts dans chacun. C’est très simple : vos environnements sont déjà séparés au niveau des TFState.

Les modules : une méthode courante pour gérer les environnements Terraform

L’utilisation de modules devient peu à peu la norme. C’est une approche un peu avancée, mais les modules fonctionnent essentiellement en recevant des variables, comme des chaînes de caractères. C’est une fonctionnalité très pratique de Terraform.

Les modules contiennent du code générique. Prenons un VPC standard comme exemple. Ce VPC peut recevoir plusieurs valeurs, comme le sous-réseau et un nom. Vous pouvez créer deux dossiers, un pour chaque environnement. Votre premier fichier Terraform définira l’espace d’adressage de votre VPC de staging, tandis que l’autre en définira un différent. Vous résolvez ainsi le problème en injectant simplement des valeurs différentes dans les modules.

C’est la principale méthode que je recommande pour utiliser les environnements.

Commencez simplement, de façon native, avec un seul TFState. Créez différents dossiers, séparez les états par dossier et utilisez des modules pour y injecter différents types de valeurs. Vous pouvez aussi vous en tenir aux recommandations de HashiCorp, comme l’utilisation des espaces de travail.

Organiser vos ressources et définir la structure de vos répertoires

Dernier point à prendre en compte : l’organisation de vos ressources et la structure de vos répertoires. Allez-vous utiliser un ou plusieurs dépôts ?

Il n’y a pas de réponse unique, mais une configuration courante consiste à gérer les modules séparément et à les appeler depuis un dépôt unique. Prenons un exemple : si vous avez un module capable de configurer correctement un VPC à partir de deux variables, vous disposez d’un code Terraform bien structuré. Vous pouvez stocker ce code dans un dépôt Git Terraform distinct, le gérer, le versionner et le publier comme n’importe quel autre projet. Mais il ne peut pas être utilisé « tel quel ». Vous avez toujours besoin de votre dépôt d’infrastructure pour appeler ce module, un peu comme vous utiliseriez une bibliothèque standard en ingénierie.

Pour certaines personnes, la hiérarchie des dossiers compte également. Il est très courant de trouver des dossiers de test, des dossiers distincts pour les modules et d’autres dossiers pour les environnements.

Autre modèle courant : utiliser des fichiers de variables contenant les différents types de valeurs possibles, afin de transmettre les environnements à l’exécution à l’aide de ces variables d’environnement.

Sécuriser votre code Terraform

Snyk IaC sécurise vos configurations Terraform (ainsi que vos modèles Kubernetes, CloudFormation et ARM !) au fur et à mesure que vous codez, et vous propose des correctifs guidés pour vous permettre de fusionner vos modifications et de poursuivre votre travail. Testez votre code au fil de son écriture, surveillez les changements dans vos dépôts Git et automatisez les tests dans vos pipelines de build avant le déploiement. La mise en route avec une offre gratuite ne prend que quelques minutes, alors qu’une faille causée par une mauvaise configuration IaC peut avoir des conséquences durables. Inscrivez-vous et commencez à sécuriser vos configurations ci-dessous.

Sécurisez votre infrastructure dès la source

Snyk automatise la sécurité et la conformité de l’IaC dans vos workflows, et détecte les ressources dont la configuration a dérivé ou qui sont manquantes.