Comprendre les fournisseurs de Terraform - AWS Directives prescriptives

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre les fournisseurs de Terraform

Dans Terraform, un fournisseur est un plugin qui interagit avec des fournisseurs de cloud, des outils tiers et d'autres API. Pour utiliser Terraform avec AWS, vous utilisez le AWS fournisseur, qui interagit avec les ressources. AWS

Si vous n'avez jamais utilisé le AWS CloudFormation registre pour intégrer des extensions tierces dans vos piles de déploiement, les fournisseurs Terraform auront peut-être besoin d'un certain temps pour s'y habituer. Comme CloudFormation il est natif de AWS, le fournisseur de AWS ressources existe déjà par défaut. Terraform, en revanche, n'a pas de fournisseur par défaut unique, donc rien ne peut être supposé quant à l'origine d'une ressource donnée. Cela signifie que la première chose à déclarer dans un fichier de configuration Terraform est exactement où vont les ressources et comment elles vont y arriver.

Cette distinction ajoute une couche de complexité supplémentaire à Terraform qui n'existe pas avec. CloudFormation Cependant, cette complexité apporte une flexibilité accrue. Vous pouvez déclarer plusieurs fournisseurs au sein d'un même module Terraform, puis les ressources sous-jacentes créées peuvent interagir les unes avec les autres dans le cadre de la même couche de déploiement.

Cela peut être utile de nombreuses manières. Les fournisseurs ne doivent pas nécessairement appartenir à des fournisseurs de cloud distincts. Les fournisseurs peuvent représenter n'importe quelle source de ressources cloud. Prenons l'exemple d'Amazon Elastic Kubernetes Service (Amazon EKS). Lorsque vous provisionnez un cluster Amazon EKS, vous souhaiterez peut-être utiliser des diagrammes Helm pour gérer les extensions tierces et utiliser Kubernetes lui-même pour gérer les ressources des pods. Comme AWSHelm et Kubernetes ont tous leurs propres fournisseurs Terraform, vous pouvez provisionner et intégrer ces ressources en même temps, puis leur transmettre des valeurs.

Dans l'exemple de code suivant pour Terraform, le AWS fournisseur crée un cluster Amazon EKS, puis les informations de configuration Kubernetes qui en résultent sont transmises aux fournisseurs Helm et Kubernetes.

terraform { required_providers { aws = { source = "hashicorp/aws" version = ">= 4.33.0" } helm = { source = "hashicorp/helm" version = "2.12.1" } kubernetes = { source = "hashicorp/kubernetes" version = "2.26.0" } } required_version = ">= 1.2.0" } provider "aws" { region = "us-west-2" } resource "aws_eks_cluster" "example_0" { name = "example_0" role_arn = aws_iam_role.cluster_role.arn vpc_config { endpoint_private_access = true endpoint_public_access = true subnet_ids = var.subnet_ids } } locals { host = aws_eks_cluster.example_0.endpoint certificate = base64decode(aws_eks_cluster.example_0.certificate_authority.data) } provider "helm" { kubernetes { host = local.host cluster_ca_certificate = local.certificate # exec allows for an authentication command to be run to obtain user # credentials rather than having them stored directly in the file exec { api_version = "client.authentication.k8s.io/v1beta1" args = ["eks", "get-token", "--cluster-name", aws_eks_cluster.example_0.name] command = "aws" } } } provider "kubernetes" { host = local.host cluster_ca_certificate = local.certificate exec { api_version = "client.authentication.k8s.io/v1beta1" args = ["eks", "get-token", "--cluster-name", aws_eks_cluster.example_0.name] command = "aws" } }

Il existe un compromis entre les fournisseurs en ce qui concerne les deux outils IaC. Terraform s'appuie entièrement sur des packages de fournisseurs externes, qui constituent le moteur de ses déploiements. CloudFormation soutient en interne tous les principaux AWS processus. Avec CloudFormation, vous ne devez vous soucier des fournisseurs tiers que si vous souhaitez intégrer une extension tierce. Chaque approche comporte des avantages et des inconvénients. Ce guide ne porte pas sur celui qui vous convient le mieux, mais il est important de garder à l'esprit la différence lors de l'évaluation des deux outils.

Utilisation d'alias Terraform

Dans Terraform, vous pouvez transmettre des configurations personnalisées à chaque fournisseur. Et si vous souhaitez utiliser plusieurs configurations de fournisseurs dans le même module ? Dans ce cas, vous devrez utiliser un alias.  Les alias vous aident à sélectionner le fournisseur à utiliser au niveau de la ressource ou du module. Lorsque vous avez plusieurs instances du même fournisseur, vous utilisez un alias pour définir les instances autres que celles par défaut. Par exemple, votre instance de fournisseur par défaut peut être spécifique Région AWS, mais vous utilisez des alias pour définir des régions alternatives.

L'exemple Terraform suivant montre comment utiliser un alias pour approvisionner des buckets dans différents compartiments. Régions AWS La région par défaut du fournisseur estus-west-2, mais vous pouvez utiliser l'alias est pour provisionner des ressourcesus-east-2.

provider "aws" { region = "us-west-2" } provider "aws" { alias = "east" region = "us-east-2" } resource "aws_s3_bucket" "myWestS3Bucket" { bucket = "my-west-s3-bucket" } resource "aws_s3_bucket" "myEastS3Bucket" { provider = aws.east bucket = "my-east-s3-bucket" }

Lorsque vous utilisez un alias avec le provider méta-argument, comme indiqué dans l'exemple précédent, vous pouvez spécifier une configuration de fournisseur différente pour des ressources spécifiques. Le provisionnement des ressources en plusieurs Régions AWS dans une seule pile n'est que le début. Les fournisseurs d'alias sont incroyablement pratiques à bien des égards.

Par exemple, il est très courant de provisionner plusieurs clusters Kubernetes à la fois. Les alias peuvent vous aider à configurer des fournisseurs Helm et Kubernetes supplémentaires afin que vous puissiez utiliser ces outils tiers différemment pour les différentes ressources Amazon EKS. L'exemple de code Terraform suivant illustre comment utiliser des alias pour effectuer cette tâche.

resource "aws_eks_cluster" "example_0" { name = "example_0" role_arn = aws_iam_role.cluster_role.arn vpc_config { endpoint_private_access = true endpoint_public_access = true subnet_ids = var.subnet_ids[0] } } resource "aws_eks_cluster" "example_1" { name = "example_1" role_arn = aws_iam_role.cluster_role.arn vpc_config { endpoint_private_access = true endpoint_public_access = true subnet_ids = var.subnet_ids[1] } } locals { host = aws_eks_cluster.example_0.endpoint certificate = base64decode(aws_eks_cluster.example_0.certificate_authority.data) host1 = aws_eks_cluster.example_1.endpoint certificate1 = base64decode(aws_eks_cluster.example_1.certificate_authority.data) } provider "helm" { kubernetes { host = local.host cluster_ca_certificate = local.certificate exec { api_version = "client.authentication.k8s.io/v1beta1" args = ["eks", "get-token", "--cluster-name", aws_eks_cluster.example_0.name] command = "aws" } } } provider "helm" { alias = "helm1" kubernetes { host = local.host1 cluster_ca_certificate = local.certificate1 exec { api_version = "client.authentication.k8s.io/v1beta1" args = ["eks", "get-token", "--cluster-name", aws_eks_cluster.example_1.name] command = "aws" } } } provider "kubernetes" { host = local.host cluster_ca_certificate = local.certificate exec { api_version = "client.authentication.k8s.io/v1beta1" args = ["eks", "get-token", "--cluster-name", aws_eks_cluster.example_0.name] command = "aws" } } provider "kubernetes" { alias = "kubernetes1" host = local.host1 cluster_ca_certificate = local.certificate1 exec { api_version = "client.authentication.k8s.io/v1beta1" args = ["eks", "get-token", "--cluster-name", aws_eks_cluster.example_1.name] command = "aws" } }