Por que devemos usar mais o Terraform Cloud?

No meu dia-a-dia eu lido muito com Terraform para fazer a criação de arquiteturas em laboratório para validação e, é claro, criar e ajustar ambientes produtivos e não produtivos dos clientes.

Então, sinta a dor comigo. Para cada ambiente, pelo menos para Azure, eu vou precisar de no mínimo 4 variáveis que são:

ARM_SUBSCRIPTION_ID
ARM_TENANT_ID
ARM_CLIENT_SECRET
ARM_CLIENT_ID

Como variável de ambiente? Sim! Afinal, não quero credenciais zanzando por aí dentro do código. No fim, teremos algo chamado de Partial Configuration, mas isso é assunto para outro dia.

Agora, imagine isso para 100 ambientes entre laboratório e de clientes. Você precisa gerenciar qual Service Principal (SP) corresponde a qual ambiente, guardar Client ID, client secret, enfim, tudo para dar errado e, ainda que dê problemas, é um trabalho extremamente cansativo e passível de erro.

Além do mais, existem clientes que ainda não estão preparados para SRE/DevOps e muito menos DevSecOps. Para esses clientes só interessa o resultado final e o código criado seria o facilitador para provisionamento dos recursos.

O que piora é armazenar o estado do terraform. Para que ele possa rastrear e comparar o que foi proposto no código com o que já esta provisionado na nuvem, o estado é armazenado em um arquivo com extensão tfstate. Se você vai trabalhar em equipe, recomenda-se usar um backend remoto, esteja ele no Azure, AWS, etc. Contudo, por mais que o custo seja baixíssimo, esses mesmos clientes podem não querer ter uma storage account só para armazenar este tipo de arquivo.

Para esses e outros desafios existe o Terraform Cloud. Ao longo deste artigo explicarei o que é e apresentarei algumas formas de como eu o uso que poderá ser útil para você.

O que é Terraform Cloud?

É uma plataforma SaaS (Software as a Service) mantida pela Hashicorp que permite provisionar infraestrutura em praticamente qualquer provider e.g Azure, GCP e AWS, de maneira otimizada para o workflow do Terraform. No Terraform cloud também é possível aplicar o enforce de políticas seja de segurança ou governança, trabalhar em um modelo CI/CD e até mesmo versionar seu tfstate.

Existem 3 maneiras de usar o Terraform, até o momento que escrevo este artigo:

• Terraform CLI (open source e gratuito)
• Terraform Cloud (SaaS)
• Terraform Enterprise (Self-hosted)

Quando falamos de Terraform Cloud temos os seguintes planos:

Para o que precisamos, o plano gratuito já é mais que o suficiente.

Como configurar?

Pelo portal

A primeira para fazer é acessar o https://app.terraform.io e se cadastrar. Durante este processo, valide seu e-mail e em seguida você será direcionado para a tela de criação do nosso primeiro workflow.

Duas opções são entregues: iniciar a partir de um template que será focado em ter a execução do workflow do Terraform feito pela linha de comando e refletido na nuvem. A outra possibilidade é começar do zero, como a gente é "brabo" vamos nessa última opção!

Defina nome da sua organização que deverá ser único e um endereço de e-mail para notificações.

Note que uma organização é um lugar que times conseguem ganhar acesso a workspaces que pertencem àquela organização e consequentemente colaborar no ambiente.

E já que começamos a falar de workspace chegou a hora de configura-lo. A primeira coisa que temos que entender é que não é a mesma coisa que as workspaces do Terraform Local. Quando executado localmente , o Terraform gerencia uma coleção de recursos dentro de um diretório persistente que contem os arquivos de configuração, estado e variáveis. Já a workspace do Terraform cloud gerencia as coleções de recursos separadamente para cada uma das workspaces, ou seja, cada uma atuará de forma independente com varíaveis, autenticação e arquivos diferentes, como se fosse um diretório e algum outro projeto.

Para criarmos nossa primeira workspace temos que decidir entre 3 tipos:

No nosso caso, como estamos somente usando para testar o nosso código sem se precupar muito com o "branching" vamos de CLI-driven Workflow que permite que a gente execute Terraform plan e Terraform apply a partir de nosso terminal.

Agora daremos um nome a ela e a criaremos.

Agora que temos criado, seremos levados a seguinte tela que nos apoiará na configuração:

A nível de código

Agora chegou a hora de realizarmos a configuração no nosso código onde primeiramente iremos nos autenticar no Terraform cloud e isso pode ser feito das seguintes maneiras:

1. Logando com terraform login (Indicado se você está utilizando um PC com acesso ao browser).

2. Criando diversos blocos de credentials podendo inserir mais de uma credencial e posteriormente fazendo uso do credentials helper para dizer ao terraform onde utilizar cada uma das credenciais. A grande diferença é que nessa modalidade deve ser utilizado um token de usuário ou to time que tem acesso à workspace onde se deseja trabalhar.

3. Utilizar o token de usuário ou de time como variável de ambiente, por exemplo: TF_TOKEN_app_terraform_io

No nosso caso, chegou a hora de morfar... digo.. de logar! Ao executar o comando terraform login ele irá fazer a requisição do token e aí tem um ponto de atenção altíssimo que este token ficará salvo como texto em um json dentro do seu ambiente então muito cuidado com quem vcê deixa acessar sua máquina. Com este token o invasor conseguirá se conectar no terraform cloud e aí já viu né!

Uma vez logado vamos gerar o token que precisamos para passar para o terminal.

Copiado o token, inserimos no terminal

Uma vez logado, inserimos o código que irá dizer ao backend aonde devemos ir para executarmos ele com sucesso

  terraform {
    required_providers {
      azurerm = {
        source  = "hashicorp/azurerm"
        version = "~>3.0.0"
    }
  }
      cloud {
        organization = "brazuca"

        workspaces {
          name = "cloudsquad-blog"
        }
      }
}

Pra finalizar, executaremos um terraform init para validar que nossas configurações de backend estão corretas

Pulo do gato

Vamos deixar tudo muito mais interessante? Então vamos configurar algumas variáveis de ambiente que servirão para logarmos no Azure e provisionarmos nossa infraestrutura. Para isso, retornaremos ao terraform cloud e navegaremos até o "settings" (configrações) da sua workspace.

Clique em create variable set, defina um nome para este grupo de variáveis, selecione se deseja aplicar para todas as workspaces do seu ambeinte ou apenas para as selecionadas, lembrando que as workspces já deverão ter sido criadas antes para que você escolha onde será aplicado e insira as variáveis de ambiente para se logar com um service principal no Azure. Estou assumindo aqui que você já possui este conhecimento e caso não tenha, no worries, só seguir este passo a passo https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_client_secret

Marquei todas como sensíveis porque são informações que não posso compartilhar com vocês. Agora, se desejar deixar visível, be my guest :)

Voltamos a nossa workspace, vamos em variable e já podemos ver nosso grupo de variáveis atribuído.

E ao rodarmos nosso plan temos o seguinte resultado:

Ainda sim não vemos o resultado no terraform cloud, mas se executarmos o terraform apply já podemos enxergar na interface gráfica

Na interface poderíamos já aprovar e isso é muito bom quando estamos trabalhando em time, logo, se o teste estivesse sendo executado por mais de uma pessoa no mesmo time esta ferramenta poderia ser muito mais simples de configurar, mais rápido de iniciar os trabalhos e ainda por cima gratuita.

Resultado final:

Pulo do gato #1

Repararam que não foi preciso criarmos uma storage account no Azure e realizar toda a configuração de apontamento no Backend do terraform para salvarmos os estados lá? Isso é porque o terraform cloud mantém os tfstates dentro dele e o melhor é que versiona a cada execução do código que for realizada. Com isso temos os seguintes benefícios:

• Menos trabalho para configurarmos o backend
• tfstate versionado onde podemos usa-lo em caso de alguma configuração mal feita

• Lock durante a execução do workflow do Terraform impossibilitando que outro usuário derrube sua sessão

Pulo do gato #2

Outro ponto foi que não houve a necessidade de configurarmos os parâmetros de autenticação dentro do nosso código, logo, isso o tornou mais seguro, pois não salvará as informações como texto. E isso tem um nome que é "partial configuration". Podemos ver aqui os seguintes benefícios:

• Parâmetros de autenticação sendo passados como variáveis de ambiente e sem aquela necessidade de ficarmos passando eles na nossa sessão do terminal
• Feito um grupo de variáveis que poderia ser alterado facilmente e consequentemente se autenticando em outro tenant/subscription sem ter que ficar caçando os ids e secrets

Conclusão

Portanto, vimos aqui que apesar do Terraform ser uma ferramenta poderosa voltada, obviamente, para o Terraform ele é simples de se configurar e de já ter ele rodando para você testar seu código. Há muitas funcionalidades que ainda não conversamos sobre, mas que da bastante conteúdo para próximos artigos.

Podemos considerar ele como uma ferramenta de CI/CD? Pode se dizer que sim, pois ele permite que tenhamos uma integração contínua quando configuramos um repositório integrado a ele e uma execução de deploy automático ou manual. Vai do gosto do fregues.