Mova o estado local para o S3

Introdução

Um responsável pela manutenção precisa de um local compartilhado para os mapeamentos de recursos de uma pilha em uso. Migre um estado local para um backend S3 separado e com versionamento, preservando o relatório existente, e observe o histórico do estado e o ciclo de vida independente do backend.

Você deve compreender o estado do Terraform, importação, planos salvos e versões de objetos S3. Todos os recursos deste laboratório são preparados neste novo ambiente; não é necessário um estado anterior nem uma conta pessoal da AWS.

Relação com certificações

Visão geral do laboratório

Estabeleça o limite entre o estado local e o backend

Nesta etapa, identifique o bucket de negócio e o destino separado para o estado. O diretório raiz de relatórios fornecido já gerencia migration-daily-reports; seu estado local é independente da referência financeira. O bucket com versionamento maintenance-team-state é preparado pela equipe de plataforma para que exista antes de este diretório raiz começar a usá-lo.

cd /home/labex/project/state-migration
terraform state list
terraform state show aws_s3_bucket.reports

Confirme que o ID do bucket remoto é migration-daily-reports. Um backend armazena mapeamentos de recursos; ele não é o provedor que cria e lê recursos AWS. As configurações de conexão do provedor e do backend são preparadas separadamente neste ambiente.

Salve um backup local privado antes de alterar o local de armazenamento do estado. O redirecionamento (>) grava o JSON do estado em um arquivo; não faça commit do estado nem de planos em um sistema público de controle de versão:

terraform state pull > local-before-migration.json
chmod 600 local-before-migration.json

Verifique o versionamento do backend e seu inventário inicialmente vazio:

aws s3api \
  get-bucket-versioning \
  --bucket maintenance-team-state

Espere Status: Enabled.

aws s3api \
  list-objects-v2 \
  --bucket maintenance-team-state

Ainda não deve existir nenhum objeto de estado. Escolher um destino vazio é importante: migrar para uma chave que já pertence a outro ambiente pode sobrescrever seu registro de gerenciamento. Mantenha migration-finance-reference intacto.

Migre o mapeamento existente para a chave S3 pretendida

Nesta etapa, configure um backend remoto e copie o mapeamento local de recursos existente para seu destino vazio. Uma chave é o nome do objeto de estado dentro do bucket do backend; escolha-a para um ambiente específico.

Escreva uma declaração parcial de backend S3. As configurações de conexão são fornecidas separadamente, e o próximo arquivo fornece sua escolha de bucket/chave:

cat > backend.tf <<'HCL'
terraform {
  backend "s3" {}
}
HCL

Crie a configuração de backend específica do ambiente. use_lockfile = true habilita o arquivo de bloqueio S3 nativo do Terraform para futuras operações de gravação:

cat > reports.s3.tfbackend <<'HCL'
bucket       = "maintenance-team-state"
key          = "reports/production.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

-migrate-state solicita ao Terraform que mova o mapeamento existente para o novo backend. O Terraform pergunta se deve copiar o estado existente; o pipeline com printf fornece a resposta yes. Execute isso somente depois de confirmar que a chave de destino deste laboratório estava vazia:

printf 'yes\n' | terraform init \
  -backend-config=backend-connection.hcl \
  -backend-config=reports.s3.tfbackend \
  -migrate-state

Espere a configuração bem-sucedida do backend S3 e a conclusão da inicialização. Não use a migração como forma de alternar para um ambiente já existente: selecionar um estado existente é uma operação diferente, abordada posteriormente neste curso.

Inspecione o mapeamento a partir de seu novo local:

terraform state show aws_s3_bucket.reports

O ID do recurso ainda deve ser migration-daily-reports. Confirme que o S3 agora contém o objeto de estado efetivo:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Um ETag e um VersionId mostram o objeto de estado armazenado. Esses metadados, por si só, são insuficientes: a verificação em segundo plano também lê seu mapeamento de recursos e compara a identidade e os bytes do relatório existente.

terraform plan

Espere No changes. A migração do estado não deve recriar o bucket de negócio.

Observe uma nova versão do estado remoto

Nesta etapa, faça uma atualização de configuração revisada e observe o histórico de estado resultante. O versionamento preserva objetos de estado anteriores; este laboratório observa o histórico, em vez de restaurar um estado danificado.

Adicione uma tag de revisão, mantendo inalterados o nome do bucket, o responsável e a configuração de destruição:

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "reports" {
  bucket        = "migration-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting", Revision = "two" }
}
HCL

Revise um plano salvo:

terraform plan -out=revision.tfplan

Espere 0 to add, 1 to change, 0 to destroy. Aplique apenas essa atualização no próprio recurso:

terraform apply revision.tfplan

Inspecione as versões do objeto do backend:

aws s3api \
  list-object-versions \
  --bucket maintenance-team-state \
  --prefix reports/production.tfstate

Devem existir pelo menos duas versões do estado após a migração e a atualização. Elas descrevem o histórico de gerenciamento; são distintas das versões do relatório de negócio no outro bucket.

aws s3 \
  cp s3://migration-daily-reports/report.txt -

O relatório continua sendo Daily sales: 120 orders. O AWS View mostra o negócio, a referência financeira e o backend como buckets separados. Arquivos de estado podem conter valores sensíveis; inspecione apenas os metadados necessários para este exercício.

terraform plan

Espere No changes. Verifique este estado em funcionamento antes de iniciar a fase separada de limpeza.

Remova os recursos de negócio, preservando o backend

Nesta etapa, desative esta pilha descartável de negócio após a aprovação das verificações de funcionalidade e preservação de dados. O backend da equipe de plataforma e a referência financeira independente estão fora do escopo de exclusão da pilha.

force_destroy = false impede que o Terraform esvazie silenciosamente o bucket de relatórios com versionamento. Identifique de forma deliberada a versão original do relatório antes de excluir o relatório deste laboratório. A substituição de comando salva seu ID; exiba esse identificador não secreto:

VERSION_ID=$(aws s3api \
  head-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --query VersionId \
  --output text)
echo "$VERSION_ID"

Exclua exatamente essa versão descartável e, em seguida, destrua o recurso de negócio. Estes comandos encerram intencionalmente a disponibilidade do relatório somente após a verificação de preservação da etapa anterior:

aws s3api \
  delete-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --version-id "$VERSION_ID"
terraform destroy -auto-approve

-auto-approve pula uma solicitação de confirmação; use-o aqui apenas para o único bucket descartável de negócio que você acabou de revisar. Espere 1 destroyed.

Confirme que seu registro de gerenciamento ainda existe no backend:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

O backend permanece, agora contendo um estado sem recursos de negócio gerenciados. A referência financeira ainda deve estar disponível. Destruir uma pilha não exclui o armazenamento usado por seu backend. Deixe esse backend intacto para seu responsável; não execute outra aplicação normal da configuração, pois ela recriaria o bucket de negócio desejado.

Consulte a documentação do backend S3 para conhecer a configuração do backend e os arquivos de bloqueio nativos.

Resumo

Você separou as funções do provedor e do backend, fez backup e migrou um mapeamento existente para o S3, observou versões de estado e removeu uma pilha de negócio sem excluir seu backend de responsabilidade independente.