Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
Cet exemple contient du code comme exemple de structuration des configurations Terraform pour une infrastructure de petite taille, où aucune dépendance externe n'est utilisée.
Parfait pour commencer et refactoriser au fur et à mesure
Parfait pour les petits modules de ressources
Bon pour les petits modules d'infrastructure linéaires (par exemple, terraform-aws-atlantis)
Bon pour un petit nombre de ressources (moins de 20-30)
Un fichier d'état unique pour toutes les ressources peut ralentir le processus de travail avec Terraform si le nombre de ressources augmente (envisagez d'utiliser un argument -target pour limiter le nombre de ressources)
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
Cet exemple contient du code comme exemple de structuration des configurations Terraform pour une infrastructure de taille moyenne qui utilise :
2 comptes AWS
2 environnements séparés (prod
et stage
qui ne partagent rien). Chaque environnement réside dans un compte AWS distinct
Chaque environnement utilise une version différente du module d'infrastructure standard (alb) provenant de Terraform Registry
Chaque environnement utilise la même version d'un module interne modules/network
puisqu'il provient d'un répertoire local.
Parfait pour les projets où l'infrastructure est logiquement séparée (comptes AWS séparés)
Bon lorsqu'il n'est pas nécessaire de modifier les ressources partagées entre les comptes AWS (un environnement = un compte AWS = un fichier d'état)
Bon quand il n'y a pas besoin d'orchestration des changements entre les environnements
Bon lorsque les ressources d'infrastructure sont différentes par environnement à dessein et ne peuvent pas être généralisées (par exemple, certaines ressources sont absentes dans un environnement ou dans certaines régions)
Au fur et à mesure que le projet grandit, il sera plus difficile de maintenir ces environnements à jour les uns avec les autres. Il faudrait envisagez d'utiliser des modules d'infrastructure (prêts à l'emploi ou internes) pour les tâches répétables.
FTP (Frequent Terraform Problems)
Les versions des modules de ressources et d'infrastructure doivent être spécifiées. Les fournisseurs doivent être configurés en dehors des modules, mais uniquement en composition. La version des fournisseurs et de Terraform peut également être verrouillée.
Il existe également un atelier pour les personnes qui souhaitent mettre en pratique certaines des choses décrites dans ce guide.
- Outil d'orchestration
- Code linter
- Gestionnaire de versions
- Automation des demandes d'extraction (Pull Request)
- Collection de git hooks pour Terraform à utiliser avec
- Estimation des coûts du cloud pour Terraform dans les demandes de pull. Fonctionne aussi avec Terragrunt, Atlantis et pre-commit-terraform
Il n'y a pas d'outil maître de gestion des dépendances, mais il existe quelques astuces pour rendre l'enfer des dépendances moins problématique. Par exemple, peut être utilisé pour automatiser les mises à jour des dépendances. Dependabot crée des demandes d'extraction pour garder vos dépendances sécurisées et à jour. Dependabot prend en charge les configurations Terraform.
Le contenu est ici -
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
Cet exemple contient du code comme exemple de structuration des configurations Terraform pour une infrastructure de grande taille qui utilise :
2 comptes AWS
2 régions
2 environnements séparés (prod
et stage
qui ne partagent rien). Chaque environnement réside dans un compte AWS distinct et répartit les ressources entre 2 régions
Chaque environnement utilise une version différente du module d'infrastructure standard (alb
) provenant de Terraform Registry
Chaque environnement utilise la même version d'un module interne modules/network
puisqu'il provient d'un répertoire local.
Dans un grand projet comme décrit ici, les avantages de l'utilisation de Terragrunt deviennent très visibles. Voir Code Structures examples with Terragrunt.
Parfait pour les projets où l'infrastructure est logiquement séparée (comptes AWS séparés)
Bon lorsqu'il n'est pas nécessaire de modifier les ressources partagées entre les comptes AWS (un environnement = un compte AWS = un fichier d'état)
Bon quand il n'y a pas besoin d'orchestration des changements entre les environnements
Bon lorsque les ressources d'infrastructure sont différentes par environnement à dessein et ne peuvent pas être généralisées (par exemple, certaines ressources sont absentes dans un environnement ou dans certaines régions)
Au fur et à mesure que le projet grandit, il sera plus difficile de maintenir ces environnements à jour les uns avec les autres. Il faudrait envisagez d'utiliser des modules d'infrastructure (prêts à l'emploi ou internes) pour les tâches répétables.
Les exemples et les modules Terraform doivent contenir une documentation expliquant les fonctionnalités et comment les utiliser.
Tous les liens dans les fichiers README.md doivent être absolus pour que le site Web Terraform Registry les affiche correctement.
La documentation peut inclure des diagrammes créés avec mermaid et des plans créés avec cloudcraft.co.
Utilisez Terraform pre-commit hooks pour vous assurer que le code est valide, correctement formaté et automatiquement documenté avant qu'il ne soit transmis à git et examiné par des humains
pre-commit est un cadre de gestion et de maintenance des hooks de pré-commit multilingues. Écrit en Python, il est un outil puissant pour faire quelque chose automatiquement sur la machine d'un développeur avant que le code ne soit validé dans un référentiel git. Normalement, il est utilisé pour exécuter des linters et formater du code (voir supported hooks).
Avec les configurations Terraform pre-commit
peut être utilisé pour formater et valider le code, ainsi que pour mettre à jour la documentation.
Vérifiez le pre-commit-terraform repository pour vous familiariser avec lui, et les référentiels existants (par exemple, terraform-aws-vpc) où cela est déjà utilisé.
terraform-docs est un outil qui génère la documentation des modules Terraform dans différents formats de sortie. Vous pouvez l'exécuter manuellement (sans crochets de pré-commit), ou utiliser pre-commit-terraform hooks pour obtenir la documentation mise à jour automatiquement.
@ToDo: Document module versions, release, GH actions
Il ne devrait y avoir aucune raison de ne pas suivre au moins ces conventions :)
Prenez notes que les ressources réelles dans le cloud ont souvent des restrictions dans les noms autorisés. Certaines ressources, par exemple, ne peuvent pas contenir de tirets, certaines doivent être en camel-case. Les conventions de ce livre font référence aux noms Terraform eux-mêmes.
Utilisez _
(surligné) au lieu de -
(tiret) partout (noms des ressources, noms des sources de données, noms des variables, sorties, etc.).
Préférez les lettres minuscules et les chiffres (même si UTF-8 est pris en charge).
Ne répétez pas le type de ressource dans le nom de la ressource (ni partiellement, ni complètement) :
Le nom de la ressource doit être ainsi donné s'il n'y a plus de nom descriptif et général disponible, ou si le module de ressources crée une seule ressource de ce type (par exemple, dans AWS VPC module il y a une seule ressource de type aws_nat_gateway
et plusieurs ressources de typeaws_route_table
, donc aws_nat_gateway
pourrait être nommé this
etaws_route_table
devrait avoir des noms plus descriptifs - comme private
, public
, database
).