Terraform 状态文件管理

Fri, 04 Sep 2026 16:08:53 +0800

1. 为什么要把 State 搬到「云上」

State 文件是 Terraform 的「账本」：它记录云上到底有哪些资源、各自的属性。本地存放 State 有三个硬伤：

绑定机器：State 在 A 电脑上，B 电脑 apply 就会"失忆"，容易把资源重建一遍。
无法协作：两个人同时改同一个环境，互相覆盖，状态文件乱套。
安全隐患：本地文件易丢，而且里面可能含有明文密码等敏感信息，因此也不建议上传到 gitlab 等代码托管平台。

解决办法就是 Terraform 的 Backend 机制：用阿里云 OSS 存 State（集中、加密、可回滚），用 Tablestore 提供加锁（防止多人并发操作冲突）。

2. 工作原理

每次执行 Terraform 命令，OSS Backend 都会走「加锁 → 干活 → 放锁」三步：

flowchart LR
A[terraform apply] --> B{从 Tablestore 拿 LockID}
B -- 已存在 --> C[报错：有人在操作]
B -- 不存在 --> D[生成并存入 LockID]
D --> E[读写 OSS 里的 State 文件]
E --> F[释放 LockID]

有锁 → 说明有人正在操作，或上次操作异常退出，直接报错
无锁 → 自动生成 LockID 存入 Tablestore，操作完成后更新 OSS 中的 State，再释放锁

3. 第一步：创建「存储 + 锁」资源

在正式使用前，要先准备一个 OSS Bucket 和一个 Tablestore 实例/表。它们本身也是云资源，所以也可以用 Terraform 自己建。

Terraform 云上存量资源导入

Thu, 03 Sep 2026 16:24:03 +0800

1. 为什么要"导入"云上资源？

很多团队都有这样的经历：最开始用控制台点几下、或者用 CLI 脚本把资源建好了，等资源越攒越多、想标准化管理时，发现这些资源"游离"在 Terraform 之外。

Terraform 的管理逻辑很简单：它只认自己 state 文件里记录的资源。你在控制台创建的资源，Terraform 根本"看不见"，也不会去动它们。所以要把存量资源管起来，第一步就是"导入"（import）——把云上已有的资源登记进 Terraform 的 state，再补上对应的配置代码。

导入成功后，这些资源和 Terraform 新建的资源享受完全一样的待遇：能 plan、能 apply、能 diff、能进 CI/CD。

2. 先搞清楚两个概念：config 和 state

这是最容易绕晕的地方，务必先分清：

概念	是什么	谁来写
`.tf` 配置（config）	声明"想要什么"，是给人看的声明式代码	手写，或工具自动生成
`terraform.tfstate`（state）	记录"现在实际是什么"，含真实属性（可能有敏感信息）	由 apply / import 自动生成

关键点：

导入只会写 state，不会自动写 config（除非你用 -generate-config-out 或 Terraformer）。
所以完整流程 = 导入进 state + 补齐 config + plan 核对一致，三步缺一不可。
state 含敏感信息，永远不要提交到 git（后面最佳实践会讲远程存储）。

整体流程可以先看这张图：

flowchart TD
A[盘点存量资源: 类型 / ID / 地域] --> B[环境准备: Terraform + provider + RAM 凭证]
B --> C{资源量多少?}
C -->|少| D[import block / terraform import]
C -->|多| E[aliterraformer 批量导入]
D --> F[生成 config + state]
E --> F
F --> G[terraform plan 核对无漂移]
G --> H[清理只读属性 + 纳入 git + OSS 远程 state]

3. 三种导入方式怎么选

阿里云官方文档提供了三种方式，直接放对比表：

Cloud on 维克的博客