O null_resource do Terraform foi introduzido em 2014 e, de acordo com a Hashicorp¹, é o 3º provedor mais baixado no Registro do Terraform.

Esse recurso é amplamente utilizado porque ele pode ser usado como um contêiner vazio, ou uma casca de recurso. Dentro deste contêiner, os usuários podem definir e executar códigos ou scripts arbitrários sem que estejam vinculados a um ciclo de vida de recurso.

Um caso de uso para o null_resource no Terraform é acionar processos externos ou executar ações que não estão diretamente relacionadas a nenhum recurso de infraestrutura, como executar um script personalizado ou executar um comando remoto em um servidor.

O exemplo abaixo mostra como imprimir “Ola Mundo” no terminal sempre que o ID da instância EC2 mudar.

resource "aws_instance" "ec2_example" {  
  ami           = "ami-XXXXXXXX"  
  instance_type =  "t2.micro"  
}  

resource "null_resource" "null_resource_hello" {  
  # Define quando o provisionador deve ser executado  
  triggers = {  
    # O provisionador é executado quando o `id` da instância EC2 muda  
    id = aws_instance.ec2_example.id  
  }  
  provisioner "local-exec" {  
    command = "echo Ola Mundo"  
  }  
}

Agora, se o null_resource é tão popular e útil, por que devemos parar de usá-lo?

Bem… o motivo é…

Um novo substituto nativo para o null_resource

Sim, um motivo para você parar de usar o null_resource é que o novo Terraform v1.4 suporta nativamente um recurso de contêiner vazio². Isso também significa que você não precisa mais configurar o null provider, o que tornará seu código um pouco mais limpo.

O nome do novo recurso é terraform_data. Ele está disponível por meio de um provedor integrado terraform.io/builtin/terraform e, de acordo com o anúncio¹, ele suporta todas as mesmas funcionalidades do null_resource.

Abaixo está um exemplo de como implementar o mesmo código apresentado anteriormente, mas usando o terraform_data em vez do null_resource.

resource "aws_instance" "ec2_example" {  
  ami           = "ami-XXXXXXXX"  
  instance_type =  "t2.micro"  
}  
  
resource "terraform_data" "tf_data_resource_hello" {  
  # Define quando o provisionador deve ser executado  
  triggers_replace = [  
    # O provisionador é executado quando o `id` da instância EC2 muda  
    aws_instance.ec2_example.id  
  ]  
  
  provisioner "local-exec" {  
    command = "echo Ola Mundo"  
  }  
}

Há duas principais diferenças entre o terraform_data e o null_resource.

• O recurso é chamado de terraform_data em vez de null_resource
• O gatilho terraform_data é chamado de triggers_replace em vez de triggers.

Quando você não deve usar o recurso terraform_data?

A regra geral do null_resource também se aplica ao terraform_data. Ele deve ser usado com moderação apenas quando não houver outra opção adequada disponível. Exemplos de quando você não deve usar o recurso são:

1. Quando um recurso mais específico estiver disponível: Se houver um recurso Terraform especificamente projetado para executar a tarefa de que você precisa, geralmente é melhor usar esse recurso em vez do terraform_data.
2. Quando você precisa manter o estado: O terraform_data não mantém o estado, ou seja, não pode ser usado para acompanhar mudanças ao longo do tempo ou impor certas condições.
3. Quando você precisa gerenciar configurações complexas em servidores provisionados: Em vez disso, considere usar ferramentas de gerenciamento de configuração dedicadas, como Chef, Puppet ou Ansible. Essas ferramentas são projetadas especificamente para gerenciar configurações complexas e podem fornecer melhor visibilidade e escalabilidade do que o terraform_data.

Recursos extras:

¹ https://www.hashicorp.com/blog/terraform-1-4-improves-the-cli-experience-for-terraform-cloud

² https://developer.hashicorp.com/terraform/language/resources/terraform -data?product_intent=terraform

Até o próximo post! 👋

Caso queira entrar em contato, você pode me encontrar no Twitter ou no LinkedIn.