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.

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.

Quels sont les outils que je devrais connaître et envisager d'utiliser?

Quelles sont les solutions à l'enfer des dépendances avec les modules ?

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.

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.

Documentation

Documentation génèrée automatiquement

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

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

Resources

1. pre-commit framework homepage

2. Collection of git hooks for Terraform to be used with pre-commit framework

3. Blog posté par Dean Wilson: pre-commit hooks and terraform - a safety net for your repositories

Conventions générales

1. Utilisez _ (surligné) au lieu de - (tiret) partout (noms des ressources, noms des sources de données, noms des variables, sorties, etc.).

2. Préférez les lettres minuscules et les chiffres (même si UTF-8 est pris en charge).

Arguments de ressource et de source de données

1. Ne répétez pas le type de ressource dans le nom de la ressource (ni partiellement, ni complètement) :

`resource "aws_route_table" "public" {}`

`resource "aws_route_table" "public_route_table" {}`

`resource "aws_route_table" "public_aws_route_table" {}`

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