Lorsque l'on travaille avec un logiciel de provisionnement aussi avancé que Terraform, il est facile de se sentir dépassé. Quelles sont les meilleures pratiques à suivre ? Quelles sont les erreurs à éviter ? C'est pourquoi l'équipe d'experts d'Iguane Solutions a compilé le Top 3 des choses à faire et à ne pas faire avec Terraform pour aider les organisations à adopter ce formidable outil open-source Infrastructure As Code créé par HashiCorp.
Terraform: Les 3 meilleures pratiques
Commençons par les principes de base, à savoir les trois meilleures pratiques que vous devez toujours suivre lorsque vous travaillez avec Terraform.
1. Lire la documentation de Terraform
La lecture de la documentation est de loin la meilleure pratique la plus sous-estimée lorsque l'on travaille avec Terraform. L'un des aspects qui différencie Terraform des autres projets est l'incroyable travail réalisé par HashiCorp sur la documentation officielle. Chez Iguane Solutions, nous n'hésitons pas à considérer la documentation de Terraform comme l'une des sources de connaissances et de ressources les plus précieuses que vous puissiez trouver en ligne.
Que vous ayez des questions concernant la syntaxe HCL, la configuration de Terraform , l'API, l'intégration VCS ou les espaces de travail de Terraform , la documentation officielle devrait être votre point de départ. Cela vous épargne de nombreuses heures de recherche et peut même vous éviter de commettre des erreurs en utilisant des configurations ou des astuces qui ne sont plus valables dans les versions les plus récentes de Terraform.
En d'autres termes, en lisant la documentation officielle de Terraform , vous bénéficiez des avantages suivants :
- Utiliser les ressources les plus récentes
- Éviter d'utiliser des "meilleures pratiques" qui ne sont plus recommandées
- Éviter de commettre des erreurs ou d'introduire des divergences lors de l'utilisation d'un code qui n'est plus valide
- Améliorer la sécurité de votre code
2. Concevoir des modules "génériques".
C'est presque une constante dans tous les langages de programmation que de promouvoir l'utilisation de "code réutilisable". Après tout, n'est-ce pas là l'un des avantages de l'utilisation d'un langage de programmation structuré ?
Aussi évident que cela puisse paraître, de nombreux développeurs tombent dans le piège de ne pas concevoir des modules génériques ; au lieu de cela, ils créent des modules pour répondre à des besoins individuels dans un environnement. Ce qui se passe généralement dans ces cas-là, c'est qu'au fur et à mesure que l'infrastructure de l'organisation grandit (et donc le nombre d'exigences et d'environnements), vous devrez réécrire une bonne partie du code. Pire encore, le code devient 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 : il faut s'assurer que les modules sont aussi génériques que possible. Vous pouvez déterminer si un module est générique en examinant ses caractéristiques. En général, les modules génériques partagent les caractéristiques suivantes :
- Ils sont réutilisables, d'où leur nom de "génériques".
- Ils effectuent généralement un seul travail.
- Ils sont bien documentés et peuvent donc être facilement modifiés.
Pour illustrer ce concept, considérons un module responsable de l'importation d'un fichier de clé publique SSH dans AWS. Il s'agirait d'un module réutilisable puisqu'il peut être utilisé dans n'importe quel environnement (développement, production, staging, etc.). En outre, il ne fait qu'une seule tâche (importer un fichier de clé publique SSH dans AWS) et il serait donc très facile de le documenter correctement.
3. Tout automatiser
L'automatisation des processus est l'un des principes fondamentaux de DevOps. En fait, dans l'un de nos articles précédents, 4 façons dont Terraform peut améliorer l'adoption de DevOpsnous avons déjà mentionné comment Terraform vous permet d'automatiser le provisionnement de l'infrastructure. À cette occasion, nous allons renforcer ce concept en faisant écho à la documentation officielle "Terraform Pratiques recommandéesoù ce processus est discuté en profondeur.
Ce n'est pas un hasard si l'automatisation est un concept si important qu'il est considéré comme une meilleure pratique. 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 des erreurs humaines liées à l'exécution manuelle de tous ces processus complexes.
Pour aller plus loin, il est important de considérer l'IaC comme n'importe quel autre processus de développement et vous devriez inclure l'IaC dans vos pipelines CI/CD habituels. C'est la clé d'un déploiement sécurisé de l'infrastructure. Les pipelines CI/CD facilitent le travail collaboratif entre les différentes équipes. Ils fournissent des outils permettant d'établir des règles de bonnes pratiques pour la vérification du code et l'examen par les pairs. Et le plus important, c'est la garantie de travailler sur la même version de l'IaC stack 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 en production.
Les principes de DevOps nous indiquent qu'une infrastructure moderne doit être évolutive et ne doit pas dépendre de processus manuels. En d'autres termes, si vous utilisez Terraform, vous devez en tirer le meilleur parti en automatisant tous vos approvisionnements. Chez Iguane Solutions, nous savons que ce n'est pas facile. Pourtant, c'est la seule façon de suivre les directives DevOps et les pratiques fondamentales qui rendent l'Infrastructure As Code (IaC) si utile.
Si vous souhaitez passer d'un provisionnement manuel à un processus semi-automatique ou d'une procédure semi-automatique à une procédure conforme aux principes de l'IaC, Iguane Solutions se fera un plaisir de vous aider.
Terraform: Les 3 principales erreurs à éviter
Les erreurs à éviter sont tout aussi importantes que les meilleures pratiques. Dans cette section, nous allons discuter des erreurs les plus courantes chez les développeurs.
1. Stocker les secrets en clair
On peut affirmer que, l'une des erreurs les plus courantes lors de l'utilisation de Terraform est de stocker des informations sensibles en texte brut. Cette erreur est fréquente tant chez les débutants que chez les développeurs expérimentés. La raison ? Ils oublient que toute personne ayant accès au référentiel peut obtenir ces secrets.
Heureusement, la correction de cette faille de sécurité est relativement simple.
- Exclure tous les fichiers susceptibles de contenir des données sensibles (.tfstate, crash.log, * override.tf *, .terraformrc, terraform.rc). Github propose un fichier .gitignore qui peut s'avérer très utile à cet égard
- Cryptez tous les secrets que vous stockez dans votre système de contrôle de version. Pour ce faire, vous pouvez utiliser des 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. de se pencher sur les outils de gestion des secrets pour le cryptage Git.
- Une autre solution valable consiste à l'utilisation d'un gestionnaire de secret externe. Chez Iguane Solutions, nos favoris sont AWS Secrets Manager et Vault développés par HashiCorp, la même société que celle à l'origine de Terraform.
2. Ne pas documenter son code
Comme pour tout autre langage de programmation, la documentation du code est considérée comme une bonne pratique. Pourquoi ? C'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, davantage de nœuds sont ajoutés, et d'autres changements qui, petit à petit, augmentent la complexité des fichiers tfstate de manière exponentielle.
Tenez compte d'un autre aspect important. Dans la plupart des cas, ce n'est pas une personne mais plusieurs qui ajoutent ou modifient le code. En d'autres termes, différents développeurs, ayant des visions différentes de la manière de résoudre un problème, mettent en œuvre leurs propres solutions sur la base de leur expérience.
Pour chacun de ces développeurs, leur code est logique, mais qu'en est-il des autres ? Étant donné que l'on peut obtenir le même résultat par des voies différentes, il est fréquent 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 est d'établir une politique claire en matière de documentation du code. C'est pourquoi les experts d'Iguane Solutions suggèrent de documenter chaque changement introduit dans le code en utilisant les politiques de votre entreprise. Cette recommandation est valable quel que soit le langage de codage. Que vous préfériez utiliser le HashiCorp Configuration Language (HCL) ou JSON, l'objectif est le même, rendre le code aussi facile à comprendre que possible.
Enfin, la documentation du code facilitera grandement son débogage, ce qui améliorera l'efficacité du cycle de développement.
3. Utilisation d'une mauvaise structure de répertoire ou de référentiel
C'est probablement 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 n'importe quelle méthode d'organisation pour ses fichiers, d'après notre expérience, certaines structures de répertoires et de dépôts peuvent potentiellement causer beaucoup d'inconvénients lors de la mise à l'échelle de votre infrastructure.
Mais qu'est-ce que cela signifie en pratique ? Eh bien, d'après la documentation officielle 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'isolation des dépendances et la modularité.
En fait, la documentation de Terraform propose une solution simple : "... Si votre organisation n'a pas de préférence marquée, nous recommandons d'utiliser des référentiels distincts pour chaque configuration et d'utiliser le registre de modules privé pour partager les modules. Cela permet un développement plus rapide des modules 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 au fur et à mesure que votre organisation grandit, nous vous suggérons d'éviter à tout prix d'utiliser l'approche "monorepo" et de préférer de conserver chaque configuration Terraform dans un référentiel distinct.
À Iguane Solutions nous aimons tellement Terraform que notre équipe a développé le fournisseur officiel d'OpenNebula. fournisseur officiel d'OpenNebula qui est maintenant disponible sur le OpenNebula github et listé sur la liste officielle des fournisseurs de liste officielle des fournisseurs de Terraform!
Besoin d'aide ou d'expertise pour votre prochain projet impliquant Terraform? Contactez nous!
