Skip to main content

Como testar Terraform com eficiência

Escrito por
Headshot of Peter De Tender

Peter De Tender

feature test in terraform

2 de agosto de 2022

0 minutos de leitura

Terraform é uma solução de infraestrutura como código (IaC) que permite que equipes de DevOps usem conceitos de programação para implantar automaticamente componentes de infraestrutura local ou na nuvem pública. Esses componentes podem incluir máquinas virtuais, componentes de rede, armazenamento, aplicações ou serviços de banco de dados.

Terraform oferece a HashiCorp Language (HCL). A HCL é uma linguagem unificada e específica de domínio que simplifica a criação de templates para diferentes provedores de nuvem, incluindo AWS CloudFormation da Amazon, Azure ARM Templates e Bicep da Microsoft, e Cloud Deployment Manager do Google para GCP.

Assim como testar código é essencial no desenvolvimento de software, testar uma solução de IaC como o Terraform é fundamental. Quando integrada corretamente, a testagem de IaC pode reduzir problemas significativos de gerenciamento de recursos e permite que equipes de DevOps validem a eficácia das configurações.

No entanto, integrar esses testes ao processo de DevOps pode ser um desafio. Surgem dúvidas sobre o que os testes devem incluir, o que podem deixar de fora e quais mecanismos disponíveis são mais eficazes. 

Há várias maneiras de testar templates do Terraform. Usar comandos integrados do Terraform, como terraform validate ou terraform plan, é a opção mais simples. Esses comandos permitem escrever testes unitários, de integração, de conformidade ou de ponta a ponta — em linha com as práticas tradicionais de teste de desenvolvimento de software. Como alternativa, podemos adotar uma abordagem mais voltada para desenvolvedores e testar com o Cloud Development Kit for Terraform (CDKTF).

Em última análise, as equipes de DevOps precisam ter clareza sobre os objetivos do processo de validação. Isso pode incluir verificar a sintaxe do template e garantir que a implantação seja bem-sucedida. Outra possibilidade é desenvolver um cenário de teste mais avançado: testar especificamente problemas de segurança ou configurações incorretas e detectar implicações de segurança durante as implantações. A ideia principal é determinar exatamente o que precisa ser testado e, então, encontrar a combinação adequada de soluções de teste.

Estratégias de teste para Terraform

Vamos conhecer algumas estratégias diferentes para testar Terraform.

Teste de desvios (drift)

Terraform valida sua infraestrutura atual usando o arquivo terraform state. Sempre que ocorre uma implantação do Terraform, o estado final é gravado em um arquivo de estado, que normalmente fica armazenado em um local compartilhado.

No entanto, se nem todas as implantações no ambiente de destino forem iniciadas pelo Terraform, pode haver uma diferença entre os recursos “reais” e o que o arquivo de estado do Terraform considera em execução. Quando essa implantação afeta um recurso que já é gerenciado pelo Terraform, o comando integrado terraform plan é útil, pois destaca mudanças ou diferenças entre o que está no escopo do arquivo de estado e o ambiente de destino real. Quando a implantação cria um recurso totalmente novo, ferramentas como driftctl e CloudQuery são úteis, pois informam quais recursos não estão sob o controle do Terraform.

Testes unitários

Os testes unitários estão entre os tipos de teste mais simples de executar. Eles consistem em realizar um teste específico e relativamente básico — normalmente em um único objeto. Muitas vezes, isso inclui verificar se a sintaxe do template está correta.

Para isso, podemos usar terraform validate. Se houver um erro na sintaxe do template, terraform validate retornará uma mensagem de erro (embora a validação bem-sucedida da sintaxe não garanta, por si só, que as implantações serão bem-sucedidas).

Para validar uma implantação, podemos usar outro comando integrado: terraform plan. Ao executar a etapa plan, o Terraform simula uma implantação real, comunica-se com o back-end do provedor e informa o resultado da implantação usando o comando terraform apply.

A saída de terraform plan destaca todas as mudanças detectadas em relação ao ambiente existente. Isso pode incluir a criação, modificação ou exclusão de recursos. Essas informações podem ajudar a equipe de DevOps a identificar o impacto da implantação antes de executá-la.

A próxima etapa é usar Terraform apply, que executa a implantação real. Mas lembre-se de que essa etapa nem sempre reflete totalmente a situação. Se você remover um recurso do HCL do Terraform e depois executar terraform apply, ele vai excluir o recurso na IaaS — porque, embora ele não esteja mais no HCL, ainda consta no estado do Terraform desde a última implantação bem-sucedida. O Terraform compara o estado do TF com a API da IaaS, identifica que o recurso não deve mais ser implantado e o exclui. Portanto, ainda é preciso observar possíveis dependências ou restrições no ambiente. Em cenários de nuvem, como AWS ou Azure, isso costuma ser gerenciado por meio da governança de políticas. 

Linting

Usar um linter também é útil. Ele permite que equipes de DevOps analisem o código em busca de erros, bugs ou trechos suspeitos. Isso ajuda a identificar problemas de sintaxe, mas também atende a casos de uso mais críticos, como a detecção de problemas de segurança.

Há várias ferramentas open source de linting para Terraform, com diferentes mecanismos de análise para diversas plataformas de destino — o GitHub oferece uma variedade de templates que usam tflint com diferentes provedores de nuvem.

Dependendo da complexidade do caso de uso do linting, o processo pode ser considerado um teste unitário simples ou fazer parte de um cenário de teste mais complexo ou avançado. Por exemplo, se o template permite implantar uma máquina virtual com um endereço IP público associado, a validação do linter pode detectar esse objeto de IP público e gerar um erro. O linter também pode detectar senhas ou strings de conexão codificadas diretamente no código.

Testes de integração

Mesmo que todos os testes unitários sejam aprovados, executar todos os planos do Terraform em sequência não garante o sucesso geral. Por isso, os testes de integração são essenciais. Em termos simples, eles consistem em executar uma combinação de testes unitários. No Terraform, os testes unitários normalmente têm como alvo um único módulo, enquanto os testes de integração validam vários módulos com dependências abrangentes.

Imagine que temos dois templates do Terraform separados: um para criar uma rede virtual ou nuvem privada virtual (VPC) e outro para implantar a infraestrutura de máquinas virtuais. Podemos executar cada um como um teste unitário independente, mas, em algum momento, queremos implantar as máquinas virtuais com sucesso usando os componentes da rede virtual já implantada. Se qualquer um dos módulos for implantado em uma região diferente, os testes unitários ainda serão aprovados, mas o teste de integração falhará.

Outra diferença importante: os testes unitários podem ser executados offline, sem implantar nada, enquanto os testes de integração exigem a implantação de recursos para validar o impacto e o sucesso.

Uma ferramenta que ajuda nos testes de integração é o Terratest by Gruntwork. Ela se baseia no framework da linguagem Go, com testes de pacote integrados, permitindo que equipes de DevOps apliquem os mesmos princípios a cenários de IaC.

Testes de conformidade

Ao validar templates do Terraform, as implantações técnicas precisam estar em conformidade com as normas corporativas. Isso exige testes de conformidade — para verificar padrões regionais, convenções de nomenclatura, padrões de infraestrutura, como tipos específicos de máquinas virtuais, e a segurança do armazenamento em disco.

Na maioria dos casos, a validação de conformidade faz (ou deveria fazer) parte da configuração do ambiente de destino, junto com a integração de políticas do Azure ou do centro de conformidade da AWS. No entanto, essas políticas só são validadas durante uma implantação real, que falhará se não estiver em conformidade com elas.

Ao integrar testes de conformidade ao processo de DevOps do Terraform, os testes são executados antes das implantações, ajudando a garantir que elas sejam bem-sucedidas. Uma solução é o Terraform-compliance, uma ferramenta externa que valida a conformidade da organização com os templates do Terraform.

Testes de ponta a ponta

Em última análise, as equipes de DevOps tentarão combinar todos os métodos de teste em um único cenário. O ideal é testar todos os templates, implantar todos os módulos e validar os resultados, sejam eles bem-sucedidos ou não.

A ideia parece ideal, mas os testes de ponta a ponta trazem desafios. A duração dos testes cria um gargalo — pode demorar muito mais para obter um resultado do que nos testes unitários, que são rápidos e fornecem resultados imediatos.

Testes unitários com CDKTF

Até aqui, nossos exemplos pressupõem o uso da linguagem nativa HashiCorp Language nos arquivos de template. No entanto, o Terraform também oferece uma abordagem de IaC mais voltada para desenvolvedores com o CDKTF - Cloud Development Kit for Terraform.

Com o CDKTF, equipes de DevOps podem implantar infraestrutura usando qualquer linguagem de programação tradicional, como Python, C#, Go e Java. Todos os provedores e módulos do Terraform são compatíveis com esse kit. A principal vantagem é que a equipe não precisa aprender HCL e pode aproveitar o conhecimento que já tem da linguagem de programação que usa.

O CDKTF adota uma abordagem diferente para escrever templates e executar implantações, por isso os testes unitários também funcionam de outra maneira. A documentação atualizada sobre testes com CDKTF está disponível no site do Terraform.

Ferramentas de segurança da Snyk

Testar sua IaC é fundamental para manter o ambiente saudável. Além de avaliar diferentes metodologias de teste, é importante destacar os aspectos de segurança. A Snyk oferece ferramentas úteis para isso:

  • Snyk Infrastructure as Code ajuda a integrar segurança a todas as etapas da criação de IaC, realizando a análise de segurança do código de forma semelhante à análise tradicional do código-fonte de aplicações.

  • driftctl, a ferramenta de teste de desvios mencionada anteriormente, é desenvolvida pela Snyk e está disponível como um mecanismo open source de detecção de desvios.

  • Snyk IaC inclui um amplo conjunto de regras de segurança predefinidas, baseadas em referências do setor, práticas recomendadas por provedores de nuvem e pesquisas sobre modelos de ameaças da Snyk. Também é possível criar regras personalizadas com o Snyk IaC usando o framework Open Policy Agent (OPA) e a linguagem de consulta Rego.

Saiba mais sobre segurança no Terraform

Testar templates é uma etapa fundamental do processo de criação. Além dos benefícios funcionais, os testes ajudam a otimizar a segurança das implantações do Terraform. Se você quer saber mais sobre como integrar segurança aos templates de implantação do Terraform, conheça a Snyk, que oferece ferramentas de validação de segurança para pipelines de DevOps e automação — incluindo Terraform.

Proteja a infraestrutura desde a origem

A Snyk automatiza a segurança e a conformidade de IaC nos fluxos de trabalho e detecta recursos com configurações divergentes ou ausentes.

Leia mais

feature customer snowflake
Article

Segurança desde o início: conheça a integração do Snyk Studio com o Snowflake Cortex Code

O Snyk Studio se integra ao Snowflake Cortex Code para detectar vulnerabilidades em código gerado por IA, dependências e contêineres durante o desenvolvimento.

blog feature pypi spoof
Article

A Snyk AI Security Platform completa, grátis para mantenedores de projetos open source

Mantenedores de projetos open source estão sobrecarregados com relatórios reais de vulnerabilidades e precisam de ajuda para priorizar, corrigir e lançar correções mais rápido. O Secure Developer Program da Snyk dá aos projetos qualificados acesso gratuito à Snyk AI Security Platform.

Article

Ataque à cadeia de suprimentos Miasma: código malicioso encontrado em pacotes npm de @redhat-cloud-services

Um worm da cadeia de suprimentos chamado Miasma foi encontrado em dezenas de versões npm de @redhat-cloud-services. O hook malicioso preinstall rouba credenciais, investiga identidades na nuvem e pode republicar outros pacotes.