Principes fondamentaux de Terraform pour la configuration, la gestion et la mise à l'échelle

Les déclarations à elles seules ne suffisent pas à garantir un fonctionnement stable de l'infrastructure dans un environnement cloud en constante évolution.
Ce livre est un guide pratique pour appliquer correctement Terraform en pratique.
Nous allons passer en revue un par un les concepts clés, tels que la gestion d'état, la séparation de l'environnement d'exécution, la conception de modules personnalisés et l'utilisation de différents fournisseurs.
De plus, il contient des exemples applicables au travail réel, notamment la gestion des valeurs d'entrée à l'aide de YAML et CSV, l'intégration de logiciels libres tels que KeyClock et la configuration d'un environnement multirégional.
Pour quiconque souhaite approfondir sa compréhension de Terraform et l'utiliser de manière fiable, ce livre constituera un excellent point de départ.

Il est vrai qu'il existe une perception selon laquelle le langage HCL de Terraform est difficile à apprendre.
Cependant, HCL n'est qu'un langage de configuration déclaratif comme JSON ou YAML, et il vous permet de définir des références de champs de ressources ou des références entre ressources d'une manière plus simple que JSON ou YAML.
En fait, tout script pouvant être écrit en HCL peut être écrit en utilisant une syntaxe de configuration équivalente basée sur JSON.
De plus, HCL pourrait théoriquement aussi être exprimé dans son équivalent YAML, puisque JSON est un sous-ensemble de YAML.
HCL est simplement un langage créé pour faciliter l'écriture de fichiers de configuration JSON et YAML pour les administrateurs d'infrastructure, et est équivalent à JSON.

--- p.17

Vous pouvez définir et utiliser des modules comme sous-répertoires au sein d'un module.
On appelle cela un module imbriqué.
En règle générale, lorsqu'on parcourt une collection et qu'on crée des ressources de manière répétée, il peut être nécessaire de créer une gamme assez large de ressources à chaque itération.
Dans ce cas, vous pouvez l'implémenter en utilisant simplement for_each ou for sur plusieurs types de ressources à la fois, mais comme vous pouvez facilement le prévoir, il existe un risque élevé d'erreur.
Dans ce cas, vous pouvez utiliser une méthode pour améliorer la lisibilité du module racine en définissant des actions en fonction du parcours des modules imbriqués.
Les modules imbriqués sont généralement placés dans le sous-répertoire /modules, conformément à la convention officielle de Terraform, mais cela fonctionne correctement même si vous ne suivez pas cette convention si vous avez une bonne raison de le faire.

--- p.74

Les métadonnées AWS sont une valeur fréquemment utilisée dans divers environnements et projets en pratique, il est donc nécessaire de les solliciter plus souvent qu'on ne le pense.
Par exemple, il est courant d'associer à chaque ressource d'un module des informations de compte.
De plus, vous pouvez créer des branches pour générer différentes ressources en fonction du compte ou de la région que vous référencez actuellement.
Cependant, dans chacune de ces situations, l'appel direct à la valeur des métadonnées AWS n'est pas efficace en termes de maintenance du code.
Pour expliquer la raison, il faut tout d'abord que l'identifiant soit reçu via différents blocs de données appelés aws_caller_identity, l'alias via aws_iam_account_alias et les informations de région via aws_region dans les valeurs des métadonnées AWS.
Cependant, il est fastidieux de devoir vérifier quel bloc de données contient l'information recherchée chaque fois que j'ai besoin de métadonnées.
De plus, si vous devez découvrir les métadonnées dans cet état en appelant simplement plusieurs blocs de données, vous finissez par écrire du code répétitif et verbeux, ce qui réduit la lisibilité et la maintenabilité.

--- p.105

Comme pour le module VPC, le module de groupe de sécurité définit également le bloc de sortie sur une valeur qui peut être référencée à partir d'autres ressources.
Les seules nouvelles ressources créées dans ce module sont les groupes de sécurité et les règles des groupes de sécurité.
Étant donné que l'identifiant d'une règle de groupe de sécurité est rarement utilisé directement en dehors du module de groupe de sécurité, la seule chose qu'il est utile de définir comme valeur de sortie est l'ID du groupe de sécurité.
Par conséquent, nous définissons le bloc de sortie du module de groupe de sécurité pour exporter les identifiants de tous les groupes de sécurité créés dans le module au format carte.
Pour ce faire, nous appliquons une expression for à aws_security_group.this, un bloc de ressources qui pointe vers un groupe de sécurité, et définissons une carte sous la forme k =〉 v.id en utilisant des paramètres qui pointent vers des clés et des valeurs.
En conséquence, un bloc de sortie est créé, capable d'obtenir l'ID d'un groupe de sécurité à partir du nom de ce groupe.

--- p.187

Un fournisseur nul est une ressource virtuelle qui ne crée aucune ressource réelle.
Au lieu de gérer des ressources réelles, elles servent à exécuter des modèles ou des scripts externes, ou à contrôler des flux de travail simples.
Par exemple, vous pouvez l'utiliser pour envoyer des requêtes API non prises en charge par Terraform, ou pour contrôler le flux de création des ressources.
Cependant, dans la plupart des cas, l'exécution de scripts ou le contrôle des ressources est possible sans fournisseur nul, et son utilisation n'est pas recommandée car elle rend le code difficile à comprendre.
De plus, à partir de la version 1.4 de Terraform, un type de ressource natif Terraform avec le même rôle nommé terraform_data6 a été introduit, éliminant ainsi le besoin d'utiliser le fournisseur nul.
En fait, si vous comparez les deux ressources, tout est identique sauf que la propriété triggers de null_resource a été remplacée par triggers_replace dans terraform_data.

--- p.249

Atlantis est un outil open source représentatif pour la collaboration Terraform.
Il est recommandé car il permet de définir des règles telles que l'exécution automatique de commandes de planification ou de réflexion lorsque des modifications de code Terraform sont envoyées au dépôt, et il fournit même un environnement d'exécution Terraform cohérent.
Cependant, cela ne signifie pas qu'Atlantis doive être appliqué à tous les projets Terraform.
Tout d'abord, si vous disposez d'une petite équipe gérant Terraform, le coût d'installation d'Atlantis peut être supérieur aux avantages que vous en retirerez.
Puisqu'il s'agit d'un outil de gestion d'infrastructure, il doit impérativement être installé au sein du réseau de l'entreprise. Les coûts liés aux serveurs doivent donc être pris en compte, et pour ceux qui l'installent pour la première fois, la mise en œuvre du pipeline peut nécessiter un apprentissage. Il est donc recommandé de vérifier si son installation est absolument nécessaire avant de la mettre en place.

--- p.333