Um guia prático para migrar o estado do Terraform para o GitLab CI/CD

Como um profissional de software que lida com Infraestrutura como Código (IaC), é provável que você trabalhe muito com Terraforma . Ao ajudar novos clientes a usar IaC, é comum simplificar as coisas, mas gerenciar um arquivo de estado do Terraform é o primeiro desafio que você enfrenta. Essencialmente, o estado do Terraform contém informações confidenciais que não devem ser armazenadas pelo controle de origem, mas, ao mesmo tempo, não serão dimensionadas se você tiver vários usuários trabalhando no mesmo estado do Terraform. A resposta para isso? Backends.

É importante observar que você pode armazenar esse arquivo de estado em um bucket do S3 e usar o DynamoDB para gerenciar o estado de bloqueio. No entanto, essa abordagem forçará você a criar recursos adicionais, o que a torna uma opção complicada, especialmente se o cliente estiver usando o GitLab. O GitLab recentemente reduziu a barreira de entrada para integrar o Terraform, fornecendo uma maneira de armazenar e gerenciar o estado do Terraform, bem como uma maneira fácil de configurar um CI em torno dele.

Nesta postagem do blog, explicaremos o que é um arquivo de estado do Terraform, como migrá-lo para o GitLab e configurar um CI Pipeline para ele. Você pode visitar nosso repositório aqui .

Índice

• O que é o estado Terraform?
• Como fazer com que o GitLab gerencie o estado do Terraform
• Como fazer o GitLab executar seu IaC por meio de um CI Pipeline
• Dica Bônus: Infracost
• Conclusão

O que é o Estado Terraforma?

O Terraform registra qualquer informação sobre a infraestrutura definida em seu código por meio de um arquivo de estado. Escrito em JSON, ele basicamente registra um mapeamento do código do Terraform para os recursos reais criados. Abaixo está um exemplo de como seria um terraform.tfstate.

Principalmente, toda vez que você executar o Terraform, ele buscará o status mais recente de sua instância do EC2 e o comparará com a configuração do Terraform para determinar quais alterações precisam ser aplicadas.

 { "version": 4, "terraform_version": "0.12.0", "serial": 1, "lineage": "1f2087f9-4b3c-1b66-65db-8b78faafc6fb", "outputs": {}, "resources": [ { "mode": "managed", "type": "aws_instance", "name": "example", "provider": "provider.aws", "instances": [ { "schema_version": 1, "attributes": { "ami": "ami-0c55b159cbfafe1f0", "availability_zone": "us-west-2a", "id": "i-00a123a0accffffff", "instance_state": "running", "instance_type": "t2.micro", "(...)": "(truncated)" } } ] } ] }

Por padrão, este terraform.tfstate é armazenado localmente onde você tem seus arquivos Terraform, planeja e aplica suas alterações. Para um projeto pessoal em que você está apenas executando alguns testes, tudo bem, mas não é a maneira recomendada, aqui está o porquê:

• Armazenado em um local compartilhado: se você estivesse hospedando esse arquivo de estado em sua estação de trabalho local e tivesse que trabalhar com outro engenheiro, as coisas ficariam complicadas. Vocês dois terão que se certificar de que estão usando a versão mais recente do estado e poderão enfrentar condições de corrida se executarem um plano Terraform ou se inscreverem ao mesmo tempo.
• Proteger informações confidenciais: um arquivo de estado gerado pode conter chaves de criptografia e senhas de infraestrutura. No entanto, os arquivos de estado não são criptografados por padrão e armazenar informações confidenciais em texto simples é uma má ideia.
• Bloqueio: a maioria dos sistemas de controle de versão não oferece suporte a nenhuma forma de bloqueio que impeça que dois membros da equipe executem o Terraform apply simultaneamente no mesmo arquivo de estado. Esse é outro motivo pelo qual não veremos um arquivo de estado gerenciado pelo controle de origem.

‍

Como obter o GitLab para gerenciar o estado do Terraform

Com o Terraform sendo considerado o padrão no provisionamento de infraestrutura em nuvem, faz mais ou menos um ano que o GitLab começou a oferecer uma maneira de armazenar e gerenciar seu estado do Terraform. Por esse motivo, gostaríamos de compartilhar o processo de migração com você, pois começamos recentemente a usar o GitLab para gerenciar nosso IaC.

Para este artigo, presumimos que você esteja usando um estado local e tenha seu estado gerenciado com um AWS S3 Bucket ou outra solução de back-end.

Em primeiro lugar, você precisará alterar seu backend.tf para usar HTTP.

 terraform { backend "http" {} }

Em seguida, você precisará configurar 4 variáveis em seu terminal:

• PROJECT_ID: você pode encontrá-lo facilmente navegando até seu repositório na página Visão geral do projeto

__ __

‍

• TF_USERNAME: nome de usuário do Gitlab que tem acesso ao repositório em que você está trabalhando.
• TF_PASSWORD: Token de acesso gerado pelo seu usuário do GitLab.
• TF_ADDRESS: URL do back-end do estado remoto

 PROJECT_ID="28450092" TF_USERNAME="florianpialoux" TF_PASSWORD="123456789" TF_ADDRESS="https://gitlab.com/api/v4/projects/${PROJECT_ID}/terraform/state/aws-buckets"

Agora você pode executar o comando de migração que moverá seu estado do Terraform de seu local anterior para o GitLab com o seguinte comando:

 terraform init \ -migrate-state \ -backend-config=address=${TF_ADDRESS} \ -backend-config=lock_address=${TF_ADDRESS}/lock \ -backend-config=unlock_address=${TF_ADDRESS}/lock \ -backend-config=username=${TF_USERNAME} \ -backend-config=password=${TF_PASSWORD} \ -backend-config=lock_method=POST \ -backend-config=unlock_method=DELETE \ -backend-config=retry_wait_min=5

Você precisará fornecer uma confirmação com um “sim” para que o GitLab possa começar a gerenciar seu arquivo de estado. Aqui está um exemplo de um estado local para o GitLab:

__ __

Exemplo s3 para GitLab

__ __

Agora você pode navegar para Infrastructure > Terraform na interface do GitLab e ver seu estado:

__ __

Percebi que alguns dos arquivos de estado que eu tinha do s3 ficarão em branco mesmo depois de usar o comando migration-state executado anteriormente, neste caso, você pode executar isto:

 terraform state pull > aws-buckets.json

Copie e cole o conteúdo do estado s3 e execute um push:

 terraform state push -lock=true aws-buckets.json

O GitLab oferece suporte ao controle de versão para seu arquivo de estado do Terraform, mas visualizar/restaurar versões mais antigas por meio da WebUI exigirá que você use um Plano GitLab Premium . Caso contrário, você precisará criar uma API GraphQL solicitar .

‍

Como fazer o GitLab executar seu IaC por meio de um pipeline de CI

O GitLab fornece uma imagem do docker que contém o GitLab-Terraform, que é um script wrapper fino em torno do binário oficial do Terraform. Alternativamente, você pode usar o imagem oficial do docker por Hashicorp. Você pode encontrar mais informações sobre o GitLab Terraform Image aqui .

Depois que o trabalho de aplicação do terraform for executado, você poderá ver quando o estado foi usado e com qual pipeline.

__ __

Saiba mais sobre a aparência do nosso gitlab-ci.yml aqui . Abaixo estão as variáveis que precisarão ser definidas no nível do projeto:

__ __

Dica Bônus: Infracost

Como você deve ter notado, olhando para o nosso gitlab-ci.yaml adicionamos Infracost o que nos permite ter mais controle sobre nosso faturamento de nuvem, pois fornece uma estimativa de custo sempre que você define um novo recurso para seu IaC. Para saber mais sobre a Infracost, você pode conferir nosso detalhado artigo sobre o que isso implica, e nosso passo a passo guia sobre como integrá-lo ao Terraform.

Conclusão

Ter o estado do Terraform e o CI em execução no Gitlab é uma ótima maneira de seguir as práticas recomendadas do GitOps. Ambos formam uma ótima combinação para desenvolver e implantar IaC. Como a maioria de vocês já pode estar usando o GitLab para seus repositórios, fica muito mais simples ter seu IaC sob o mesmo teto e permitir que o GitLab gerencie seu estado do Terraform, suportando criptografia em trânsito e em repouso, bem como controle de versão, bloqueio e desbloqueio do estado.