Evite Desastres no Deploy: Usando Assertions e Blocos Run no Terraform

O Terraform evolui demais nos últimos tempos, pois antigamente testar uma infraestrutura como código significava executar o terraform apply em um ambiente de homologação e ficar torcendo para que nada desse errado, outra forma era recorrer a como código significava executar o terraform apply em um ambiente de homologação e ficar torcendo para que nada desse errado, outra forma era recorrer a ferramentas externas complexas como o famoso Terratest que exige um conhecimento em GO.

Mas agora temos uma saída nativa, o comando terraform test e dos arquivos de configuração main.tftest.hcl. Nesse artigo vamos entender como funciona essa recurso, o motivo de resistência de algunas analistas e também irei demonstrar casos reais de uso.

O que é o main.tftest.hcl?

O recurso foi introduzido de forma nativa a partir do Terraform 1.6, o arquivo .tftest.hcl permite criar testes unitários diretamente na linguagem HCL. Você pode definir cenários, injetar variáveis e validar se os outputs e o estado dos recursos atendem o que foi desejado antes de colocar o código no ambiente real.

Porque os testes de infraestrutura são necessários?

Escrever códigos reutilizáveis é uma excelente prática, mas também temos os riscos: uma alteração em um módulo compartilhado pode quebrar vários projetos que estavam dependentes do módulo. Os testes podem ajudar a resolver esse problema pois garante que:

·         As mudanças dos códigos sejam seguras

·         Políticas sejam respeitadas

·         A lógica de condicionais (count e for_each) funcione.

Por que alguns analistas ainda relutam em usar?

Apesar de ser um recurso com benefícios evidente, muitos profissionais que trabalham como DevOps ainda relutam em adotar testes nativos por alguns motivos:

·         Funciona no Plan : Existe uma uma sensação falsa que o comando terraform plan já cumpre esse papel de  teste. O Plan apenas faz a validação da sintase e se a API do provedor aceita a requisição, não existe a validação dos módulos.

·         Falta de cultura de escrever testes: Escrever os testes é um cultura enraizada no desenvolvimento de softwares, mas muito recente no mundo de infraestrutura.

·         Gerenciamento dos testes: O terraform test pode criar recursos reais e destruí-los logo após a validação, muitos profissionais ficam com receio dos custos temporários.

Estrutura Básica de um Teste

Um arquivo main.tftest.hcl é formado por blocos run , cada bloco executa o código com  as variáveis e logo em seguida aplica o assertions:

run "check_vm_sku" {
  command = apply
  assert {
    condition     = azurerm_linux_virtual_machine.vm.size == "Standard_B1s"
    error_message = "Erro: O tamanho da VM deve ser Standard_B1s."
  }
}

run "check_network_config" {
  command = apply
  assert {
    condition     = azurerm_public_ip.pip.allocation_method == "Static"
    error_message = "Erro: O IP Público precisa ser Estático."
  }
}

run "check_vnet_address_space" {
  command = apply
  assert {
    condition     = azurerm_virtual_network.vnet.address_space[0] == "10.0.0.0/16"
    error_message = "Erro: O range da VNet está incorreto."
  }
}

Vamos entender o uso em alguns casos

Caso de Uso: Um profissional precisa alterar o nome de uma subnet ou um parâmetro, sem que ele perceba essa alteração força a destruição e a recriação do serviço.

·         Com uma asserção no main.tftest.hcl pode validar propriedades estáticas ou o comportamento de um plano, se o plano indicar uma destruição de um recurso, o teste falha e bloqueia o deploy.

Conclusão

Podemos dizer que superar a resistência de usar o main.tftest.hcl paga os gastos temporários já na primeira falha evitada. O teste nativo transforma o modelo baseado na esperança para um modelo baseado na engenharia previsível.

Faça um teste com usando o meu Github: https://github.com/Ch1c4n0/evite-desastres-deploy-terraform-assertions