Top 3 des choses à faire et à ne pas faire avec Terraform

Top 3 des choses à faire et à ne pas faire avec Terraform

Lorsque vous travaillez avec un outil d’Infrastructure as Code aussi avancé que Terraform, il est facile d’être dépassé. Quelles sont les meilleures pratiques à suivre ? Quelles erreurs dois-je éviter ? Iguane Solutions a compilé le Top 3 des choses à faire et à ne pas faire avec Terraform pour aider les entreprises à adopter cet incroyable outil open-source créé par HashiCorp.

Terraform : Top 3 des best practices

Logo Terraform

Commençons par les bases, quelles sont les 3 best practices que vous devez toujours suivre lorsque vous travaillez avec Terraform.

1. Lire la documentation Terraform

Cela peut sembler évident, mais en réalité, la lecture de la documentation est de loin la pratique la plus sous-estimée lorsque vous travaillez avec Terraform. L’un des aspects qui différencie Terraform des autres projets est le travail incroyable que HashiCorp a réalisé avec la documentation officielle. Chez Iguane Solutions, nous n’hésitons pas à considérer la documentation Terraform comme l’une des sources de connaissances et de ressources les plus complètes et pertinentes que vous puissiez trouver en ligne.

Que vous ayez des questions concernant la syntaxe HCL, la configuration Terraform, l’API, l’intégration VCS ou les espaces de travail Terraform, la documentation officielle devrait être votre point de départ. Cela vous permet d’économiser de nombreuses heures de recherche et peut même vous éviter de faire des erreurs lors de l’utilisation de configurations ou de conseils qui ne sont plus valides dans les versions les plus récentes de Terraform.

En d’autres termes, en lisant la documentation officielle de Terraform, vous : 

  • Utilisez les dernières ressources,
  • Évitez d’utiliser les «bonnes pratiques» qui ne sont plus recommandées,
  • Évitez de faire des erreurs ou d’introduire des régressions lors de l’utilisation de code qui n’est plus valide,
  • Améliorez la sécurité de votre code.

2. Concevez les modules pour qu’ils soient «génériques»

C’est presque une constante dans tous les langages de programmation de promouvoir l’utilisation du «code réutilisable». Après tout, n’est-ce pas l’un des avantages de l’utilisation d’un langage de programmation structuré en premier lieu  ?

Et bien, aussi évident que cela puisse paraître, de nombreux développeurs tombent dans le piège de ne pas concevoir de modules génériques. Au lieu de cela, ils créent des modules pour répondre aux exigences individuelles d’un environnement. Ce qui se passe généralement dans ces cas, c’est qu’à mesure que l’infrastructure de l’organisation se développe (et donc le nombre d’exigences et d’environnements), vous devrez réécrire une bonne partie du code. Pire encore, le code deviendra plus compliqué qu’il ne devrait l’être en raison des innombrables versions et modifications apportées à chaque module.

Vous vous demandez peut-être comment éviter cette situation  ? La réponse est simple, en s’assurant que les modules soient aussi génériques que possible. Vous pouvez dire si un module est générique en regardant ses caractéristiques. Généralement, les modules génériques partagent les fonctionnalités suivantes :

  • Ils sont réutilisables, par conséquent, ils sont appelés «génériques»,
  • Ils ne remplissent généralement qu’une seule fonction,
  • Ils sont bien documentés afin de pouvoir être facilement modifiés.

Pour illustrer ce concept, envisagez un module chargé d’importer un fichier de clé publique SSH dans AWS. Ce serait un module réutilisable car il peut être utilisé dans n’importe quel environnement (développement, production, mise en scène, etc.). En plus de cela, il ne réalise qu’une seule tâche (importer un fichier de clé publique SSH dans AWS), il serait donc très facile de le documenter correctement.

 

3. Tout automatiser

L’automatisation des processus est l’un des principes fondamentaux du DevOps. D’ailleurs, dans l’un de nos articles précédents intitulé Comment Terraform améliore l’adoption du DevOps?, nous avons déjà mentionné comment Terraform vous permet d’automatiser votre processus de gestion d’infrastructure. A cette occasion, nous renforçons ce concept en faisant écho à la documentation officielle «Terraform Recommended Practices», où ce processus est abordé en profondeur.

Ce n’est pas un hasard si l’automatisation est un concept si important qu’il doit être considéré comme une best practice. L’utilisation de la ligne de commande ou de scripts personnalisés pour modifier votre infrastructure n’est pas une solution viable à long terme. Les résultats ne sont pas toujours reproductibles, sans parler de l’erreur humaine dans l’exécution manuelle de tous ces processus complexes.

Pour aller plus loin, il est important de considérer l’IaC comme tout autre processus de développement et vous devriez inclure l’IaC dans vos pipelines de CI / CD habituelles. C’est la clé pour sécuriser le déploiement de l’infrastructure. Les pipelines de CI / CD facilitent le travail collaboratif entre vos différentes équipes. Elles fournissent les outils pour automatiser et forcer la vérification du code avant son déploiement ainsi que sa révision par des pairs. 

Enfin, le recours aux pipelines de CI / CD c’est aussi la garantie pour chacun de travailler sur la même version de la pile d’IaC et de partager l’état actuel de vos déploiements. Il vous permet de définir plusieurs environnements pour valider votre travail avant de passer à la production.

Les principes du DevOps nous disent que l’infrastructure moderne doit être évolutive et ne doit pas dépendre de processus manuels. En d’autres termes, si vous comptez utiliser Terraform, vous devez en tirer le meilleur parti en automatisant tous vos approvisionnements. Même si la tâche n’est pas toujours facile, pourtant, c’est le seul moyen de suivre les directives du DevOps et les pratiques fondamentales qui rendent l’Infrastructure as Code si utile.

Si vous souhaitez automatiser votre processus de gestion d’infrastructure ou que vous désirez un accompagnement pour implémenter les bonnes pratiques relatives à l’Infrastructure As Code au sein de votre organisation, Iguane Solutions sera ravie de mettre son expertise à contribution pour vous accompagner.

Terraform : Top 3 des erreurs à éviter

 

A ne pas faire avec Terraform

 

Les erreurs à éviter sont tout aussi importantes que les best practices à appliquer. Dans cette section, nous allons discuter des erreurs les plus courantes commises lors de l’utilisation de Terraform.

1. Stocker les secrets en clair

L’une des erreurs les plus courantes lors de l’utilisation de Terraform est sans doute le stockage d’informations sensibles en texte brut. Cette erreur est commise aussi bien par les développeurs débutants que par les ingénieurs les plus aguerris. La raison ? Ils oublient que toute personne ayant accès au dépôt de code peut obtenir ces secrets.

Heureusement, corriger cette faille de sécurité est relativement simple.

  • Exclure tous les fichiers susceptibles de stocker des données sensibles (.tfstate, crash.log, * override.tf *, .terraformrc, terraform.rc). Github propose une fonctionnalité via la ressource .gitignore qui peut être très utile à cet égard.
  • Chiffrer tous les secrets que vous stockez dans votre système de contrôle de version. Cela peut être accompli à l’aide d’outils tels que Git-crypt, BlackBox, SOPS ou Transcrypt. En fonction de votre environnement de développement, certains d’entre eux peuvent être mieux adaptés que d’autres, nous vous recommandons donc de vous plonger dans les outils de gestion des secrets pour le chiffrement Git.
  • Une autre alternative valable consiste à utiliser un gestionnaire de secrets externe. Chez Iguane Solutions, notre solution favorite reste Vault, développé par HashiCorp, la même société qui édite Terraform.

2. Ne pas documenter votre code

Comme pour tout autre langage de programmation, la documentation du code est considérée comme une best practice. Pourquoi ? La raison est simple. Au fur et à mesure que l’infrastructure se développe, de nouvelles configurations sont introduites dans les composants existants, de nouveaux services sont ajoutés, plus de nœuds sont ajoutés et d’autres changements qui, petit à petit, augmentent la complexité des fichiers tfstate de manière exponentielle.

Prenez en compte un autre aspect important. Dans la plupart des cas, ce n’est pas une personne unique mais plusieurs qui ajoutent ou modifient le code. En d’autres termes, différents développeurs, avec des visions différentes de la façon de résoudre un problème, implémentent leurs propres solutions en fonction de leur expérience.

Pour chacun de ces développeurs, leur code a du sens, mais qu’en est-il des autres ? Étant donné que vous pouvez obtenir le même résultat en utilisant des chemins différents, il est courant que deux personnes soient en désaccord ou ne comprennent tout simplement pas pourquoi une modification particulière est apportée au code.

La solution la plus simple à ce problème consiste à établir une politique claire concernant la documentation du code. Cette recommandation est valable quel que soit le langage de codage. Que vous préfériez utiliser le langage de configuration HashiCorp (HCL) ou JSON, l’objectif est le même: rendre le code aussi facile à comprendre que possible.

Enfin, documenter le code facilitera grandement son déboggage, ce qui améliorera l’efficacité du cycle de développement.

 

3. Utilisation d’une mauvaise structure de répertoire ou de dépôt

C’est peut-être l’un des points les plus controversés car il a beaucoup à voir avec la manière « recommandée » de structurer les fichiers et les configurations de Terraform. Bien que Terraform soit flexible quant à l’utilisation de toute méthode d’organisation pour ses fichiers, selon notre expérience, certaines structures de répertoires et de dépôts peuvent potentiellement causer de nombreux inconvénients lors de la mise à l’échelle de votre infrastructure.

Mais qu’est-ce que cela signifie en pratique ? Eh bien, selon la documentation officielle de Terraform, la meilleure façon d’organiser votre code et la structure de vos dépôts est d’utiliser une organisation qui favorise l’isolement des dépendances et la modularité.

En fait, la documentation Terraform propose une solution simple: « … Si votre organisation n’a pas de préférence forte, nous vous recommandons d’utiliser des répertoires séparés pour chaque configuration et d’utiliser le registre de modules privés pour partager vos modules. Cela permet un développement de modules plus rapide puisque vous n’avez pas à mettre à jour chaque configuration qui consomme un module en même temps que le module lui-même … « 

En d’autres termes, pour éviter des maux de tête inutiles à mesure que votre organisation se développe, notre suggestion est d’éviter à tout prix d’utiliser l’approche «monorepo» et de privilégier à la place le maintien de chaque configuration Terraform dans un dépôt séparé.

 

Chez Iguane Solutions, nous aimons tellement Terraform que notre équipe a développé le provider officiel OpenNebula qui est maintenant disponible sur le github OpenNebula et répertorié sur la liste officielle des providers Terraform!

 

Besoin d’aide ou d’expertise pour votre prochain projet impliquant Terraform ?

Migration vers le Cloud, accompagnement 24/7, Kubernetes, FinOps