Entendendo os estados e back-ends do Terraform

Um dos conceitos mais importantes em infraestrutura como código (IaC) é o conceito de estado. Os serviços de IaC mantêm o estado, o que permite declarar um recurso em um arquivo IaC sem que ele seja recriado toda vez que você implanta. Os arquivos IaC documentam o estado de todos os recursos no final de uma implantação para que ele possa comparar esse estado com o estado de destino, conforme declarado na próxima implantação. Portanto, se o estado atual contiver um bucket do Amazon Simple Storage Service (Amazon S3) my-s3-bucket chamado e as alterações recebidas também contiverem o mesmo bucket, o novo processo aplicará todas as alterações encontradas ao bucket existente em vez de tentar criar um bucket totalmente novo.

A tabela a seguir fornece exemplos do processo geral do estado do IaC.

Estado atual	Estado alvo	Ação
Nenhum bucket S3 chamado my-s3-bucket	Bucket S3 chamado my-s3-bucket	Crie um bucket S3 chamado my-s3-bucket
my-s3-bucketsem o controle de versão do bucket configurado	my-s3-bucketsem o controle de versão do bucket configurado	Nenhuma ação
my-s3-bucketsem o controle de versão do bucket configurado	my-s3-bucketcom o controle de versão do bucket configurado	Configure my-s3-bucket para ter controle de versão do bucket
my-s3-bucketcom o controle de versão do bucket configurado	Nenhum bucket S3 chamado my-s3-bucket	Tentativa de excluir my-s3-bucket

Para entender as diferentes maneiras pelas quais AWS CloudFormation o Terraform rastreia o estado, é importante lembrar a primeira diferença básica entre as duas ferramentas: CloudFormation está hospedada dentro do e o Nuvem AWS Terraform é essencialmente remoto. Esse fato permite CloudFormation manter o estado internamente. Você pode acessar o CloudFormation console e ver o histórico de eventos de uma determinada pilha, mas o CloudFormation serviço em si impõe as regras de estado para você.

Os três modos que CloudFormation operam em um determinado recurso são CreateUpdate, Delete e. O modo atual é determinado com base no que aconteceu na última implantação e não pode ser influenciado de outra forma. Talvez você possa atualizar CloudFormation os recursos manualmente para influenciar qual modo é determinado, mas não pode passar um comando CloudFormation que diga “Para este recurso, opere Create no modo”.

Como o Terraform não está hospedado no Nuvem AWS, o processo de manutenção do estado deve ser mais configurável. Por esse motivo, o estado do Terraform é mantido em um arquivo de estado gerado automaticamente. Um desenvolvedor do Terraform precisa lidar com o estado de forma muito mais direta do que faria com CloudFormation ele. É importante lembrar que o estado de rastreamento é igualmente importante para ambas as ferramentas.

Por padrão, o arquivo de estado do Terraform é armazenado localmente no nível superior do diretório principal que executa sua pilha do Terraform. Se você executar o terraform apply comando em seu ambiente de desenvolvimento local, poderá ver o Terraform gerar o arquivo terraform.tfstate que ele usa para manter o estado em tempo real. Para o bem ou para o mal, isso lhe dá muito mais controle sobre o estado no Terraform do que você tem no CloudFormation. Embora você nunca deva atualizar o arquivo de estado diretamente, há vários comandos da CLI do Terraform que você pode executar para atualizar o estado entre as implantações. Por exemplo, a importação do terraform permite que você adicione recursos criados fora do Terraform à sua pilha de implantação. Por outro lado, você pode remover um recurso do estado executando terraform state rm.

O fato de o Terraform precisar armazenar seu estado em algum lugar leva a outro conceito que não se aplica a CloudFormation: o back-end. Um back-end do Terraform é o local em que uma pilha do Terraform armazena seu arquivo de estado após a implantação. Também é aqui que ele espera encontrar o arquivo de estado quando uma nova implantação começar. Ao executar sua pilha localmente, conforme descrito acima, você pode manter uma cópia do estado do Terraform no diretório local de nível superior. Isso é conhecido como back-end local.

Ao desenvolver para um ambiente de integração contínua e implantação contínua (CI/CD), o arquivo de estado local geralmente é incluído no arquivo.gitignore para mantê-lo fora do controle de versão. Então, não há nenhum arquivo de estado local presente no pipeline. Para funcionar corretamente, esse estágio do pipeline precisa encontrar o arquivo de estado correto em algum lugar.É por isso que os arquivos de configuração do Terraform geralmente contêm um bloco de back-end. O bloco de back-end indica à pilha do Terraform que ela precisa procurar em algum lugar além de seu próprio diretório de nível superior para encontrar o arquivo de estado.

Um back-end do Terraform pode estar localizado em praticamente qualquer lugar: um bucket Amazon S3, um endpoint de API ou até mesmo um espaço de trabalho remoto do Terraform. Veja a seguir um exemplo de um back-end do Terraform armazenado em um bucket do Amazon S3.

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

Para evitar o armazenamento de informações confidenciais nos arquivos de configuração do Terraform, os back-ends também oferecem suporte a configurações parciais. No exemplo anterior, as credenciais necessárias para acessar o bucket não estão presentes na configuração. As credenciais podem ser obtidas a partir de variáveis de ambiente ou usando outros meios, como AWS Secrets Manager. Para obter mais informações, consulte Protegendo dados confidenciais usando o AWS Secrets Manager HashiCorp Terraform.

Um cenário de back-end comum é um back-end local usado em seu ambiente local para fins de teste. O arquivo terraform.tfstate está incluído no arquivo.gitignore para que não seja enviado ao repositório remoto. Então, cada ambiente dentro do pipeline de CI/CD manteria seu próprio back-end. Nesse cenário, vários desenvolvedores podem ter acesso a esse estado remoto, então você gostaria de proteger a integridade do arquivo de estado. Se várias implantações estiverem em execução e atualizando o estado ao mesmo tempo, o arquivo de estado poderá ficar corrompido. Por esse motivo, em situações com back-ends não locais, o arquivo de estado normalmente é bloqueado durante a implantação.