将现有资源纳入管理

介绍

你正在接手一个正常使用中的报告存储桶，它是在 Terraform 之外创建的。你需要将其纳入管理，不能重新创建存储桶或重写其中的报告。随后，审查并应用一项小幅配置调整，同时保持财务团队的相邻存储不变。

你应已了解 Terraform 配置、资源地址、init、plan、apply 和本地状态，以及基本的 S3 对象操作。此全新环境已准备好 Terraform、AWS Provider、访问配置和两个独立的报告存储桶。无需个人 AWS 账户，也不依赖之前实验中的资源。

与认证考试的关联

实验概览

检查现有存储和期望配置

在这一步中，比较 AWS 中已存在的资源与你即将管理的配置。Terminal 上方的 AWS View 显示与你通过 CLI 读取的相同 S3 资源。展开 handover-daily-reports 卡片中的 report.txt，查看报告数据；finance-reference-reports 属于另一个团队，必须保持不变。

Terraform 资源地址（例如 aws_s3_bucket.reports）标识一个配置块。存储桶名称标识远端的 AWS 资源。状态记录这两种标识之间的映射。仅有配置文件并不会建立该映射。

进入已准备好的根目录，阅读期望的存储桶配置：

cd /home/labex/project/report-storage
cat main.tf

bucket 参数选择 handover-daily-reports。Owner 必须保持为 reporting；新增的 ManagedBy 标签将记录此次交接。force_destroy = false 可防止 Terraform 在之后执行销毁时自动清空非空存储桶。这是 Terraform 的行为设置，与存储桶中保存的报告相互独立。

检查现有标签：

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

最初只有 Owner=reporting。将 - 作为目标位置，把原始报告读取到标准输出：

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

预期报告内容：

Daily sales: 120 orders

初始化工作目录。init 为此根目录安装固定版本的 Provider；它不会导入或创建存储桶：

terraform init

查看计划执行的操作，但不要应用：

terraform plan

计划显示 1 to add，因为此根目录尚无受管理资源的映射。存储桶已经存在；这说明状态中缺少管理映射，并不意味着可以替换该存储。不要应用这个创建计划。 下一步将显式建立映射。

继续之前，请手动确认你能识别报告存储桶、读取其中的报告，并将它与财务存储区分开来。本检查步骤的后台检查会验证预置资源是否保持不变，不会判断你是否理解了所显示的计划。

导入现有存储桶并审查差异

在这一步中，将现有存储桶映射到预期的 Terraform 地址。CLI 的 import 会读取远端资源，并在状态中记录其标识。它不会生成期望配置，也不会导入存储桶中的每个对象。

执行导入时，先指定配置地址，再指定现有存储桶名称：

terraform import aws_s3_bucket.reports handover-daily-reports

留意 Import successful!。验证现在哪个地址已纳入管理：

terraform state list

预期地址：

aws_s3_bucket.reports

读取其属性：

terraform state show aws_s3_bucket.reports

id 和 bucket 都应指向 handover-daily-reports。report.txt 仍存储在 S3 中；导入存储桶不会将该对象纳入独立的 aws_s3_object 地址进行管理。财务存储桶不得出现在此根目录的状态中。

导入并不保证马上得到没有变更的计划。一些设置来自远端服务；另一些设置（包括 force_destroy）描述 Terraform 自身的行为，导入后可能需要与配置对齐。这类差异不表示报告已损坏。

保存一个计划以供审查。-out=handover.tfplan 保存计划操作，使下一步可以应用同一份已审查的计划：

terraform plan -out=handover.tfplan

读取已保存的计划：

terraform show handover.tfplan

预期看到就地更新（~）、新增 ManagedBy=Terraform 标签，以及可能需要将 force_destroy 调整为 false。摘要必须为：

Plan: 0 to add, 1 to change, 0 to destroy.

如果计划提出删除、替换、创建、使用不同的存储桶名称，或更改财务存储，请停止并检查根目录、资源地址和导入 ID。不要通过删除现有报告来解决意外的计划。

应用配置调整并确认资源保留

在这一步中，仅应用你已审查的计划，并证明原始报告得以保留。向 apply 提供已保存的计划会直接执行该计划，不会再次提示批准。只有确认上一步摘要中的创建数和销毁数均为零后，才能运行：

terraform apply handover.tfplan

预期看到 Resources: 0 added, 1 changed, 0 destroyed.。存储桶现已纳入管理，交接标签也已与配置一致。

读取当前标签，验证 AWS 中的结果：

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

应同时存在 Owner=reporting 和 ManagedBy=Terraform；标签顺序不重要。

再次读取报告：

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

报告必须仍包含 Daily sales: 120 orders。在 AWS View 中，展开两份报告，确认报告内容和财务参考报告仍可访问。调整标签不需要新建存储桶或重写对象。

检查当前配置、状态与刷新后的 AWS 资源是否收敛：

terraform plan

预期结果：

No changes. Your infrastructure matches the configuration.

仅凭没有变更的计划不足以证明交接安全：你还检查了预期资源地址和原始数据；后台检查则会比较原始对象版本和相邻存储，并在一次性副本中对当前配置生成计划，以确认已收敛。此次交接需保留两个存储桶。不要运行 terraform destroy：报告仍在使用中。在实际交接中，应将状态作为敏感运维数据加以保护，并为下一位维护者安排访问权限；不要将状态或包含敏感值的已保存计划提交到公共仓库。

如需更多背景信息，请参阅 HashiCorp 的 CLI 导入工作流。

总结

你比较了现有存储桶与 Terraform 配置，将其标识导入到预期的状态地址，并在应用前审查了一项不会造成破坏的配置调整。你确认了计划没有变更，同时保留了原始报告和财务存储。导入负责建立管理关系；配置审查则决定 Terraform 接下来应更改哪些内容。