Terraform, un projet relativement nouveau (comme la plus part des outils Devops actuellement), a été lancé en 2014.

Terraform est un outil puissant (si ce n'est le plus puissant actuellement disponible) et le plus utilisé pour le gestion de l'infrastructure comme code. Il permet aux developpeurs de créer plusieurs codes dont le support et l'intégration seront faciles

Certaines informations décrit dans ce livre pourraient ne pas ressembler aux bonnes pratiques. J'en suis conscient, et pour aider les lecteurs à séparer ce qui établit comme bonnes pratiques et ce que je considère être d'autres méthodes équivalentes, j'utiliserai par moment des indications pour fournir un certain contexte et des icônes pour spécifier le niveau de maturité de chaque sous-section reliée aux bonnes pratiques

Ce livre a été commencé dans une ville de Madrid ensoleillée en 2018 et est disponible gratuitement ici https://www.terraform-best-practices.com/

Quelques années plus tard il a été mis à jour grâce à plusieurs récentes bonnes pratiques disponibles avec Terraform 1.0. Éventuellement ce livre devrait contenir la plupart des bonnes pratiques et recommandations indiscutables pour les utilisateurs de Terraform.

Sponsors

Please if you want to become a sponsor.

Translations

Contactez-moi si vous voulez aider à traduire ce livre dans d'autres langues.

Contributions

Je souhaite toujours obtenir des commentaires et mettre à jour ce livre au fur et à mesure que la communauté mûrit et que de nouvelles idées sont mises en œuvre et vérifiées au fil du temps. Si vous êtes intéressé par certains sujets, veuillez ouvrir un problème ou en indiquer un que vous souhaitez être traiter plus en détail. Si vous sentez que vous avez du contenu et que vous souhaitez y contribuer, rédigez un brouillon et soumettez un pull request (ne vous souciez pas d'écrire un bon texte à ce stade !)

Authors

Ce livre est maintenu par Anton Babenko avec l'aide de différents contributeurs et traducteurs. Nicanor Foping l'a traduit en français.

License

Ce travail est sous licence Apache 2. Voir LICENCE pour plus de détails.

Les auteurs et contributeurs de ce contenu ne peuvent garantir la validité des informations trouvées ici. Veuillez vous assurer que vous comprenez que les informations fournies ici sont fournies librement et qu'aucun type d'accord ou de contrat n'est créé entre vous et toute personne associée à ce contenu ou projet. Les auteurs et les contributeurs n'assument pas et déclinent par la présente toute responsabilité envers toute partie pour toute perte, dommage ou perturbation causé par des erreurs ou des omissions dans les informations contenues dans, associées ou liées à ce contenu, que ces erreurs ou omissions résultent de négligence, accident ou toute autre cause.

Copyright © 2018-2023 Anton Babenko.

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

• Terragrunt - 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

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

Documentation

Documentation génèrée automatiquement

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

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 pour vous familiariser avec lui, et les référentiels existants (par exemple, ) 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 pour obtenir la documentation mise à jour automatiquement.

@ToDo: Document module versions, release, GH actions

Resources

3. Blog posté par :

La documentation officielle de Terraform décrit tous les aspects de la configuration en détail. Il faudrait la lire attentivement pour comprendre le reste de cette section

Cette section décrit les concepts clés qui seront utilisés dans le livre.

Ressource

Une ressource est un objet commeaws_vpc, aws_db_instance, etc. Une ressource appartient à un fournisseur, accepte des arguments, génère des attributs et possède des cycles de vie. Une ressource peut être créée, récupérée, mise à jour et supprimée.

Module de ressources

Un module de ressources est un ensemble de ressources connectées qui exécutent mutuellement l'action commune (par exemple, le module AWS VPC Terraform crée un VPC, des sous-réseaux, une passerelle NAT, etc.). Il dépend de la configuration du fournisseur, qui peut être définie dans celui-ci, ou dans des structures de niveau supérieur (par exemple, dans le module d'infrastructure).

Module d'infrastructure

Un module d'infrastructure est un ensemble de modules de ressources, qui peuvent logiquement ne pas être connectés, mais dans la situation/projet/configuration actuels, ils ont le même objectif. Il définit la configuration des fournisseurs, qui est transmise aux modules de ressources en aval et aux ressources. Il est normalement limité au travail dans une entité par un séparateur logique (par exemple, AWS Region, Google Project).

Par exemple, le module utilise des modules de ressources comme et pour gérer l'infrastructure requise afin d'opérationneliser sur .

Un autre exemple est le module qui emploie plusieurs modules de ensemble afin de gérer l'infrastructure et utilisent les ressources Docker pour créer, pousser et déployer des images Docker. Tout en un ensemble.

Composition

La composition est une collection de modules d'infrastructure, qui peuvent s'étendre sur plusieurs zones logiquement séparées (par exemple, des régions AWS, plusieurs comptes AWS). La composition est utilisée pour décrire l'infrastructure complète requise pour l'ensemble de l'organisation ou du projet.

Une composition est constituée de modules d'infrastructure, qui comprennent des modules de ressources implémentant des ressources individuelles.

Source de données

La source de données effectue une opération en lecture seule et dépend de la configuration du fournisseur. Elle est utilisée dans un module de ressources et un module d'infrastructure.

La source de données terraform_remote_stateagit comme une colle (lien) pour les modules et les compositions de niveau supérieur.

La source de données permet à un programme externe d'agir en tant que source de données, exposant des données arbitraires à utiliser ailleurs dans la configuration Terraform. En voici un exemple à partir du module où le nom de fichier est obtenu en appelant un script Python externe.

La source de données envoie une requête HTTP GET à l'URL donnée et exporte des informations liées à la réponse. Ces dernières sont souvent utiles pour obtenir des informations à partir de points de terminaison où un fournisseur Terraform natif n'existe pas.

État distant

Les modules et les compositions d'infrastructure doivent conserver leur dans un emplacement distant où il peut être récupéré par d'autres de manière contrôlable (par exemple, l'accès spécifique à l'ACL, la gestion des versions, la journalisation).

Fournisseur, commission etc

Les fournisseurs, les commission (provisioner) et quelques autres termes sont très bien décrits dans la documentation officielle et il est inutile de le répéter ici. À mon avis, ils ont peu à voir avec l'écriture de bons modules Terraform.

Pourquoi est ce si difficile?

Alors que les ressources individuelles sont comme des atomes dans l'infrastructure, les modules de ressources sont des molécules. Un module est la plus petite unité versionnable et partageable. Il a une liste exacte d'arguments, implémente une logique de base pour qu'une telle unité remplisse la fonction requise. Par exemple, le module crée des ressources aws_security_group etaws_security_group_rule en fonction de l'entrée. Ce module de ressources en lui-même peut être utilisé avec d'autres modules pour créer le module d'infrastructure.

L'accès aux données à travers les molécules (modules de ressources et modules d'infrastructure) est effectué à l'aide des sorties et des sources de données des modules.

L'accès entre les compositions est souvent effectué à l'aide de sources de données à distance. Il existe .

Lorsque vous mettez les concepts décrits ci-dessus dans des pseudo-relations, cela peut ressembler à ceci :

Utilisez locals pour spécifier des dépendances explicites entre les ressources

Moyen utile d'indiquer à Terraform que certaines ressources doivent être supprimées au préalable lorsqu'il n'y a pas de dépendance directe dans les configurations Terraform.

Il existe également un atelier pour les personnes qui souhaitent mettre en pratique certaines des choses décrites dans ce guide.

Le contenu est ici -

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:

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

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) :

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

Exemples de code de ressource

Utilisation de count / for_each

Emplacement de tags

Conditions dans count

Variables

1. Ne réinventez pas la roue dans les modules de ressources : utilisez le nom, la description et la valeur par défaut des variables telles que définies dans la section "Référence des arguments" pour la ressource avec laquelle vous travaillez.

2. La prise en charge de la validation dans les variables est plutôt limitée (par exemple, impossible d'accéder à d'autres variables ou de faire des recherches). Planifiez en conséquence car dans de nombreux cas, cette fonctionnalité est inutile.

3. Utilisez la forme plurielle dans un nom de variable lorsque type est list(...)

Sorties

Faire les sorties cohérentes et compréhensibles en dehors de son champ d'application (lorsqu'un utilisateur utilise un module, le type et l'attribut de la valeur renvoyée doivent être évidents).

1. Le nom de la sortie doit décrire la propriété qu'il contient et être moins libre que vous ne le souhaiteriez normalement.

2. Une bonne structure pour le nom de la sortie ressemble à {name}_{type}_{attribute} , où:

   1. {name} est le nom de la ressource ou de la source de données

Exemples de Code de sortie (output)

Renvoie au plus un ID de groupe de sécurité :

Lorsque vous avez plusieurs ressources du même type, cela doit être omis dans le nom de la sortie:

Utilisez un nom pluriel si la valeur retournée est une liste

- Liste des personnes qui travaillent très activement avec Terraform et qui peuvent vous en dire beaucoup (si vous leur demandez).

- Liste organisée de ressources sur Terraform de HashiCorp.

Source:

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

Les questions liées à la structure du code Terraform sont de loin les plus fréquentes dans la communauté. Tout le monde a également pensé à la meilleure structure de code pour le projet à un moment donné.

Comment devrais-je structurer mes configurations Terraform?

C'est l'une des questions pour lesquelles de nombreuses solutions existent, mais il est très difficile de donner des conseils universels, alors commençons par comprendre à quoi nous avons affaire.

Structures de code Terraform

Structures de code Terragrunt