Comprendre les sources de données Terraform

Il est très courant que les piles de déploiement s'appuient sur des données provenant de ressources existantes. La plupart des outils IaC ont un moyen d'importer des ressources créées par un autre processus. Ces ressources importées sont généralement en lecture seule (bien que les rôles IAM constituent une exception notable) et sont utilisées pour accéder aux données nécessaires aux ressources de la pile. AWS CloudFormation permet d'importer des ressources, mais cette idée peut être mieux expliquée en examinant le AWS Cloud Development Kit (AWS CDK).

AWS CDK Cela aide les développeurs à utiliser les langages de programmation existants pour générer des CloudFormation modèles. Le résultat final d'une AWS CDK opération est une ressource importée dans CloudFormation. Cependant, la syntaxe utilisée avec le AWS CDK facilite la comparaison avec Terraform. Voici un exemple d'importation d'une ressource à l'aide du AWS CDK.

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

Une ressource importée est généralement créée en appelant une méthode statique sur la même classe que celle que vous utilisez pour créer une nouvelle ressource du même type. L'appel new Bucket(... créerait une nouvelle ressource, et l'appel Bucket.fromBucketAttributes(... en importe une existante. Vous transmettez un sous-ensemble des propriétés du compartiment à la fonction afin qu'elle AWS CDK puisse trouver le bon compartiment. Une autre différence, cependant, est que la création d'un nouveau bucket renvoie une instance complète de la Bucket classe, avec toutes les propriétés et méthodes disponibles. L'importation de la ressource renvoie unIBucket, qui est un type qui contient uniquement les Bucket propriétés requises. Bien que vous puissiez importer une ressource à partir d'une pile externe, les options d'utilisation de cette ressource sont limitées.

Dans Terraform, un objectif similaire est atteint en utilisant des sources de données. La plupart des ressources Terraform définies sont associées à une source de données disponible. Voici un exemple de ressource de compartiment Terraform S3 suivie de sa source de données correspondante.

# 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 seule différence entre ces deux éléments est le préfixe du nom. Comme indiqué dans la documentation relative à une source de données, il existe moins de paramètres que vous pouvez transmettre à une source de données qu'à une ressource. Cela est dû au fait que la ressource utilise ces paramètres pour déclarer toutes les propriétés d'un nouveau compartiment S3, tandis que la source de données a juste besoin de suffisamment d'informations pour identifier et importer de manière unique les données d'une ressource existante.

La similitude entre la syntaxe d'une ressource Terraform et d'une source de données peut être pratique, mais elle peut également être problématique. Il est courant que les développeurs Terraform novices utilisent accidentellement une source de données plutôt qu'une ressource dans leur configuration. Les sources de données Terraform sont toujours en lecture seule. Vous pouvez les utiliser à la place de la ressource correspondante pour les actions de lecture (comme la fourniture d'un nom d'identification à une autre ressource). Cependant, vous ne pouvez pas les utiliser pour des actions d'écriture, qui modifient fondamentalement certains aspects de la ressource sous-jacente. Pour cette raison, vous pouvez considérer une source de données Terraform comme une version clonée de la ressource sous-jacente.

Comme dans le précédent exemple d'AWS CDK iBucket, les sources de données sont utiles pour les scénarios en lecture seule. Si vous avez besoin d'obtenir des données à partir d'une ressource existante mais que vous n'avez pas besoin de conserver cette ressource dans votre pile, utilisez une source de données. C'est le cas par exemple lorsque vous créez une instance Amazon EC2 qui utilise le VPC par défaut du compte. Comme ce VPC existe déjà, il vous suffit d'extraire ses données. L'exemple de code suivant montre comment utiliser les données pour identifier le VPC cible.

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
}