Terraform Best Practices
Terraform consultingTwitter @antonbabenkoTerraform Weekly
Français (French)
Français (French)
  • Bienvenue
  • Concepts clés
  • Structure du code
  • Exemples de structure de code
    • Terragrunt
    • Terraform
      • Infrastructure de petite taille avec Terraform
      • Infrastructure de taille moyenne avec Terraform
      • Infrastructure de grande taille avec Terraform
  • Convention des noms
  • Style de code
  • FAQ
  • Références
  • Ecrire des configurations Terraform
  • Atélier
Powered by GitBook
On this page
  • Ressource
  • Module de ressources
  • Module d'infrastructure
  • Composition
  • Source de données
  • État distant
  • Fournisseur, commission etc
  • Pourquoi est ce si difficile?
Export as PDF

Concepts clés

PreviousBienvenueNextStructure du code

Last updated 1 year ago

La documentation officielle de Terraform décrit . 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.

État distant

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?

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.

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

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }

}

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.

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

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 entre les compositions est souvent effectué à l'aide de sources de données à distance. Il existe .

tous les aspects de la configuration en détail
terraform-aws-atlantis
terraform-aws-vpc
terraform-aws-security-group
Atlantis
AWS Fargate
terraform-aws-cloudquery
terraform-aws-modules
externe
terraform-aws-lambda
http
état Terraform
terraform-aws-security-group
plusieurs façons de partager des données entre les configurations
Simple infrastructure composition