审查并应用存储变更

介绍

你的团队需要将现有报告存储标记为发布版本 2，同时不重新创建存储或更改报告。你将审查并应用一份已保存的计划，然后检测和修复一次刻意引入的标签漂移。

这个独立环境已准备好初始的小型存储和本地状态。运用你的 plan/apply、变量文件和 S3 查询知识；无需远端状态或自动化审批知识。

与认证考试的关联

审查并应用已保存的计划

在这一步中，你将使用已保存的计划更新预先准备的报告存储的发布标签，同时保留现有存储桶和报告。

这个全新根目录已管理前面实验教你创建的小型存储。环境准备过程提供该初始场景，让你专注于变更审查。期望的新发布版本为 2；现有报告必须保持为 orders,12。先读取配置、变量值和当前标签：

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

输入文件目前选择发布版本 1。更改资源名称可能导致替换存储，而更改标签可以更新现有存储桶。仅更改发布版本输入：

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

预期就地更新存储桶：0 to add, 1 to change, 0 to destroy。-out 写入一份原生计划产物，其中包含此配置及这些输入值。与未保存的预览不同，应用此文件会使用这份已审查的计划，而不是根据后续编辑重新生成计划。在实际项目中，计划可能包含敏感值，因此应将其作为项目产物妥善处理。

应用之前，先读取已保存的计划：

terraform show change.tfplan

确认 Release 从 1 改为 2，且没有对象或存储桶被替换。然后应用该产物。已保存的计划不会再出现 yes 确认提示：

terraform apply change.tfplan

查询当前标签并读取报告：

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

预期发布版本为 2，报告为 orders,12。只有应用后的资源和保留的数据与所审查的变更一致，保存计划才有意义。

检测并修复标签漂移

在这一步中，你将观察在 Terraform 之外进行的实际标签变更，并在不更改报告的情况下恢复声明的配置。

漂移是已部署资源与其期望配置之间的差异。使用 AWS CLI 在 Terraform 之外更改标签。这项刻意安排的练习更改的是 provider 可以读取的实际资源属性，而不是编辑本地成功标记。

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

让 Terraform 比较当前资源与期望的发布版本。-detailed-exitcode 区分 0（无变更）、2（提出变更）和 1（错误）。以下计划预期返回 2；这表示它发现了标签差异，而不是部署失败。

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

计划提出将 unexpected 改回 2。审查并保存修复计划，然后应用该产物：

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

确认当前标签和已收敛的计划：

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

标签为 2；最终计划显示 No changes，并以 0 退出。报告保持不变。这证明了可以检测到可读取的标签漂移，并不代表能够检测所有可能发生在 Terraform 之外的数据修改。有关保存计划和详细退出码，请参阅 Terraform plan。

清理变更后的存储

在这一步中，在变更和漂移检查通过后，你将仅删除此根目录管理的存储。

审查并执行删除，在 destroy 提示时输入 yes：

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

报告对象先于其存储桶被删除。查询剩余资源和空映射：

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

团队参考报告仍然保留。保存在本地的计划是审查产物；它们的存在不代表已删除的 AWS 资源仍然存在。

总结

你应用了已审查的原生计划产物，区分了就地更新与替换，通过 provider 读取观察了实际标签漂移，恢复了期望配置，并将报告数据保留到清理阶段。