Post

Modificando o comportamento padrão do ciclo de vida de recursos do Terraform

Nesse post, vou tentar abordar um pouco sobre o ciclo de vida de recursos do Terraform e falar um pouco sobre um bloco de meta-argumento bem especial.

O que acontece quando eu executo um terraform apply?

De forma resumida, quando você executa um apply, o comportamento padrão do Terraform é tentar realizar uma (ou mais de uma) das seguintes tarefas:

  • Criar recursos que existem no seu código mas não estão associados a um objeto da infraestrutura real no state.

  • Atualizar em execução recursos que tiveram alguma mudança na sua configuração em código.

  • Destruir recursos que existem no state mas não existem mais no seu código.

  • Destruir e recriar recursos que tiveram alguma mudança na sua configuração mas não podem ser atualizados em execução por limitações da API do provider.

Como deu pra ver, o apply não vai só criar ou atualizar recursos em execução, em certos casos vai ser preciso destruir o recurso.

O bloco de meta-argumento lifecycle

Pensando em casos onde por algum motivo você não quer que o Terraform tenha esse comportamento padrão em um apply, existe um bloco de meta-argumento bem especial chamado lifecycle:

1
2
3
  lifecycle {
   
  }

Esse bloco pode ser adicionado no corpo de um resource e tem os seguintes argumentos:

  • create_before_destroy (booleano): Caso seja true vai alterar o comportamento para casos onde a atualização precise destruir e recriar o recurso, nesse caso vai primeiro criar o novo recurso e só depois destruir.

  • prevent_destroy (booleano): Caso seja true o Terraform vai retornar um erro em qualquer plan que tenha a destruição de algum recurso.

  • ignore_changes (lista de nomes de atributos): Para a lista de atributos recebida, o Terraform vai ignorar mudanças nesses atributos. Um caso especial desse argumento é que caso seja uma lista com a keyword all o Terraform nunca vai verificar por mudanças.

Abaixo um exemplo com todos os argumentos:

1
2
3
4
5
6
7
8
9
10
11
resource "aws_instance" "my_instance" {

....
  lifecycle {
    prevent_destroy = true 
    create_before_destroy = true # esse caso vai ser desnecessário porque já existe o prevent_destroy habilitado.
    ignore_changes = [
      tags,
    ]
  }
}

Referências

This post is licensed under CC BY 4.0 by the author.