Teoria do Terraform

Teoria do Terraform

Primeiramente, uma breve descrição sobre o que é “Infraestrutura como Código” ?

Infraestrutura como Código, Infra as Code, ou simplesmente IaC, é tratar a infra como um software, desenvolvendo, versionando, testando, depurando e colocando em produção, utilizando de ferramentas que lhe permitem declarar ou ordenar (imperativa) a infraestrutura, desde recursos em nuvens até a configuração do servidor web que está respondendo a requisição do seu navegador.

Este conceito de infraestrutura está muito ligado ao DevOps e SRE, pois aproximou o mindset do Dev para o SysAdmin que até então automatizava tudo com scripts.

As vantagens estão muito ligadas a facilidade e agilidade das coisas, não existem mais janelas gigantescas para fazer o provisionamento e configuração de ambiente, o código que produzido é auto documentado, reproduzível, portátil e ágil.

Então, onde entra o Terraform?

O Terraform é uma ferramenta open source de orquestração de infraestrutura, com uma arquitetura modular baseada em plugins, escrito em Golang, assim como boa parte das ferramentas que o cercam e segue a filosofia UNIX (faça uma coisa e faça bem).

O Terraform abstrai e simplifica a automação da infraestrutura em nuvem, transformando a interação com os cloud providers em uma linguagem declarativa próxima a humana, tornando o processo de provisionamento e gerenciamento de infra reproduzível, seguro e previsível.

O workflow do Terraform consegue unir o Dev e o Ops, pois controla, rastreia, documenta e automatiza a infraestrutura, demonstra a importância do git flow e com isso da oportunidade aos Devs de opinar e expor as necessidades deles para Ops, removendo barreiras entre os times e suas atividades. DevOps no sentido mais literal possível.

Extensões

Como tudo nesse maravilhoso mundo open source, o Terraform possui diversas “extensões”, ferramentas que trabalham ao redor do seu ecossistema, estendendo ou melhorando a utilização do mesmo.

Separei alguns exemplos interessantes:

  • Terragrunt:, pequeno wrapper que ajuda no desenvolvimento de modulos, evitando repetição de código e dando a possibilidade de paralelismo na execução dos mesmos.
  • Atlantis: permite uma integração ainda maior com o git, permitindo terraform plan e terraform apply de dentro do merge request.
  • Terraform-inventory: gera um inventario dinâmico do Ansible a partir de um state do Terraform.
  • Terraformer: gera o código de uma infra já existente.
  • tfsec: análise de segurança da infraestrutura.

 

Alternativas no mercado

Existem outras ferramentas que também fazem o trabalho ou parte, do Terraform, uma lista não exaustiva delas separadas por categoria é:

  • Configuration Management:
    • Ansible
    • Puppet
    • Chef
    • Saltstack
  • Cloud Provider:
    • AWS CloudFormation
    • Google Cloud Deployment Manager
    • Azure Resource Manager
  • Orchestration:
    • Pulumi
    • Gyro
    • Cloudify

E por último, seria utilizar as bibliotecas disponíveis ou chamadas de API REST do cloud provider desejado. Das ferramentas citadas, o Terraform sem dúvida é o mais desenvolvido delas.

As ferramentas de gerenciamento de configuração conseguem fazer parte do trabalho e inclusive podem até ser melhor vistas, afinal, você tem 2-em-1, provisionando e configurando seu ambiente ao mesmo tempo, porém, essas ferramentas falham em alguns pontos, por não ter módulos para desempenhar determinadas funções, comportamentos imprevisíveis e etc, geralmente para manter uma infra utilizando elas é necessário desenvolver scripts ou outros meios manuais para lidar com os problemas que aparecem durante o caminho.

Se você usa apenas uma cloud, utilizar a ferramenta de provisionamento do seu cloud provider pode ser uma boa ideia, mas tem um contra ponto grande, o vendor lock-in, num ambiente multi-cloud isso se torna um pouco mais problemático, pois será necessário investir tempo aprendendo X ferramentas distintas.

 

Ansible x Terraform

Um ponto que é muito questionado nas comunidades, dentro da salas de aulas da 4Linux e com certeza dentro das empresas é sobre qual dessas duas ferramentas utilizar.

Faremos então uma comparação rápida…

Dentro das ferramentas de gerenciamento de configuração o Ansible se destaca pela simplicidade, quantidade de módulos e documentação, ele também é muito usado para fazer o trabalho do Terraform, e consegue lidar até bem com isso, porém, quando você tem um caso de uso um pouco mais complexo, ou precisa impor um controle maior nessa infra, o Ansible não irá conseguir suprir seus requisitos.

Há claras diferenças na arquitetura ( e objetivos) da duas ferramentas, o que logicamente leva a comportamentos diferentes, por exemplo, o Ansible foi projetado para na maior parte dos casos utilizar uma sintaxe imperativa, diferente do Terraform que utiliza uma sintaxe declarativa com o propósito de declarar recursos. Uma vantagem implícita do Terraform sobre o Ansible é o Go, é natural durante o desenvolvimento no Ansible algum módulo quebrar durante um minor update do Python, especialmente no caso da GCP (devido a interação entre o Ansible e Magic Modules da Google), como o Go não teve uma mudança que quebre a compatibilidade com versões anteriores isso é bem mais difícil acontecer com o Terraform e de brinde você não esquenta a cabeça com as dependências do Python.

Por outro lado, é possível obter uma das melhores experiências de mercado na questão de automatização quando se tem o Terraform e o Ansible trabalhando em conjunto, sendo respectivamente, o Terraform orquestrando o ambiente e o Ansible gerindo as configurações das máquinas.

 

Registry

Parecido com o DockerHub, no Terraform temos o Registry, cuja função é ser um repositório de módulos e providers do Terraform, sendo o berço para providers de pequenos provedores cloud, assim se tornando uma fonte extremamente útil de código para reutilização no seu projeto.

No Terraform é possível tanto utilizar o Registry, que é publico, quanto o Terraform Cloud e ter uma solução privada para tal. Também é possível plugar módulos de qualquer VCS suportado pelo Terraform.

É fácil encontrar módulos também no Github, com uma simples busca é possível encontrar módulos prontos para deploy.

Terraform Cloud & Terraform Enterprise

O Terraform Cloud é basicamente uma Web UI com todo o workflow do Terraform integrado em único lugar, ele é uma versão cloud do Terraform Enterprise (solução paga e selfhosted), ela unifica o trabalho relacionada ao Terraform, provendo uma interface única para a interação do time, devido a forte integração com o git, possibilitando um fluxo de CI/CD.

Um grande ponto a respeito do Terraform Cloud/Enterprise é a possibilidade de uso do Sentinel, um framework para aplicação de compliance as code, onde você consegue aplicar “testes” a sua infraestrutura, garantindo sua infra e mitigando riscos de problemas futuros.

 

Mitos

Dois mitos que valem a pena discutir antes de adotar a ferramenta:

  • Vou escrever minha infra como código e nunca mais vou precisar tocar nele!

A menos que você não vá utilizar esse código é claro, de outro modo, assim como qualquer software, seu código vai precisar de manutenção, hora por uma mudança interna do cloud provider (API), hora pela evolução do Terraform, hora por melhorias. Exemplo disso foi a mudança do Terraform 0.11 para o Terraform 0.12, onde o time do Terraform utilizou o feedback da comunidade para melhorar o HCL, essa mudança necessitou da refatoração de códigos existentes, e a Hashicorp deu uma ajudinha ao prover ferramentas para automatizar a refatoração dessa mudança.

  • O Terraform é cloud agnostic!

O Terraform não é cloud agnostic, todo o código que você escrever vai servir somente para aquele cloud provider, ainda assim, a sintaxe é a mesma em todo o seu ecossistema. O Terraform é um meio-campo entre você construir a sua infraestrutura através dos painéis dos cloud providers ou utilizar as libs/APIs REST e ter que lidar com toda a lógica envolvida no projeto. Logo a implementação depende somente da API que o cloud provider expõe.

 

Pontos negativos

O Terraform é uma excelente ferramenta, mas assim como tudo na vida, ela tem seus pontos negativos…

  • State

O state é o arquivo json que contêm todas informações da infraestrutura gerenciada pelo Terraform. Problemas comuns durante o trabalho com ele são o locking do estado do arquivo e os secrets contidos nele.

Como é um arquivo que possui informação de toda infraestrutura é natural que contenha informações sensíveis a cerca da mesma, isso pode ser ou não um problema para quem for utilizar dependendo friamente da escolha de backend utilizado para guardar o state. Quando se trabalha em equipe é relativamente fácil corromper o state, dependendo do flow do desenvolvimento e do backend utilizado, quando o state se corrompe perde-se controle da infraestrutura já implantada.

  • Import

Importar uma infraestrutura existente para ser gerenciada pelo Terraform pode ser uma tarefa árdua, especialmente com a limitação na funcionalidade do mesmo (no momento), o import do Terraform apenas sabe da existência da sua infraestrutura, ele ainda não vai estar controlando ela, e esse pequeno equívoco pode levar a grandes problemas, pois ele não tem o código que a cria, afetando a imutabilidade da infra e consequentemente levando a passos imprevisíveis.

  • DRY

Escrever código repetido é extremamente comum no Terraform devido a sintaxe declarativa, é por isso que soluções como o Terragrunt e o Pulumi (que utiliza parte do Terraform por debaixo dos panos) existem.

  • API Breaks

Devido a constante evolução do Terraform é comum ter que refatorar o código num curto período de tempo para adequar as novas versões.

 

Conclusão

Em resumo, o Terraform é no momento, a melhor solução para provisionamento de recursos a ser utilizadas, a abstração que ele permite é na quantidade certa, não simplificando as coisas demais e perdendo controle e nem complicando de mais sendo complexo e inchado, seu workflow é simples e consistente, a comunidade é ativa e o projeto está em evolução contínua.

Num ambiente de infra como código, o trio Packer, Terraform e Ansible (ou o gerenciador de configurações de sua preferência) brilha e facilita muito a vida.

Se você se interessou pelo Terraform, sugiro fortemente que leia sua documentação e também o excelente Learn Hashicorp, para testá-lo sugiro também usar uma conta Free Tier da AWS, GCP ou Azure, caso já tenha os utilizado, uma opção barata, porém, com menos recursos, é a Digital Ocean, todos esses possuem providers do Terraform oficiais e mantidos pelos respectivos cloud providers. Caso precise de ajuda a comunidade sempre está disposta a ajudar, IRC, Gitter e o Fórum estão sempre de portas abertas.

Se você deseja conhecimento do que o Terraform faz por debaixo dos panos sugiro fortemente a leitura do Internal na documentação do Terraform, ela é clara e objetiva, uma olhada no core do Terraform também não faz mal, especialmente pra ficar a par dos possíveis bugs, vai ajudar bastante a entender o porque do seu comportamento.

CURSOSCONSULTORIA    CONTATO

Anterior Quando contratar suporte especializado para sua empresa ?
Próxima Criando um Container do Docker (Sem o Docker!)

About author

Bryan Albuquerque
Bryan Albuquerque 1 posts

Bryan Albuquerque, desenvolvedor nas horas vagas, atua como Engenheiro de Infraestrutura na 4Linux, é entusiasta de software livre, cloud e segurança. Formado em Análise e Desenvolvimento de Sistemas pela FATEC.

View all posts by this author →

Você pode gostar também

DevOps

Openshift: criação de cluster e deploy de uma aplicação

Esse post tem como objetivo criar um cluster de OpenShift Origin com um master e dois nós, a fim de fazer o deploy automático e definir o fluxo de integração

Infraestrutura

Zimbra: com remover e-mail enviado por engano

Em um dos meus projetos de zimbra recebi aquela pergunta que todo analista de T.I. já recebeu: ” Enviei e-mail errado  e foi para toda a empresa, preciso apagar este

Banco de Dados

Monitorando MongoDB com Prometheus e Grafana

O MongoDB é uma das soluções de NoSQL mais utilizadas na atualidade. Ele é um tipo de banco baseado em documentos assim como o AWS DocumentDB, Couchbase Server e Apache