Description | Justification | Exemples | Mesurabilité | Tags |
---|---|---|---|---|
Ne jamais écrire des identifiants en clair dans un fichier de configuration de Terraform. [source 1] |
Ne pas s’exposer à des fuites et à du piratage. | Difficile | - Security - Variables - Resources |
|
Utiliser un format consistant dans les différents fichiers de configuration. [source 1] |
Lisibilité et cohérence. Terraform fournit un outil de formatage automatique des fichiers de configuration. |
Difficile | - Lisibility | |
Créer des ressources avec un nom différent pour chaque environnement et chaque ressource. [source 1] |
Définition facile de la ressource avec un nom significatif et unique, et possibilité de construire plus de la même pile d’applications pour différents développeurs sans changer beaucoup. Par exemple, vous mettez à jour l’environnement pour dev, staging, uat, prod, etc. | Difficile | - Conventions | |
Mettre en place un verrou sur l’état Terraform à l’aide d’un backend Terraform. [source 1] [source 2] |
Si plusieurs développeurs travaillent sur un même projet, il est possible que plusieurs membres décident d’exécuter la configuration Terraform en même temps. Cela peut conduire à la corruption du fichier d’état Terraform ou même à une perte de données. Dans ce cas, il est possible de configurer un verrou sur l’état Terraform à l’aide d’un backend Terraform. Pour un backend configuré avec AWS, la mise à jour de la configuration du backend consiste simplement à indiquer un nouveau nom de table Dynamo DB. | Difficile | - Teamwork | |
Utiliser le bon type de données pour les variables. [source 1] |
L’utilisation de types de données appropriés dans Terraform facilite la validation des entrées et la documentation de l’utilisation. | Difficile | - Variables - Conventions |
|
Ne jamais divulguer de secrets en clair dans les sorties d’une configuration Terraform. [source 1] |
Les secrets ne doivent jamais être des sorties de modules. Ils doivent être écrits dans un stockage sécurisé avec chiffrement. | Difficile | - Security | |
Dans le bloc “required_providers”, il est recommandé de toujours expliciter l’attribut “version”. [source 1] |
Cela permet de contraindre Terraform et de l’empêcher d’installer un fournisseur incompatible avec la configuration. La dernière version sera installée par défaut. | Facile | - Modules | |
Utiliser des fichiers de variables. [source 1] |
Cela permet de facilement gérer les variables d’environnement sans lancer terraform avec une longue liste de paires clé-valeur. | Facile | - Variables - Conventions |
|
Utiliser plusieurs fichiers de configuration .tf [source 1] |
Cela permet de répartir les responsabilités dans des fichiers distincts et de les rendre plus lisibles. | Notre projet de Cloud ! | Facile | - Structure - Lisibility |
Documenter le code. [source 1] [source 2] [source 3] |
Cela permet une meilleure compréhension et maintenabilité. | Commenter les lignes et/ou utiliser un README. | Facile | - Lisibility |
Ne jamais partager le fichier .tfstate sur le repository. [source 1] [source 2] |
Le fichier .tfstate est un fichier généré par Terraform lorsque des commandes qui modifient l’état de l’infrastructure sont exécutées. En effet, Terraform a besoin d’un fichier .tfstate pour connaître l’état de l’infrastructure avant de faire des modifications. Cependant, partager le fichier .tfstate sur le repository présente plusieurs risques. Premièrement, il est possible d’exposer les secrets de la configuration de l’application, tels que des mots de passe, des chaînes de connexion à la base de données, etc. Et deuxièmement, il est possible d’exécuter Terraform sur un état périmé ou ancien que quelqu’un a oublié de retirer du repository. Dans ce cas, il existe une alternative au partage du fichier .tfstate qui consiste à configurer une fonctionnalité appelée “backend” Terraform. | Facile | - Security - Teamwork |
|
Utiliser un fichier .editorconfig pour assurer la cohérence des caractères d’espacement. [source 1] |
La plupart des IDE courants prennent en charge le standard .editorconfig afin de faciliter le respect de la cohérence des caractères d’espacement. La norme EditorConfig permet aux éditeurs de définir un style d’écriture pour chaque type de fichier et de respecter les styles définis. | Facile | - Conventions - Lisibility |
|
Ne jamais modifier le fichier d’état Terraform manuellement. [source 1] |
Le fichier d’état est une représentation de votre infrastructure dans le monde réel. Il arrive parfois que certaines situations vous obligent à modifier cet état. Beaucoup sont tentés, lorsqu’ils doivent déplacer ou renommer un état, de plonger dans le fichier d’état lui-même et de commencer à le bidouiller. Mais attention, il existe un moyen beaucoup plus sûr ! La CLI de Terraform vous offre des commandes qui vous permettent de supprimer ou de déplacer. Celle-ci pourra effectuer un certain nombre de vérifications et effectuera les modifications à tous les endroits nécessaires. | Par exemple, si vous souhaitez renommer un bloc de ressources, vous devrez réassigner votre état Terraform au nouveau nom de la ressource. | Impossible | - Structure - Language |
Nommer les variables entièrement en minuscules séparées par des underscores. [source 1] [source 2] |
Par convention. Certaines ressources cloud peuvent avoir des contraintes de nommage. |
“ma_variable”, “une_ressource” | Moyen | - Variables - Convention |
Utiliser les modules officiels de Terraform autant que possible et les modifier si besoin. [source 1] [source 2] [source 3] |
Cela permet d’alléger la configuration en utilisant des ressources fonctionnelles et bien conçues tout en évitant de réinventer la roue. | Moyen | - Modules | |
Isoler les ressources indépendantes dans différentes compositions. [source 1] |
Les ressources doivent être isolées par dépendance, c.a.d celles n’étant pas liées entre elles (non interdépendantes) ne doivent pas être placées dans une même composition. Permet d’isoler plus efficacement l’infrastructure et d’éviter qu’une erreur/panne se propage. |
Moyen | - Resources - Structure - Modules |
|
Construire des modules de ressources atomiques. [source 1] |
Un module de ressource va englober des ressources et des données, donc afin d’éviter les effets de bord indésirables, les modules doivent être le plus atomique possible, donc avec le moins de dépendance. Cela permet ainsi de garantir une composition atomique et rejoint le point précédent concernant l’isolation des ressources. | Moyen | - Modules - Structure |
|
Spécifier explicitement les dépendances entre les ressources. [source 1] |
Via le mot clé ‘locals’ on spécifie explicitement à Terraform une relation de dépendance entre ressources, dans le cas où Terraform n’aurait pas automatiquement reconnu cette dépendance. Cela permet notamment de définir un ordre dans les dépendances pour, par exemple, expliciter la dépendance d’une base de données avec un service, afin d’être garantie que Terraform déploie en priorité la base de données. Ainsi, le service est certain de pouvoir y accéder. | Moyen | - Variables | |
Maintenir régulièrement la configuration de Terraform à jour. [source 1] [source 2] |
La communauté de développement Terraform est très active et la publication de nouvelles fonctionnalités est fréquente. Ainsi, il devient difficile de mettre à jour Terraform si plusieurs versions majeures ont été ignorées. Pour cette raison, il est recommandé de maintenir régulièrement la configuration de Terraform à jour. De plus, cela permet de bénéficier des derniers correctifs de sécurité. | Moyen | - Security | |
Sauvegarder l’état de l’infrastructure sur un backend Terraform. [source 1] [source 2] |
La plupart du temps, plusieurs développeurs travaillent sur un projet. Pour leur donner accès au fichier d’état Terraform de manière sécurisée, celui-ci doit être stocké dans un emplacement centralisé et distant. Dans ce cas, il est possible de configurer un backend Terraform qui fera office de source unique de vérité sur l’état Terraform de votre infrastructure. En plus de permettre le partage sécurisé de l’état de l’infrastructure, un backend Terraform permet de faciliter le versionnement de l’état (pour revenir rapidement à un état connu en cas de problème) et de mettre en place un verrou sur l’état (pour éviter que plusieurs développeurs déploient des modifications au même temps). | Moyen | - Teamwork | |
Utiliser les fonctions d’interpolation mathématique du CIDR pour les calculs de réseau. [source 1] |
Cela réduit le temps nécessaire à la prise en main du projet pour que de nouveaux développeurs puissent contribuer plus rapidement. De plus, cela réduit la probabilité d’une erreur humaine dans les calculs réseau qui peuvent être complexes. | Moyen | - Optimization - Lisibility |
|
Utiliser les fins de ligne de Unix plutôt que celles de Windows. [source 1] |
Par convention. | Facile | - Convention | |
Exécuter la configuration de Terraform à l’aide d’une chaîne de déploiement continu. [source 1] |
L’exécution du code à l’aide d’une chaîne de déploiement continu présente de nombreux avantages, notamment un processus reproductible et un historique des modifications. Le concept de builds est également très utile lorsqu’il est appliqué à Terraform, car il permet de mieux voir ce qui a été exécuté sur votre infrastructure à des fins d’audit, de débogage et de collaboration. | Difficile | - Modules |