Entendiendo a los proveedores de Terraform

En Terraform, un proveedor es un complemento que interactúa con proveedores de nube, herramientas de terceros y otras API. Para usar Terraform AWS, utiliza el AWS proveedor, que interactúa con los recursos. AWS

Si nunca has utilizado el AWS CloudFormation registro para incorporar extensiones de terceros en tus paquetes de despliegue, es posible que los proveedores de Terraform tarden un poco en acostumbrarse. Como CloudFormation es nativo de AWS, el proveedor de AWS recursos ya está ahí de forma predeterminada. Terraform, por otro lado, no tiene un único proveedor predeterminado, por lo que no se puede suponer nada sobre el origen de un recurso determinado. Esto significa que lo primero que debe declararse en un archivo de configuración de Terraform es exactamente a dónde van los recursos y cómo van a llegar allí.

Esta distinción añade una capa adicional de complejidad a Terraform que no existe. CloudFormation Sin embargo, esa complejidad proporciona una mayor flexibilidad. Puede declarar varios proveedores en un único módulo de Terraform y, a continuación, los recursos subyacentes que se creen pueden interactuar entre sí como parte de la misma capa de despliegue.

Esto puede resultar útil de muchas maneras. Los proveedores no tienen por qué ser necesariamente proveedores de nube independientes. Los proveedores pueden representar cualquier fuente de recursos en la nube. Por ejemplo, tomemos Amazon Elastic Kubernetes Service (Amazon EKS). Al aprovisionar un clúster de Amazon EKS, es posible que desee utilizar los gráficos de Helm para gestionar extensiones de terceros y utilizar el propio Kubernetes para gestionar los recursos de los pods. Como AWSHelm y Kubernetes tienen sus propios proveedores de Terraform, puede aprovisionar e integrar todos estos recursos al mismo tiempo y, después, transferir valores entre ellos.

En el siguiente ejemplo de código para Terraform, el AWS proveedor crea un clúster de Amazon EKS y, a continuación, la información de configuración de Kubernetes resultante se transmite a los proveedores de Helm y 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"
  }
}

En lo que respecta a los proveedores, las dos herramientas de IaC tienen que hacer concesiones. Terraform depende completamente de paquetes de proveedores ubicados externamente, que son el motor que impulsa sus despliegues. CloudFormation apoya internamente todos los procesos principales AWS . Con CloudFormation esto, solo debe preocuparse por los proveedores de terceros si desea incorporar una extensión de terceros. Cada enfoque tiene sus ventajas y desventajas. Cuál es el adecuado para usted va más allá del alcance de esta guía, pero es importante recordar la diferencia al evaluar ambas herramientas.

Uso de alias de Terraform

En Terraform, puede pasar configuraciones personalizadas a cada proveedor. Entonces, ¿qué pasa si desea usar configuraciones de varios proveedores dentro del mismo módulo? En ese caso, tendrías que usar un alias.  Los alias le ayudan a seleccionar qué proveedor usar a nivel de recurso o módulo. Cuando tiene más de una instancia del mismo proveedor, utiliza un alias para definir las instancias no predeterminadas. Por ejemplo, la instancia de tu proveedor predeterminado puede ser específica Región de AWS, pero usas alias para definir regiones alternativas.

El siguiente ejemplo de Terraform muestra cómo usar un alias para aprovisionar depósitos en diferentes áreas. Regiones de AWS La región predeterminada para el proveedor esus-west-2, pero puedes usar el alias este para aprovisionar recursos. 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"
}

Si utiliza un argumento alias junto con el provider metaargumento, como se muestra en el ejemplo anterior, puede especificar una configuración de proveedor diferente para recursos específicos. El aprovisionamiento de varios recursos Regiones de AWS en una sola pila es solo el principio. Asignar alias a los proveedores es increíblemente práctico en muchos sentidos.

Por ejemplo, es muy común aprovisionar varios clústeres de Kubernetes a la vez. Los alias pueden ayudarle a configurar otros proveedores de Helm y Kubernetes para que pueda utilizar estas herramientas de terceros de forma diferente para los distintos recursos de Amazon EKS. El siguiente ejemplo de código de Terraform ilustra cómo usar los alias para realizar esta tarea.

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