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.
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.