Créer un code de qualité en Terraform qui ne génère pas de surprise sur la facture et qui est réutilisable pour plusieurs projets peut être challengeant.
Voici un ensemble de règles que nous appliquons chez Keltio lorsque nous codons en Terraform.
Terraform lit tous les fichiers avec des extensions .tf. Vous pouvez avoir autant de fichiers que vous le souhaitez.
Cependant, il est préférable d'avoir une structure propre afin que tout le monde dans l'équipe puisse comprendre et participer au projet.
Voici le format suggéré à suivre :
.tf (Réseau, stockage, compute …)README.md pour avoir une description du projet et des informations telles que les entrées, les sorties. Vous pouvez utiliser des outils comme terraform-docs pour générer ce fichierprovider.tf pour définir les fournisseurs dans votre projetversion.tf pour indiquer à terraform quelles versions de terraform et de fournisseur doivent être utiliséesdocs/ pour mettre la documentation pertinente sur le projetSi le projet est grand, envisagez de le diviser en plusieurs sous-projets pour que le nombre de ressources dans chaque sous-projet ne soit pas trop important (par exemple : 100 ressources).
Cela peut sembler évident, mais en réalité, la lecture de la documentation est de loin la pratique la plus sous-estimée lorsque vous travaillez avec Terraform.
L’un des aspects qui différencie Terraform des autres projets est le travail incroyable que HashiCorp a réalisé avec la documentation officielle.
Que vous ayez des questions concernant la syntaxe HCL, la configuration Terraform, l’API, l’intégration VCS ou les espaces de travail Terraform, la documentation officielle devrait être votre point de départ. Cela vous permet d’économiser de nombreuses heures de recherche et peut même vous éviter de faire des erreurs lors de l’utilisation de configurations ou de conseils qui ne sont plus valides dans les versions les plus récentes de Terraform.
En d’autres termes, en lisant la documentation officielle de Terraform, vous :