4 conseils pour gérer plusieurs versions de Terraform

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

Il existe de nombreuses raisons pour lesquelles vous pouvez avoir besoin d’utiliser plusieurs versions de Terraform en local : environnements différents (déploiements structurés) utilisant des versions distinctes, projets multiples pour différents clients, vérification de la rétrocompatibilité de votre code en l’exécutant avec plusieurs versions, etc. Voici quelques conseils très simples pour garder plusieurs versions de Terraform bien organisées.

Commencez par utiliser un gestionnaire d’environnements et de versions de Terraform en local

Un gestionnaire de versions facilite considérablement l’utilisation de plusieurs versions de Terraform en local et vous permet de vous assurer que :

• Vous passez rapidement d’un projet à l’autre

• Votre environnement de développement est aussi proche que possible de la production.

tfenv est un bon outil, inspiré de rbenv. En résumé, tfenv vous permet d’installer une version spécifique de Terraform et de la définir comme version par défaut. Il vous permet également de répertorier et de suivre toutes les versions de Terraform installées sur votre ordinateur. Il propose aussi plusieurs commandes pratiques, comme tfenv install min-required, qui parcourt récursivement vos fichiers Terraform pour déterminer la version minimale requise.

Définissez explicitement vos versions de Terraform

Les mises à niveau de Terraform peuvent poser problème. Et encore plus lorsqu’une erreur inattendue survient sans que vous la compreniez, avant que vous découvriez qu’elle est due à l’utilisation d’une mauvaise version de Terraform sur cette machine.

En définissant explicitement la version requise de Terraform, vous obtiendrez une erreur claire si vous tentez d’exécuter un apply dans le mauvais environnement.

1terraform {
2required_version = "0.12.10"
3}

Définissez aussi les versions des modules

Les éléments mobiles sont parmi les pires ennemis des programmeurs, et cela vaut aussi pour l’Infrastructure as Code. Les modules Terraform favorisent la réutilisation et la composition, mais ils peuvent aussi devenir difficiles à gérer.

Définir les versions des modules permet de mieux contrôler les changements apportés à votre infrastructure lors de la mise à niveau d’un module. Ainsi, pour un commit donné dans votre base de code, vous avez la garantie de toujours déployer la même chose.

1module “blabla” {
2source = “module_name”
3version = “1.2.3”
4}

Cela permet également de déployer progressivement les mises à niveau des modules : vous pouvez conserver l’ancienne version en production, créer une branche de développement pour mettre à niveau le module, effectuer des tests dans votre environnement de développement, puis fusionner dans la branche principale si les tests sont concluants.

Plus vous utilisez de modules, plus le risque que l’un d’eux provoque un problème augmente. Cette précaution devient donc de plus en plus essentielle à mesure que votre base de code s’agrandit.

Évitez les apply en local et les commits directs dans la branche principale

N’oubliez pas votre workflow ! Exécuter apply en local peut être dangereux dès que deux personnes travaillent sur le même fichier Terraform : si deux mises à jour sont effectuées à peu d’intervalle, la première peut être écrasée par la seconde. De plus, vous ne savez jamais ce qui peut arriver sur votre ordinateur, et nous avons entendu parler de fichiers d’état volumineux endommagés à la suite d’une coupure Wi-Fi.

C’est pourquoi un workflow mieux adapté à la production recommande d’exécuter apply uniquement depuis un système centralisé et versionné, par exemple via une CI/CD.

L’étape suivante consiste toutefois à intégrer ce comportement au processus. Par exemple, les droits d’accès d’un utilisateur ne lui permettront pas d’apporter directement des modifications en production. Seules les clés de la CI/CD disposeront des droits nécessaires.

De même, il est très tentant de fusionner directement dans la branche principale, même si nous savons que ce n’est pas une bonne pratique. Protéger la branche principale incitera les utilisateurs à suivre un processus plus sûr : créer une pull request, puis la faire réviser. À moins d’être surhumain, de toujours lire le plan Terraform et de ne jamais faire d’erreur.

Certaines équipes ajoutent des étapes supplémentaires, comme l’analyse statique ou la vérification des mises à jour de la documentation. Un petit investissement qui contribue à garder un code propre sur le long terme.

Sécurisez votre code Terraform

Snyk IaC sécurise vos configurations Terraform (ainsi que vos modèles Kubernetes, CloudFormation et ARM !) pendant que vous codez, et vous propose des correctifs guidés pour vous permettre de fusionner vos modifications et de passer à la suite. Testez votre code au fur et à mesure, surveillez les changements dans vos dépôts Git et automatisez les tests dans vos pipelines de build avant le déploiement. Quelques minutes suffisent pour commencer avec un forfait gratuit, tandis qu’une faille due à une mauvaise configuration IaC peut avoir des conséquences durables. Inscrivez-vous et commencez à sécuriser vos configurations ci-dessous.