Comprensión de las fuentes de datos de Terraform

Es muy común que las pilas de despliegues se basen en datos de recursos previamente existentes. La mayoría de las herramientas de IaC permiten importar recursos que se crearon mediante algún otro proceso. Estos recursos importados suelen ser de solo lectura (aunque las funciones de IAM son una notable excepción) y se utilizan para acceder a los datos que necesitan los recursos de la pila. AWS CloudFormation permite importar recursos, pero esta idea puede explicarse mejor consultando la AWS Cloud Development Kit (AWS CDK).

AWS CDK Esto ayuda a los desarrolladores a utilizar los lenguajes de programación existentes para generar CloudFormation plantillas. El resultado final de una AWS CDK operación es un recurso importado en CloudFormation. Sin embargo, la sintaxis utilizada con el AWS CDK facilita la comparación con Terraform. A continuación, se muestra un ejemplo de cómo importar un recurso mediante. AWS CDK

const importedBucket: IBucket = Bucket.fromBucketAttributes(
    scope,
    "imported-bucket",
    {
        bucketName: "My_S3_Bucket"
    }
);

Por lo general, un recurso importado se crea llamando a un método estático de la misma clase que se utiliza para crear un nuevo recurso del mismo tipo. La llamada new Bucket(... crearía un recurso nuevo y la llamada Bucket.fromBucketAttributes(... importaría uno existente. Pasas un subconjunto de las propiedades del depósito a la función para que AWS CDK pueda encontrar el depósito correcto. Sin embargo, otra diferencia es que al crear un depósito nuevo se obtiene una instancia completa de la Bucket clase, con todas las propiedades y métodos disponibles en ella. Al importar el recursoIBucket, se devuelve un, que es un tipo que contiene solo las propiedades que Bucket debe tener. Aunque puede importar un recurso desde una pila externa, las opciones de lo que puede hacer con él son limitadas.

En Terraform, se logra un objetivo similar mediante el uso de fuentes de datos. La mayoría de los recursos definidos de Terraform tienen una fuente de datos adjunta disponible junto con ellos. El siguiente es un ejemplo de un recurso de bucket de Terraform S3 seguido de su fuente de datos correspondiente.

# S3 Bucket resource:
resource "aws_s3_bucket" "My_S3_Bucket" {
  bucket = "My_S3_Bucket"
}

# S3 Bucket data source:
data "aws_s3_bucket" "My_S3_Bucket" {
  bucket = "My_S3_Bucket"
}

La única diferencia entre estos dos elementos es el prefijo del nombre. Como se muestra en la documentación de una fuente de datos, hay menos parámetros disponibles que pueda pasar a una fuente de datos que a un recurso. Esto se debe a que el recurso usa esos parámetros para declarar todas las propiedades de un nuevo bucket de S3, mientras que la fuente de datos solo necesita la información suficiente para identificar e importar de forma exclusiva los datos de un recurso existente.

La similitud entre la sintaxis de un recurso de Terraform y una fuente de datos puede resultar práctica, pero también problemática. Es habitual que los desarrolladores novatos de Terraform utilicen accidentalmente una fuente de datos en lugar de un recurso en su configuración. Las fuentes de datos de Terraform siempre son de solo lectura. Puede utilizarlas en lugar del recurso correspondiente para las acciones de lectura (como proporcionar un nombre de identificación a otro recurso). Sin embargo, no se pueden usar para acciones de escritura, ya que modifican de manera fundamental algún aspecto del recurso subyacente. Por esta razón, puede pensar en una fuente de datos de Terraform como una versión clonada del recurso subyacente.

Al igual que en el ejemplo anterior de iBucket de AWS CDK, las fuentes de datos son útiles para escenarios de solo lectura. Si necesita obtener datos de un recurso existente pero no necesita mantener ese recurso dentro de su pila, utilice una fuente de datos. Un buen ejemplo de ello es cuando se crea una instancia de Amazon EC2 que utiliza la VPC predeterminada de la cuenta. Como esa VPC ya existe, todo lo que necesita hacer es extraer sus datos. En el siguiente ejemplo de código, se muestra cómo utilizar los datos para identificar la VPC de destino.

data "aws_vpc" "default" {
  default = true
}

resource "aws_instance" "instance1" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
  subnet_id     = data.aws_vpc.default.main_route_table_id
}