Comprendere i fornitori Terraform

In Terraform, un provider è un plug-in che interagisce con provider di cloud, strumenti di terze parti e altre API. Per utilizzare Terraform con AWS, si utilizza il AWS Provider, che interagisce con le risorse. AWS

Se non hai mai utilizzato il AWS CloudFormation registro per incorporare estensioni di terze parti nei tuoi stack di distribuzione, i provider Terraform potrebbero impiegare un po' di tempo per abituarsi. Poiché CloudFormation è nativo di AWS, il provider di AWS risorse è già presente per impostazione predefinita. Terraform, d'altra parte, non ha un unico provider predefinito, quindi non si può presumere nulla sull'origine di una determinata risorsa. Ciò significa che la prima cosa che deve essere dichiarata in un file di configurazione Terraform è esattamente dove stanno andando le risorse e come ci arriveranno.

Questa distinzione aggiunge un ulteriore livello di complessità a Terraform che non esiste. CloudFormation Tuttavia, tale complessità offre una maggiore flessibilità. È possibile dichiarare più provider all'interno di un singolo modulo Terraform e quindi le risorse sottostanti create possono interagire tra loro come parte dello stesso livello di implementazione.

Questo può essere utile in molti modi. I provider non devono necessariamente rivolgersi a provider cloud separati. I provider possono rappresentare qualsiasi fonte di risorse cloud. Prendiamo ad esempio Amazon Elastic Kubernetes Service (Amazon EKS). Quando esegui il provisioning di un cluster Amazon EKS, potresti voler utilizzare i grafici Helm per gestire le estensioni di terze parti e utilizzare Kubernetes stesso per gestire le risorse dei pod. Poiché AWSHelm e Kubernetes hanno tutti i propri provider Terraform, puoi fornire e integrare queste risorse tutte contemporaneamente e quindi passare valori tra di esse.

Nel seguente esempio di codice per Terraform, il AWS provider crea un cluster Amazon EKS, quindi le informazioni di configurazione Kubernetes risultanti vengono passate ai provider Helm e 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"
  }
}

C'è un compromesso per quanto riguarda i provider quando si tratta dei due strumenti IaC. Terraform si affida interamente a pacchetti di provider posizionati esternamente, che sono il motore che guida le sue implementazioni. CloudFormation supporta AWS internamente tutti i principali processi. Con CloudFormation, devi preoccuparti dei provider di terze parti solo se desideri incorporare un'estensione di terze parti. Ogni approccio presenta vantaggi e svantaggi. Qual è quello giusto per te non rientra nell'ambito di questa guida, ma è importante ricordare la differenza quando si valutano entrambi gli strumenti.

Utilizzo degli alias Terraform

In Terraform, puoi passare configurazioni personalizzate a ciascun provider. Quindi cosa succede se si desidera utilizzare più configurazioni di provider all'interno dello stesso modulo? In tal caso dovresti usare un alias.  Gli alias consentono di selezionare il provider da utilizzare a livello di risorsa o modulo. Quando hai più di un'istanza dello stesso provider, usi un alias per definire le istanze non predefinite. Ad esempio, l'istanza del provider predefinita potrebbe essere specifica Regione AWS, ma si utilizzano alias per definire regioni alternative.

Il seguente esempio di Terraform mostra come utilizzare un alias per effettuare il provisioning di bucket in diversi. Regioni AWS La regione predefinita per il provider èus-west-2, ma è possibile utilizzare l'alias east per il provisioning delle risorse. us-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"
}

Quando utilizzate un alias insieme al provider meta-argomento, come mostrato nell'esempio precedente, potete specificare una configurazione del provider diversa per risorse specifiche. Il provisioning di più risorse Regioni AWS in un unico stack è solo l'inizio. I provider di aliasing sono incredibilmente convenienti in molti modi.

Ad esempio, è molto comune effettuare il provisioning di più cluster Kubernetes contemporaneamente. Gli alias possono aiutarti a configurare provider Helm e Kubernetes aggiuntivi in modo da poter utilizzare questi strumenti di terze parti in modo diverso per diverse risorse Amazon EKS. Il seguente esempio di codice Terraform illustra come utilizzare gli alias per eseguire questa attività.

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"
  }
}