Entendendo as fontes de dados do Terraform

É muito comum que as pilhas de implantação dependam de dados de recursos existentes anteriormente. A maioria das ferramentas de IaC tem uma forma de importar recursos que foram criados por algum outro processo. Esses recursos importados geralmente são somente para leitura (embora as funções do IAM sejam uma exceção notável) e são usados para acessar os dados necessários aos recursos dentro da pilha. AWS CloudFormation permite a importação de recursos, mas essa ideia pode ser melhor explicada examinando o. AWS Cloud Development Kit (AWS CDK)

AWS CDK Isso ajuda os desenvolvedores a usar as linguagens de programação existentes para gerar CloudFormation modelos. O resultado final de uma AWS CDK operação é um recurso importado em CloudFormation. No entanto, a sintaxe usada com o AWS CDK facilita a comparação com o Terraform. Aqui está um exemplo de importação de um recurso usando o. AWS CDK

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

Um recurso importado geralmente é criado chamando um método estático na mesma classe que você usa para criar um novo recurso do mesmo tipo. A chamada new Bucket(... criaria um novo recurso e a chamada Bucket.fromBucketAttributes(... importaria um existente. Você passa um subconjunto das propriedades do intervalo para a função para que ela AWS CDK possa encontrar o intervalo certo. Outra diferença, no entanto, é que a criação de um novo bucket retorna uma instância completa da Bucket classe, com todas as propriedades e métodos disponíveis nela. A importação do recurso retorna anIBucket, que é um tipo que contém somente as propriedades que Bucket devem ter. Embora você possa importar um recurso de uma pilha externa, as opções do que você pode fazer com ele são limitadas.

No Terraform, uma meta semelhante é alcançada usando fontes de dados. A maioria dos recursos definidos do Terraform tem uma fonte de dados complementar disponível junto com ela. Veja a seguir um exemplo de um recurso de bucket do Terraform S3 seguido por sua fonte de dados correspondente.

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

A única diferença entre esses dois itens é o prefixo do nome. Conforme mostrado na documentação de uma fonte de dados, há menos parâmetros disponíveis que você pode passar para uma fonte de dados do que para um recurso. Isso ocorre porque o recurso usa esses parâmetros para declarar todas as propriedades de um novo bucket do S3, enquanto a fonte de dados precisa apenas de informações suficientes para identificar e importar de forma exclusiva os dados de um recurso existente.

A semelhança entre a sintaxe de um recurso do Terraform e uma fonte de dados pode ser conveniente, mas também pode ser problemática. É comum que desenvolvedores novatos do Terraform usem acidentalmente uma fonte de dados em vez de um recurso em sua configuração. As fontes de dados do Terraform são sempre somente para leitura. Você pode usá-los no lugar do recurso correspondente para ações de leitura (como fornecer um nome de ID para outro recurso). No entanto, você não pode usá-los para escrever ações, que fundamentalmente alteram alguns aspectos do recurso subjacente. Por esse motivo, você pode pensar em uma fonte de dados do Terraform como uma versão clonada do recurso subjacente.

Semelhante ao exemplo anterior do AWS CDK iBucket, as fontes de dados são úteis para cenários somente de leitura. Se você precisar obter dados de um recurso existente, mas não precisar manter esse recurso em sua pilha, use uma fonte de dados. Um bom exemplo disso é quando você está criando uma instância do Amazon EC2 que usa a VPC padrão da conta. Como essa VPC já existe, tudo o que você precisa fazer é extrair seus dados. O exemplo de código a seguir mostra como usar dados para identificar a 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
}