Revise e aplique uma alteração de armazenamento

Introdução

Sua equipe precisa identificar um armazenamento de relatórios existente como release 2 sem recriar o armazenamento nem alterar seu relatório. Você revisará um plano salvo, aplicará esse plano e, em seguida, detectará e corrigirá um desvio deliberado de tag.

Este ambiente independente prepara o pequeno armazenamento inicial e o estado local. Use seus conhecimentos de plan/apply, arquivos de variáveis e consultas ao S3; estado remoto e aprovações automatizadas não são necessários.

Relação com certificações

Revise e aplique um plano salvo

Nesta etapa, você atualizará a tag de release de um armazenamento de relatórios preparado usando um plano salvo, preservando seu bucket e relatório existentes.

Este novo diretório raiz já gerencia o pequeno armazenamento que os laboratórios anteriores ensinaram você a criar. A preparação fornece esse cenário inicial para que você possa se concentrar na revisão de alterações. A nova release desejada é 2; o relatório existente deve continuar sendo orders,12. Comece lendo a configuração, os valores e a tag atual:

cd /home/labex/project/storage-change
cat main.tf
cat release.tfvars
terraform state list
aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports

O arquivo de entradas atualmente seleciona a release 1. Uma alteração no nome do recurso poderia substituir o armazenamento, mas uma alteração de tag pode atualizar o bucket existente. Altere apenas a entrada de release:

cat > release.tfvars <<'EOF'
release = "2"
EOF
terraform plan -var-file=release.tfvars -out=change.tfplan

Espere uma atualização no próprio bucket: 0 to add, 1 to change, 0 to destroy. -out grava um artefato de plano nativo que contém esta configuração e estes valores de entrada. Diferentemente de uma prévia não salva, aplicar esse arquivo usa o plano revisado, em vez de gerar um novo a partir de edições posteriores. Planos podem conter valores sensíveis em projetos reais, portanto trate-os como artefatos do projeto.

Leia o plano salvo antes de aplicá-lo:

terraform show change.tfplan

Confirme que Release muda de 1 para 2 e que nenhum objeto ou bucket é substituído. Em seguida, aplique o artefato. Nenhuma solicitação adicional de yes aparece para um plano salvo:

terraform apply change.tfplan

Consulte a tag atual e leia o relatório:

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
aws s3api \
  get-object \
  --bucket terraform-change-reports \
  --key reports/current.csv \
  retained.csv
cat retained.csv

Espere a release 2 e orders,12. Um plano salvo só é útil quando o recurso ao qual ele foi aplicado e os dados preservados correspondem à alteração revisada.

Detecte e corrija um desvio de tag

Nesta etapa, você observará uma alteração efetiva de tag feita fora do Terraform e restaurará a configuração declarada sem alterar o relatório.

Desvio é uma diferença entre o recurso implantado e sua configuração desejada. Use a AWS CLI para alterar a tag fora do Terraform. Este exercício deliberado altera um atributo real do recurso que o provedor pode ler; ele não edita um marcador local de sucesso.

aws s3api \
  put-bucket-tagging \
  --bucket terraform-change-reports \
  --tagging '{"TagSet":[{"Key":"Project","Value":"TerraformReports"},{"Key":"Release","Value":"unexpected"}]}'

Peça ao Terraform que compare o recurso atual com a release desejada. -detailed-exitcode distingue 0 (nenhuma alteração), 2 (uma alteração proposta) e 1 (um erro). O plano a seguir retorna intencionalmente 2; isso significa que encontrou a diferença na tag, não que a implantação falhou.

terraform plan -var-file=release.tfvars -detailed-exitcode

O plano propõe alterar unexpected de volta para 2. Revise e salve a correção e, em seguida, aplique esse artefato:

terraform plan -var-file=release.tfvars -out=repair.tfplan
terraform show repair.tfplan
terraform apply repair.tfplan

Confirme a tag atual e um plano convergente:

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
terraform plan -var-file=release.tfvars -detailed-exitcode

A tag é 2; o plano final informa No changes e encerra com código 0. O relatório permanece inalterado. Isso demonstra um desvio de tag que pode ser lido, não a detecção de toda possível modificação de dados fora do Terraform. Consulte Terraform plan para conhecer planos salvos e códigos de saída detalhados.

Limpe o armazenamento alterado

Nesta etapa, você removerá apenas o armazenamento gerenciado por este diretório raiz após a aprovação das verificações da alteração e do desvio.

Revise e execute a exclusão, digitando yes para destroy:

terraform plan -destroy -var-file=release.tfvars
terraform destroy -var-file=release.tfvars

O objeto de relatório é removido antes de seu bucket. Consulte os recursos restantes e o mapeamento vazio:

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

O relatório de referência da equipe permanece. Planos locais salvos são artefatos de revisão; sua presença não significa que recursos AWS excluídos ainda existam.

Resumo

Você aplicou um artefato nativo de plano revisado, distinguiu atualizações no próprio recurso de substituições, observou um desvio real de tag por meio de leituras do provedor, restaurou a configuração desejada e preservou os dados do relatório até a limpeza.