Terraform Provider中resources与data sources区别及适用场景

核心差异 #

• 生命周期管控权限不同：resource 声明的对象由当前Terraform栈全权管理，从创建、配置更新到删除销毁的全流程操作都由Terraform执行，执行terraform destroy时这类资源会被同步清理。data 声明的对象Terraform只有读取权限，仅会拉取已经存在的资源的属性信息，不会对资源本身做任何增删改操作，哪怕销毁当前栈也不会影响这类对象。
• 配置目的不同：编写resource块是为了声明需要从无到有创建的新资源，告诉Terraform你要交付的基础设施目标状态；编写data块是为了查询已有资源的属性值，供当前栈的其他配置引用，不会生成新的基础设施对象。
• 状态管理逻辑不同：resource的全量配置、与云平台实际资源的映射关系会完整持久化到当前栈的state文件中，每次执行plan都会比对配置与实际资源的差异，存在偏差就会触发更新动作。data仅会将每次查询到的结果临时存入state，即使查询到的属性与历史值有差异，也不会触发对该对象本身的修改。

适用场景举例 #

Resources 适用场景 #

所有需要纳入当前Terraform栈全生命周期管理的全新基础设施，都用resource块声明。
最典型的场景是新业务线从零搭建云上资源：你需要申请全新的弹性公网IP（EIP），并绑定到自己新创建的EC2实例上，这时候EIP、EIP绑定关系都属于当前栈管控的资源，配置示例如下：

# 申请全新的弹性公网IP
resource "aws_eip" "biz_server_eip" {
  domain = "vpc"
  tags = {
    Name = "业务线专属公网IP"
  }
}

# 创建EIP与EC2实例的绑定关系
resource "aws_eip_association" "eip_bind" {
  instance_id   = aws_instance.biz_server.id
  allocation_id = aws_eip.biz_server_eip.id
}

这类场景的共性是：

• 资源需要从无到有新建，之前不存在
• 后续资源的配置变更、缩扩容、下线销毁都跟随当前业务栈的生命周期走
• 你对这类资源拥有完整的操作权限

Data Sources 适用场景 #

所有不需要当前栈创建、仅需要读取属性做关联的已有资源，都用data块查询。
最典型的场景是中大型企业的公共资源复用：网络团队提前统一创建了全公司共用的VPC、安全组，以及一批完成备案的固定EIP，这些资源归网络团队的Terraform栈管控，业务线没有修改、删除权限，只需要引用即可。这时候你不需要重复创建EIP，只需要查询到已有EIP的ID，绑定到自己管理的EC2实例上，配置示例如下：

# 查询网络团队提前交付的固定公网IP对应的EIP信息
data "aws_eip" "existing_company_eip" {
  public_ip = "43.xxx.xxx.xxx" # 公司统一分配的已备案公网IP
}

# 创建EIP与当前栈管理的EC2实例的绑定关系
resource "aws_eip_association" "bind_existing_eip" {
  instance_id   = aws_instance.biz_server.id
  allocation_id = data.aws_eip.existing_company_eip.id # 引用data查询到的EIP ID
}

这类场景的共性是：

• 资源已经存在，归属其他团队、其他Terraform栈管理，或是云厂商提供的公共资源
• 你不需要、也没有权限对这类资源做修改、删除操作，仅需要获取它的属性做配置关联
• 常见的查询对象包括：公共VPC/子网信息、云平台官方提供的操作系统镜像ID、可用区列表、手动在控制台创建的不纳入栈管理的资源等

内容的提问来源于stack exchange，提问作者SAI VINIL