Ferramentas open source para testar código Terraform

Nota do editor: Esta publicação foi originalmente publicada em CloudSkiff.com. A CloudSkiff se uniu à Snyk em outubro de 2021.

O teste de código Terraform é um assunto recorrente que sempre aparece nas conversas. Muitas pessoas têm dúvidas sobre testes de código de infraestrutura, embora ainda vejamos pouca adoção de testes na prática. Antes de tudo: você deve testar seu código? Quais são as diferentes estratégias para automatizar testes e quais são as melhores ferramentas open source para isso?

Testar código Terraform é essencial — e, sim, você deve fazer isso. Há muitas maneiras de testar. O processo é muito parecido com o da engenharia de software tradicional. A cultura é a mesma, então não há nenhuma surpresa.

Teste código Terraform: comece usando linters

Você pode executar linters diretamente no seu computador ou no sistema de CI/CD para garantir que outras pessoas sigam determinadas convenções de código e padrões.

Um linter para Terraform de que gosto muito se chama TFLint. Ele é open source e está disponível no GitHub. É um linter “feito para infraestrutura”: analisa seu código de uma forma que o terraform validate não faria. terraform validate é um subcomando do Terraform. Basicamente, ele verifica apenas se a estrutura é válida, não se o conteúdo está correto. Isso significa que, se você especificar um tipo de máquina AWS inválido, o terraform validate não vai apontar o erro, mas o TFLint vai.

Veja como seria um commit com erro:

E veja como o erro seria identificado e apareceria nos logs:

Esse linter também oferece um recurso de “análise aprofundada”, que vai além da análise básica.

Imagine que você precisa solicitar uma VM válida já existente, como uma instância T3 grande. Se sua conta não tiver mais capacidade disponível (por exemplo, porque você já iniciou todas as VMs que podia solicitar), o linter consultará a API da AWS para verificar se o recurso solicitado está correto e se é possível executá-lo dentro dos limites da sua conta. Ele faz tudo o que se espera de um bom linter durante o desenvolvimento — verifica qualidade, tabs etc. — e vai além dos recursos de validação e formatação disponíveis no próprio Terraform.

Um caso de uso comum: você fez todos os testes em um ambiente de staging, cujos limites da AWS são bem altos porque, ao longo do tempo, você fez dezenas de solicitações para testar diferentes coisas. Talvez sua conta permita centenas ou até milhares de instâncias em cada região.

Mas então você decide promover uma nova alteração para produção, onde talvez as regras ou os limites da conta da AWS sejam diferentes. Nesse caso, você vai promover algo que não funcionará no ambiente de produção.

O linter com análise aprofundada garante que aquilo que você pretende promover ou iniciar em produção — seja a partir de staging, desenvolvimento ou qualquer outro ambiente — realmente possa ser executado de acordo com as permissões da sua conta.

Faça testes unitários no seu código Terraform com TDD

Um fluxo de trabalho ágil de engenharia bem estruturado começa com o desenvolvimento orientado a testes (TDD).

Ao começar a trabalhar com TDD, você escreve testes unitários, como: “quero criar minha VPC, que deve ter este espaço de endereços”. Em seguida, escreve sua função (no Terraform, ela é chamada de recurso) e a executa. Como veremos adiante, eu usaria qualquer ferramenta derivada do RSpec para isso: Serverspec, InSpec… As etapas do TDD seriam mais ou menos assim:

Comece escrevendo o teste: ele falha

Escreva o recurso. O teste não falha porque ele será iniciado em um ambiente isolado (especialmente a VPC).

Nesse processo, você testa o que queria e depois destrói o recurso. Dá para fazer exatamente o que você faria em um projeto de engenharia, como no seu CI: executar todos os testes em pull requests. Aliás, decidir o nível de segurança desejado ao começar a testar é um assunto delicado. Eu, pessoalmente, executo todos os testes antes de mesclar qualquer alteração, mas faço menos testes durante a etapa do pull request, porque executar todos os testes o tempo todo, a cada commit, pode demorar bastante.

Faça testes de integração

Outra possibilidade, bastante comum em processos de QA, é randomizar elementos, como variáveis. Terratest é outra ferramenta excelente para testes de integração. Provavelmente é a mais completa, mas também a mais complexa.

Vamos conhecer um pouco melhor essa ferramenta.

Terratest é uma biblioteca em Go. É preciso ter experiência para dominá-la (afinal, é Go…), mas ela permite testar qualquer coisa que tenha uma API, como AWS, Azure, Google Cloud, Kubernetes, imagens Docker, builds do Packer (ferramenta da HashiCorp para criar AMIs: imagens de disco de máquinas virtuais) e até charts do Helm.

Basicamente, você só precisa criar o nome do seu resource_test.go, importar as bibliotecas e executar o teste. Mas isso exige certo domínio de Go e um entendimento profundo do que você quer testar.

Randomize os elementos

Durante essa etapa de integração, eu randomizaria elementos como os nomes das regiões. Normalmente, você testa seu código sempre na mesma região. Ao randomizá-los, você obtém resultados diferentes e garante que tudo funcione.

Talvez os nomes que você usa sejam exclusivos, assim como os nomes dos seus recursos. Por exemplo, seu bucket do Amazon S3 precisa ter um nome exclusivo. O processo é o mesmo de um projeto de engenharia:

Use as ferramentas

• Analise seu código com um linter

• Faça testes unitários nos seus arquivos

• Randomize os elementos

• Inclua os resultados no seu CI

• Adicione isso aos seus pull requests

• Marque seu código e suas versões (como master)

• Use branches de funcionalidade, mescle-as em master e, em seguida, lance uma versão do código

Outras ferramentas que recomendamos para testar seu código de infraestrutura

Mencionei as ferramentas derivadas do RSpec: Serverspec, InSpec… O InSpec foi criado pela Chef, enquanto o Serverspec é mais voltado à comunidade, eu acho.

Serverspec foi criado para testes unitários, mas não é exclusivo do Terraform. É uma ferramenta mais abrangente. Você pode testar desde infraestrutura e imagens Docker até processos em execução em um servidor e coisas do tipo. Além disso, seu código é fácil de ler — bem próximo do inglês. É realmente genérico porque não testa o código diretamente nem corresponde de forma direta ao código Terraform do seu repositório de infraestrutura. Em vez disso, testa o que foi efetivamente iniciado. Por exemplo, se você adicionar um novo recurso, como um banco de dados no Google Cloud, e quiser verificar se a porta “5.4.3.2” está aberta, basta escrever e executar esse teste. Assim, você terá certeza para sempre de que há algo respondendo nessa porta. O Serverspec ajuda você a fazer isso de forma rápida e fácil.

Outra ferramenta de que gosto muito é o GOSS. É open source e muito legal. É simples e baseado em YAML. Não foi criado para testar código Terraform, mas sim para testar os resultados. Por exemplo, você criou um grupo de segurança e quer garantir que a porta 22 para SSH esteja fechada. Você pode testar isso, além de processos, pacotes, resolvedores DNS, usuários… Também pode verificar se seu endpoint HTTP no Kubernetes está respondendo e coisas do tipo…

Acho que ele até consegue gerar resultados de teste compatíveis com o Nagios. Assim, você pode executá-lo em um endpoint /health do seu microsserviço para garantir que tudo esteja funcionando corretamente. É realmente simples e leve. Gosto muito dessa ferramenta. Ela funciona muito bem com arquivos Docker etc.

Testando seu código Terraform

GOSS é ideal para verificações bem simples e de alto nível, com YAML simples e um binário leve e fácil de usar. Serverspec e InSpec são ótimos para testes unitários — e todos são open source.

E, claro, Terratest para testes de integração. É muito completo. Integre tudo isso ao seu sistema de CI/CD ou, pelo menos, execute os testes antes de publicar ou lançar o código. Caso contrário, você pode ter problemas.

Para testar seu Terraform em busca de vulnerabilidades de segurança, o Snyk IaC pode analisar suas configurações do Terraform (e também templates do Kubernetes, CloudFormation e ARM!) enquanto você programa, com correções guiadas para que você possa mesclar as alterações e seguir em frente. Teste enquanto escreve, monitore mudanças nos seus repositórios Git e automatize os testes nos pipelines de build antes da implantação. Você leva poucos minutos para começar com um plano gratuito, enquanto uma violação causada por uma configuração incorreta de IaC pode trazer danos permanentes. Inscreva-se e comece a proteger suas configurações abaixo.