Data Sources 数据源与前置断言

这一课你将能做到

1. 用 data 块只读查询云上已有信息（当前账号、区域、AMI、托管策略、现有网络）
2. 用动态 AMI 查询替换写死的镜像 ID，让配置在任何区域自动取到正确镜像
3. 用 precondition / postcondition 在资源变更前后做跨对象断言

为什么要学

前面的 resource 解决「我要创建什么」，但 Terraform 还经常需要「读取我不拥有、不该由我创建的东西」：当前部署用的是哪个账号？Amazon Linux 最新 AMI 的 ID 是多少（AMI ID 每个区域不同、还频繁更新）？公司共享 VPC 的 ID？AWS 托管的 IAM 策略 ARN？这些都不是你要创建的资源，写一个 resource 去管它只会冲突。

data source 就是 Terraform 的「只读查询接口」：它什么都不创建、不修改，只把云平台的现有信息读进配置供引用。善用 data source，配置才不会到处是写死的 ID，跨区域、跨账号复用才真正成立。配合 1.2 引入的 preconditions，还能把「只有 prod 才能开删除保护」「镜像必须是我们自己账号的」这类规则固化下来。

先建立图像

resource：create / update / delete → 会改变世界
data    ：read only                → 只查询、零副作用、不入常规资源计数

一次 plan/apply 的求值顺序中，data 像「提前问云要答案」：

data "aws_ami" "al2023"  ──读──▶ AWS API ──▶ ami_id
                                        │
resource "aws_instance" "web" { ◀────────┘ 引用 data.aws_ami.al2023.id
  ami = data.aws_ami.al2023.id
}

跟着做

步骤 1：查询身份与区域——防止部署到错账号

最该放在每份配置开头的两个 data source：

data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

output "deploy_target" {
  value = {
    account_id = data.aws_caller_identity.current.account_id
    region     = data.aws_region.current.name
  }
}

它们不接受参数，读的是当前凭证实际连到的账号和区域。典型用途是配合断言（步骤 4）防止「拿着 prod 凭证对 dev 目录 apply」。

步骤 2：动态查 AMI——消灭写死的镜像 ID

把第 4、9 课写死的 AMI 替换掉：

data "aws_ami" "amazon_linux_2023" {
  most_recent = true
  owners      = ["amazon"]   # 只认 Amazon 官方账号，防止第三方冒名镜像

  filter {
    name   = "name"
    values = ["al2023-ami-2023.*-x86_64"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amazon_linux_2023.id
  instance_type = "t3.micro"

  tags = {
    Name      = "coderoadmap-web"
    AmiName   = data.aws_ami.amazon_linux_2023.name
  }
}

关键点：most_recent = true 取最新一个；owners = ["amazon"] 是安全必需——不限制 owner，别人可以发布同名镜像投毒。filter 的写法和 AWS CLI describe-images --filters 完全一致。现在这份配置不用改一个字符就能在任何区域拿到对的 AMI。

步骤 3：查询托管策略、共享网络与远程 state