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:
lifecycle {
}
Esse bloco pode ser adicionado no corpo de um resource e tem os seguintes argumentos:
create_before_destroy (booleano): Caso sejatruevai 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 sejatrueo Terraform vai retornar um erro em qualquerplanque 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 keywordallo Terraform nunca vai verificar por mudanças.
Abaixo um exemplo com todos os argumentos:
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,
]
}
}