从网上听说的原理

terraform 就是将实际的云资源状态和定义的云资源状态保持一致性

我思考后的原理

terraform 会将所有自己所管理的资源放在 terraform.state 文件里（或者其它 backend ）
不在 state 文件里的资源就不在 terraform 管理的 scope
terraform plan 和 apply 会将定义的文件和 state 文件里的差异体现出来，也就是 state 文件会参照定义的 tf 文件对实际的云资源做变更
terraform destroy 只会删除 state 文件里的云资源，如果你不想让一个云资源被删除使用如下命令 terraform state rm ...
如果一个云资源真实存在，但是 state 文件没有，tf 文件里面定义了，那么执行terraform apply会创建这个资源，但是会报错，会提示你使用terraform import导入已经存在的资源

总结就是，terraform 工作流程首先对比 tf 文件和 state 文件，state 文件表示现在的云资源的状态，然后对标 tf 文件对实际云资源进行增删改，完事儿之后把状态更新到 state 文件里

第 1 条附言 · 135 天前

结合 GPT 多了一些思考

terraform 的核心是三个文件，
1. 一个是开发者自己定义的 tf 文件
2. 第二个是.tfstate 文件
3. 第三个是云资源的真实状态

首先读取.tf 文件配置确认期望状态，然后读取 tfstate 文件中的当前状态(.tf 有，.tfstate 没有，那么会创建；.tf 没有,.tfstate 有，那么会删除)，这个时候还没有真正开始操作

然后通过 provider 获取真实的资源状态（这里获取真实资源状态，那么获取哪些资源呢，scope 是什么，scope 就是.state 文件里的 “资源对象+对象名”，以这个作为标识符，不在 tfstate 里面的 terraform 会认为资源不存在，并且按照.tf 定义的进行执行）

这里读取的.tfstate ，我认为主要就是看看上一次受 terraform 管理的资源 scope

然后进行比较

比较什么呢，
简化理解：
A （以 state 文件里面的内容为 scope ，通过 provider 从远程真实云资源状态获取信息）
B （.tf 文件的定义状态）

看看 A 是否和 B 定义的一样

这里有个问题，因为 A 的数据很全，有些属性是创建后才知道的，B 都是人员自己定义的，没有那么全
有些情况就算你什么都没变，后面再次 terraform apply 时候会发现如下这些

- identity {
- identity_ids = [] -> null
- principal_id = "xxxxxxxxxxx" -> null
- tenant_id = "xxxxxxxxxxx" -> null
- type = "xxxxxxxxxxx" -> null
}

# (4 unchanged blocks hidden)
}

这是因为 B 定义的没有，A 里面有，所以要改成 null

--------------

下面是 chatgpt 回答

1. 期望状态：
• Terraform 解析 main.tf ，期望有一个 AMI ID 为 ami-0c55b159cbfafe1f0 的 t2.micro 实例。
2. 当前状态：
• Terraform 读取 .tfstate 文件，假设当前状态文件记录了一个 t2.micro 实例，AMI ID 为 ami-0c55b159cbfafe1f0 。
3. 真实状态：
• Terraform 通过 AWS 提供者插件调用 AWS API 获取实际的实例信息。如果在 AWS 控制台中手动删除了该实例，AWS 提供者插件将返回实例不存在的信息。
4. 比较：
• Terraform 发现期望状态与真实状态不一致（实例已被删除），于是它决定创建一个新的实例。
5. 执行计划：
• Terraform 执行计划，创建一个新的 t2.micro 实例，AMI ID 为 ami-0c55b159cbfafe1f0 。
6. 更新状态文件：
• Terraform 更新 .tfstate 文件，记录新创建的实例信息。

目前尚无回复

terraform 原理的一点儿思考

从网上听说的原理

我思考后的原理