4 de maio de 2022 Renato Barbosa 2263 Views

Terraform e Gitlab-CI: Como gerenciar sua infraestrutura em nuvem

Introdução

O Terraform é uma ótima ferramenta para fazer o gerenciamento de sua infraestrutura em nuvem, normalmente iniciamos projetos de terraform rodando os principais comandos de construção e deleção de infraestrutura diretamente da nossa maquina, mantendo o estado tfstate em local compartilhado. Mas assim que o projeto toma forma precisamos roda-lo em um local comum, para que todos os desenvolvedores e administradores possam executar a partir do mesmo local e modelo, para isso muitas vezes optamos por uma ferramenta de CI/CD, onde podemos executar nossos projetos a partir de um repositorio GIT.

Antes de continuarmos é importante revisitarmos os conceitos de Integração Contínua (CI) e Entrega Contínua (CD). De maneira resumida, podemos definir CI/CD como uma série metodologias que visam a utilização de processos e ferramentas com o fim de ter entregas mais rápidas de novas versões de códigos, quando falamos códigos podemos entender como softwares e também infraestrutura atráves de IaC (Infraestruture as code).

dentro da estrutura de CI/CD muitas equipes de desenvolvimento seguem alguns passos em seu ciclo de desenvolvimento até a entrega final ou deployment, esse ciclo seria:

Submeter o código atualizado para um repositório Git;
Execução do processo de build do código;
Execução de testes automatizados;
Execução de algum processo de validação de segurança do código, como um SAST;
Execução do Deployment da aplicação.

Para a execução de todo esse processo de maneira automatizada temos algumas ferramentas como Jenkins, Github Actions e o Gitlab-CI. E normalmente esse processo é totalmente escrito em um arquivo que contempla todos esses passos, esse arquivo é chamado de pipeline.

Criação do repositório e arquivos terraform

Agora que temos algumas informações sobre o processo que será executado e suas motivações vamos ao projeto.

Antes de iniciarmos crie uma conta gratuita no gitlab, cadastre sua chave ssh e crie um repositorio.

Além desses é preciso atender alguns pré-requisitos.

Ter alguma familiaridade com Terraform;
Ter alguma familiaridade com o Git;
Conta na AWS (será necessária para subir o ambiente);
Acesso a um programatic Access da AWS (AWS_SECRET_ACCESS_KEY e AWS_ACCESS_KEY_ID).

Nesse projeto subiremos uma EC2 na AWS atráves do terraform utilizando todo o processo dentro do gitlab-ci, então let’s go.

Criamos o repositorio.

em seguida faremos o clone dele.

dentro do dirétorio do projeto criaremos dois arquivos.

main.tf

provider “aws” { region = “ca-central-1” }

é altamente recomendável que utilize o backend em um bucket ex: s3
para saber mais visite. https://www.terraform.io/language/settings/backends

ec2.tf

data “aws_ami” “image” { most_recent = true filter { name = “name” values = [“ubuntu/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*”] } filter { name = “virtualization-type” values = [“hvm”] } owners = [“099720109477”] # Canonical } resource “aws_instance” “ubuntu” { ami = data.aws_ami.ubuntu.id instance_type = “t2.micro” tags = { Name = “UbuntuMicro” } }

após a criação desses arquivos, faremos o push para nosso repositório remoto.

Implementando a pipeline

Antes de implementarmos a pipeline, iremos criar duas variáveis de ambiente para o nosso projeto no Gitlab, essas variáveis serão utilizadas para fazermos o deploy na nossa conta AWS. são elas: AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY.

para criarmos essas variáveis vamos em Settings>CI/CD.

Agora começaremos a criação de nossa pipeline.

O gitlab espera a nomeclatura .gitlab-ci.yml para a nossa pipeline, logo, criaremos esse arquivo.

dentro desse arquivo teremos:

O que temos nesse código?

image – aqui definimos qual imagem do container que rodará nossa pipeline, podemos utilizar qualquer imagem Docker, lembrando que caso tenhamos nosso proprio registry devemos ter as credencias como variáveis de ambiente.
cache – a opção cache nos permite fazer cache de arquivos ou informações que possam ser reutilizados em outros jobs.
before_script – dentro do before_script podemos definir tarefas que serão executadas antes do inicío de todos os jobs.
stages – esses são os estágios de nossa pipeline, por enquanto teremos apenas um stage que será de check, um stage pode ser compartilhado por mais de um job como no exemplo atual.
tf-fmt – esse é um job que faz parte do stage terraform:check, nele faremos uma verificação do formato do nosso código, avaliando as melhores práticas
tf-validate – esse job também faz parte do stage terraform:check, nele faremos um validate, para verificar se o nosso código não contém algum erro que o impeça de ser executado.

Bom… agora vamos executar nosso código, para isso vamos até a aba CI/CD>Pipelines

Após a execução bem sucedida, temos a seguinte informação:

agora temos nossa pipeline sendo executada mas faltam algumas partes do processo de deploy do terraform, o build e o deploy, agora vamos incluir esses passos na nossa pipeline.

image: name: hashicorp/terraform:light entrypoint: – ‘/usr/bin/env’ – ‘PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin’ – ‘AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}’ – ‘AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}’ cache: paths: – .terraform before_script: – terraform –version – terraform init stages: – terraform:check – terraform:plan – terraform:apply tf-fmt: stage: terraform:check script: – terraform fmt -check -recursive only: – branches tf-validate: stage: terraform:check tags: – terraform script: terraform validate only: – branches tf-plan: stage: terraform:plan script: – terraform plan -out=”plan.tfplan” artifacts: name: tfplan paths: – ./plan.tfplan tf-apply: stage: terraform:apply script: – terraform apply plan.tfplan when: manual

Temos algumas palavras reservadas novas aqui, no build temos artifacts, com ele é possível eu tranferir um arquivo gerado nesse job para um proxímo job, faço isso com o plan.tfplan, esse arquivo me garante que o que será aplicado no job apply será exatamente o que eu vi no job de plan. Outra palavra reservada está no job tf-apply que é o when, com ele é possível que eu defina que um determinado job só será executado caso eu aprove manualmente.

agora vamos ver a saída de toda a nossa pipeline.

Conclusão

O CI do gitlab é bem robusto e possui uma vasta gama de possibilidades, como vimos nesse artigo podemos facilmente fazer o deploy de nossa infraestrutura em cloud via terraform com ele, recomendo também ver mais sobre o assunto diretamente na documentação oficial.