Como gerenciar o estado do Terraform?

Nota do editor: Esta publicação foi publicada originalmente em CloudSkiff.com. A CloudSkiff se juntou à Snyk em outubro de 2021.

Como gerenciar o estado do Terraform? E, por falar nisso, o que é um arquivo TFState? Como ele diferencia o código Terraform de outras ferramentas de gerenciamento de configuração e quais são as práticas recomendadas?

Como gerenciar o estado do Terraform?

Saber como gerenciar o estado do Terraform é essencial. Antes de tudo, o que é exatamente um TFState?

O arquivo TFState do Terraform é o que o diferencia bastante de outros sistemas. Você pode criar e implantar infraestruturas com outras ferramentas de gerenciamento de configuração, como Chef, Saltstack e Ansible, mas a maior diferença do Terraform está nesse estado.

Você pode ver seu arquivo TFState como uma grande estrutura JSON que representa a realidade da sua infraestrutura, trabalhando em conjunto com o código Terraform para declarar o chamado “estado desejado” que você quer alcançar.

Esse estado desejado é declarativo. Isso significa que, ao declarar no código que você quer um recurso específico com uma configuração específica e apply esse código, o Terraform vai “conversar” com a API do seu provedor de nuvem e criar todos esses recursos. Quando terminar, ele vai registrar nesse arquivo JSON a realidade da implantação no provedor de nuvem.

No fim das contas, você tem 3 situações com 3 elementos:

• seu código

• a realidade na conta do seu provedor de nuvem

• o arquivo de estado

O arquivo de estado é exatamente o espelho do último apply bem-sucedido do seu código. Ele funciona com qualquer tipo de recurso: você pode usá-lo com seu provedor de nuvem para implantar recursos de infraestrutura ou com qualquer outro tipo de provedor.

Digamos que você implante gráficos Helm usando o Terraform. Nesse caso, você também terá um arquivo de estado das implantações. O mesmo vale para o GitHub. Se você usar o provedor do GitHub, definir usuários e usar o mesmo usuário em um projeto no Google Cloud e em um IAM na AWS como usuário do GitHub, todas essas informações serão registradas para esse usuário específico e vinculadas ao arquivo de estado do Terraform.

Considere esse arquivo como a referência, acessível pelo seu código, que representa a realidade da infraestrutura existente.

Em resumo, o arquivo de estado representa a realidade da implantação no seu provedor de nuvem, com base na intenção declarada no código Terraform.

Como lidar com isso e onde armazenar o estado do Terraform?

Por padrão, não há uma opção definida. Na primeira vez que você inicializa seu repositório Git com código Terraform e aplica um pequeno trecho de código Terraform, o arquivo TFState é criado diretamente na raiz do repositório do GitHub. Você precisa salvá-lo em algum lugar. Por padrão, pode dar vontade de enviá-lo para o GitHub, como muita gente faz, mas essa não é uma das práticas recomendadas, pois ele pode conter segredos — e você provavelmente não quer enviá-los para o GitHub.

Mesmo assim, você precisa armazenar o arquivo de estado. Sem ele, você perde o que o Terraform considera a “infraestrutura existente”. Se você apagá-lo e executar um apply novamente, o Terraform vai tentar implantar toda a infraestrutura outra vez como se fosse “nova” — algo que você provavelmente não quer.

A prática recomendada é armazená-lo em um local compartilhado, geralmente em um bucket do Amazon S3 ou em outro tipo de bucket de armazenamento na AWS, no Azure ou no Google Cloud:

1resource "aws_instance" "vm" {
2  ami                    = data.aws_ami.amazon-linux.id
3  instance_type          = var.instance_type
4  tags = {
5    Name = "DEMO VM DESTROY ME - ${terraform.workspace}",
6    Terraform = "true"
7  }
8}
9
10data "aws_ami" "amazon-linux" {
11  most_recent = true
12  owners = ["amazon"]
13
14  filter {
15    name   = "name"
16    values = ["amzn-ami-hvm-*"]
17  }
18
19}

Em resumo, você declara seu back-end. Neste caso, é um código bem simples que implanta uma única VM. É apenas para demonstração. Uso esse código para experimentar e testar meus workspaces do Terraform, então não o considere adequado para projetos importantes.

Você pode configurar o Terraform usando a palavra-chave Terraform e dizer: “Para o Terraform, quero que meu back-end seja o S3, e o bucket do S3 deve ser este.”

Você define onde quer que seu arquivo de estado fique. É simples assim. No próximo Terraform apply, o Terraform vai usar um arquivo de estado temporário localmente e depois enviá-lo para seu bucket do S3.

Depois disso, sempre que você quiser trabalhar nele, o Terraform vai usar esse arquivo.

1terraform {
2  backend "s3" {
3    bucket = "cs-tfstates-demo-sj-frankfurt-1"
4    key    = "tfstates/terraform.tfstate"
5  }
6}

Uma última dica: não se esqueça de adicionar também um arquivo de bloqueio em um banco de dados. Assim, se esse bloqueio existir, duas pessoas não poderão iniciar uma ação destrutiva ou aplicar mudanças no Terraform ao mesmo tempo.

Proteja seu código Terraform

Snyk IaC protege suas configurações do Terraform (e também os templates de Kubernetes, CloudFormation e ARM!) enquanto você programa, com correções guiadas para você mesclar as alterações e seguir em frente. Você pode testar enquanto escreve, monitorar mudanças nos repositórios Git e automatizar os testes nos pipelines de build antes da implantação. Começar com um plano gratuito leva poucos minutos, enquanto uma violação causada por uma configuração incorreta de IaC pode deixar consequências para a vida toda. Cadastre-se abaixo e comece a proteger suas configurações.