企业官网建设流程全解析

1. 这不是又一个“云上点点鼠标”的活儿：Terraform 是怎么把服务器变成可版本管理的代码的？

你有没有过这种经历：凌晨两点，线上服务突然告警，排查发现是某台数据库服务器的磁盘 I/O 参数被悄悄改成了默认值；回滚配置后服务恢复，但没人记得是谁、什么时候、为什么改的；更糟的是，测试环境里压根没这台机器——它只存在于运维小哥的本地终端历史记录里。或者，新项目上线前，开发提了 7 个环境申请单：dev、staging、prod、canary、load-test、backup、demo……每个环境都要手动在控制台点 43 步，填 28 个字段，复制粘贴 5 次密钥，最后还得截图发邮件确认。三天后，有人问：“staging 环境的 Redis 密码是多少？”——没人知道，因为没人写下来，也没人管它和 dev 环境是不是一模一样。这就是传统基础设施管理的真实切片。而Terraform，就是那个把“点鼠标”变成“写代码”、把“口头约定”变成“版本快照”、把“人肉记忆”变成“Git 提交记录”的工具。它不属于某个云厂商，不绑定某套语言，它的核心就一句话：用声明式配置文件描述你想要的基础设施状态，然后由 Terraform 引擎自动规划、执行、并持续维护这个状态。关键词是“声明式”——你告诉它“我要 3 台 4 核 16G 的 Ubuntu 22.04 服务器，挂载一块 500G SSD，开放 22 和 80 端口”，而不是写一段 Shell 脚本去“先创建 VPC，再创建子网，再创建安全组，再创建实例，再关联弹性 IP……”。它解决的不是“怎么部署一台服务器”，而是“如何让 100 个工程师、5 个环境、3 家云厂商、2 年时间跨度里的每一次变更都可追溯、可复现、可审计、可回滚”。适合谁？不是只有 DevOps 工程师才需要。如果你是刚接手一个老项目的后端开发，想快速拉起一套本地可调试的完整依赖环境（MySQL + Redis + Kafka）；如果你是 SRE，每天要处理几十个“请帮我重置下测试集群”的工单；如果你是技术负责人，正为“为什么生产环境和预发环境行为不一致”这种问题头疼——那你已经站在了 Terraform 的门口。它不承诺让你一夜之间成为云架构大师，但它能立刻把你从“救火队员”变成“消防系统设计师”。

2. 为什么非得是 Terraform？不是 Ansible、不是 CloudFormation、不是自己写 Python 脚本？

选型从来不是比功能列表，而是比“谁最能扛住真实世界的混乱”。我带过三个不同规模的团队落地 IaC，踩过所有主流方案的坑，最终全站 Terraform，原因很实在，不是因为它多酷，而是因为它在几个关键生死线上，表现得足够“稳”。

2.1 声明式 vs. 命令式：一次写错，十年难愈的“状态漂移”

Ansible 是命令式的典型代表。你写一个 playbook：

- name: Create web server ec2: key_name: mykey instance_type: t3.medium image: ami-0c55b159cbfafe1f0 wait: yes count: 1

它执行完，服务器就起来了。但问题来了：如果第二天你手动登录服务器，apt update && apt upgrade -y，系统内核升级了；或者你忘了关掉某个调试端口，安全组规则被临时修改了；又或者，你直接在 AWS 控制台删掉了这台实例——Ansible 下次运行时，它只会“再创建一台”，而不会管“原来那台哪去了”、“现在这台和上次配置是否一致”。它没有“当前状态”的概念，只有“执行动作”的指令。久而久之，你的基础设施就变成了一个巨大的、无法描述的“黑盒”，我们叫它State Drift（状态漂移）。就像你有一份菜谱（Ansible Playbook），但厨师（人）经常凭感觉加盐、换火候、甚至偷吃一口，最后端上来的菜，和菜谱写的早已不是同一道。

Terraform 是声明式的。你写的是main.tf：

resource "aws_instance" "web" { ami = "ami-0c55b159cbfafe1f0" instance_type = "t3.medium" key_name = "mykey" tags = { Name = "web-server" } }

Terraform 会做三件事：第一，读取你这份“理想蓝图”；第二，调用云 API，扫描当前真实环境，生成一份“现状快照”；第三，对比蓝图和快照，自动计算出“最小变更集”——比如“删除旧实例 A，创建新实例 B，更新标签”。它永远以“最终状态”为目标，而不是“执行步骤”。这意味着，哪怕你手贱在控制台删了资源，只要terraform apply一下，它立刻给你补回来，且保证和蓝图一模一样。这不是魔法，这是对“确定性”的极致追求。

2.2 多云抽象层：别再为每家云写一套“方言”了

AWS 有 CloudFormation，Azure 有 ARM Templates，GCP 有 Deployment Manager。它们都很好，但全是“方言”。你为 AWS 写了一套完整的 VPC、EKS 集群、RDS 实例的模板，想迁移到 Azure？对不起，重写。不是语法差异，是底层模型差异：AWS 的 Security Group 是无状态的入站/出站规则集合，Azure 的 NSG 是有状态的，规则优先级逻辑完全不同；AWS 的 Load Balancer 分 ALB/NLB/GLB，Azure 只有 Standard/Basic 两种 SKU，转发逻辑、健康检查机制、计费模型全不一样。自己写 Python 脚本调 SDK？恭喜你，成功把自己变成了一个“云厂商适配器开发工程师”，90% 的精力花在处理各家 API 的奇技淫巧上，比如 AWS 的describe_instances返回的是Reservations数组套Instances数组，而 GCP 的list接口直接返回instances列表，连 JSON 结构都不统一。

Terraform 的解法是Provider 模型。它把云厂商的 SDK 封装成一个个 Provider 插件（aws,azurerm,google,alicloud,vsphere, 甚至docker,kubernetes,github）。你写的 HCL 代码，是面向 Terraform 自己的、统一的资源抽象模型（Resource Model）。aws_instance、azurerm_linux_virtual_machine、google_compute_instance，它们在 Terraform 的世界里，共享同一套生命周期语义（Create/Read/Update/Delete）、同一套状态管理机制、同一套变量注入方式。你只需要在provider块里声明用哪个云，其余代码几乎可以 100% 复用。我去年帮一家出海电商做双云容灾，主站跑 AWS，灾备站跑阿里云。核心的vpc,subnet,rds_cluster,ecs_service模块，HCL 代码共用率高达 92%，差异只在 provider 配置和极少数云特有参数（如阿里云的zone_id）。这省下的不是几周开发时间，而是避免了两套完全独立、极易产生差异的基础设施代码库。

2.3 状态（State）是灵魂，也是地雷：Terraform 怎么管好它的“记忆”

Terraform 最常被误解、也最致命的一点，就是它的State 文件。很多人第一次terraform init后，看到本地生成了一个terraform.tfstate，就以为“哦，这就是我的配置备份”。大错特错。.tfstate不是备份，它是 Terraform 的唯一真相源（Source of Truth），是它大脑里的“工作记忆”。里面存着所有已创建资源的 ID、属性、依赖关系。当你terraform apply时，它不是去云上重新扫描一遍，而是直接读取.tfstate，对比你新写的 HCL，算出差异。所以，如果.tfstate文件丢了、损坏了、或者被多人同时编辑冲突了，Terraform 就彻底“失忆”了——它不知道哪些资源是它创建的，哪些是你手动建的，下次apply可能会把生产数据库给删了。

这就是为什么terraform init后的第一件事，必须是远程后端（Remote Backend）配置。绝不能让它把 state 存在本地。我们团队强制使用s3+dynamodb组合（AWS 场景）：

terraform { backend "s3" { bucket = "my-company-tfstate-prod" key = "global/terraform.tfstate" region = "us-east-1" dynamodb_table = "my-company-tfstate-lock" } }

S3 存储 state 文件本身，DynamoDB 提供分布式锁（Locking），确保同一时刻只有一个terraform apply能修改 state，彻底杜绝并发冲突。这个表不是可选的，是必须的。我见过太多团队，初期图省事用本地 state，结果三人协作时，Aapply了，Bapply了，Capply了，最后 state 文件里只剩 C 的记录，A 和 B 创建的资源，在 Terraform 眼里“从未存在过”，成了真正的“幽灵资源”。修复代价远超重写。所以，Terraform 的选型优势，一半在它的声明式引擎，另一半，就在它对 state 这个核心资产，提供了工业级的、开箱即用的管理方案。

3. 从零开始：5 分钟亲手造出你的第一个“云上服务器”，并理解每一步在干什么

别被“Infrastructure as Code”这个词吓住。它本质上就是写配置文件 + 运行一个命令。下面，我带你亲手走一遍最简路径，目标：在 AWS 上创建一台 EC2 实例，并通过 SSH 连上去。全程不跳过任何一个“为什么”，你会明白每个文件、每个命令背后的真实意图。

3.1 准备工作：不是安装软件，而是建立信任链

第一步，永远不是curl -O https://releases.hashicorp.com/terraform/...。而是建立你和云厂商之间的身份信任。Terraform 本身不存储任何云账号密码，它需要你提供凭证，才能调用云 API。AWS 的标准做法是使用IAM 用户 + Access Key。

提示：绝对不要用 Root 账号的 AKSK！创建一个专用的 IAM 用户，只赋予它AmazonEC2FullAccess和AmazonS3FullAccess（用于 state 存储）权限。把生成的Access Key ID和Secret Access Key记下来。这是你给 Terraform 的“门禁卡”。

第二步，安装 Terraform。Mac 用户brew tap hashicorp/tap && brew install hashicorp/tap/terraform；Windows 用户用 Chocolateychoco install terraform；Linux 用户下载二进制包解压到/usr/local/bin。验证：terraform version，输出类似Terraform v1.6.6即可。

第三步，初始化项目目录。新建一个空文件夹my-first-ec2，进入它。记住，Terraform 的一切，都围绕这个目录展开。它没有全局配置，所有状态、插件、缓存，都默认在这个目录下。

3.2 编写你的第一份“基础设施蓝图”：main.tf

在my-first-ec2目录下，创建文件main.tf。内容如下：

# 1. 声明你要用的云提供商（Provider） terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" # 锁定大版本，避免意外升级破坏兼容性 } } } # 2. 配置 AWS Provider，告诉 Terraform 你的“门禁卡”在哪 provider "aws" { region = "us-east-1" # 选择一个你有权限的区域 # 凭证来源：优先级为 环境变量 > shared credentials file > EC2 Instance Profile # 我们推荐用环境变量，最安全，且不污染代码 } # 3. 定义你要创建的资源：一台 EC2 实例 resource "aws_instance" "example" { ami = "ami-0c55b159cbfafe1f0" # Ubuntu 22.04 LTS (us-east-1) instance_type = "t2.micro" # 免费套餐可用 key_name = "my-key-pair" # 你提前在 AWS 控制台创建的密钥对名称 # 4. 关键：定义安全组，控制网络访问 vpc_security_group_ids = [aws_security_group.allow_ssh.id] # 5. 标签，方便识别和管理 tags = { Name = "my-first-terraform-instance" } } # 6. 定义安全组：只允许 SSH (22) 端口入站 resource "aws_security_group" "allow_ssh" { name = "allow-ssh" description = "Allow SSH inbound traffic" vpc_id = aws_vpc.main.id ingress { description = "SSH from anywhere" from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] # 注意：生产环境绝不能这样写！ } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } } # 7. 定义 VPC：所有资源必须在 VPC 内 resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" tags = { Name = "terraform-vpc" } } # 8. 定义子网：VPC 内的逻辑分区 resource "aws_subnet" "main" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" map_public_ip_on_launch = true # 让实例自动获取公网 IP availability_zone = "us-east-1a" tags = { Name = "terraform-subnet" } }

这段代码里，藏着几个必须理解的“为什么”：

• Provider 声明是必须的：Terraform 是插件化的，不声明aws，它根本不知道aws_instance是什么。source指向 HashiCorp 官方仓库，version锁定大版本，防止terraform init时自动拉取不兼容的新版 Provider（比如 v6.x 可能废弃了某些参数）。
• provider "aws"块里没写 AKSK：这是最佳实践。凭证应该通过环境变量注入，而不是硬编码在代码里（git commit就等于泄露密码）。执行export AWS_ACCESS_KEY_ID=your_key_here和export AWS_SECRET_ACCESS_KEY=your_secret_here即可。Terraform 会自动读取。
• 资源间有隐式依赖：aws_instance.example用到了aws_security_group.allow_ssh.id，而aws_security_group.allow_ssh又用到了aws_vpc.main.id。Terraform 会自动解析这些依赖关系，决定创建顺序：先 VPC，再子网，再安全组，最后实例。你不需要写depends_on（除非有循环依赖等特殊情况）。
• cidr_blocks = ["0.0.0.0/0"]是危险的：它意味着“允许全世界任何人 SSH 连接”。这只是为了演示。生产环境必须严格限制，比如只允许公司办公网 IP 段或堡垒机 IP。

3.3 执行三部曲：init→plan→apply，像外科手术一样精准

现在，目录结构是这样的：

my-first-ec2/ ├── main.tf

打开终端，进入该目录，执行：

第一步：terraform init

terraform init

这是“奠基仪式”。Terraform 会：

• 下载hashicorp/awsProvider 插件（v5.x）到.terraform/plugins/目录；
• 初始化工作目录，创建.terraform/隐藏文件夹，存放所有元数据；
• 如果你配置了远程后端（我们还没配），它会连接 S3 并准备 state 文件。

注意：init只需执行一次，或者当required_providers改变、或你更换了后端配置时才需要重做。它不碰你的云资源，纯本地操作。

第二步：terraform plan

terraform plan

这是“术前会诊”。Terraform 会：

• 读取main.tf，构建你的“理想蓝图”；
• 调用 AWS API，扫描当前us-east-1区域，生成“现状快照”（此时快照为空，因为你还没创建任何东西）；
• 对比蓝图和快照，计算出“要做的动作”；
• 输出一个彩色的、人类可读的执行计划。

你会看到类似这样的输出：

Terraform will perform the following actions: # aws_instance.example will be created + resource "aws_instance" "example" { + ami = "ami-0c55b159cbfafe1f0" + instance_type = "t2.micro" + key_name = "my-key-pair" # ... 其他 50+ 行属性 ... } # aws_security_group.allow_ssh will be created + resource "aws_security_group" "allow_ssh" { + name = "allow-ssh" + description = "Allow SSH inbound traffic" # ... } Plan: 4 to add, 0 to change, 0 to destroy.

plan是 Terraform 的灵魂所在。它让你在真正动手前，100% 确认“它要干什么”。你可以把它保存成文件terraform plan -out=tfplan，然后terraform apply tfplan来执行，确保计划和执行完全一致。这是防止误操作的终极保险。

第三步：terraform apply

terraform apply

这是“手术执行”。Terraform 会：

• 再次运行plan（确保自上次plan后没有其他人改动了 state 或云环境）；
• 询问你Do you want to perform these actions?，输入yes确认；
• 按照计算出的顺序（VPC → 子网 → 安全组 → 实例），依次调用 AWS API 创建资源；
• 成功后，将所有新创建资源的 ID、属性等信息，写入terraform.tfstate（默认本地）。

整个过程大约 2-3 分钟。完成后，你可以在 AWS 控制台EC2 → Instances页面，看到一台状态为running的新实例，名字是my-first-terraform-instance。恭喜，你的第一行“基础设施代码”已经成功运行！

3.4 验证与清理：理解state的力量与责任

验证：找到实例的Public IPv4 address，用你的私钥（.pem文件）尝试 SSH：

ssh -i /path/to/my-key-pair.pem ubuntu@<public-ip>

如果成功登录，说明一切正常。你创建的是一台 Ubuntu 服务器，用户是ubuntu。

清理：为了不产生费用，执行：

terraform destroy

它会读取terraform.tfstate，知道哪些资源是它创建的，然后按逆序（实例 → 安全组 → 子网 → VPC）逐一销毁。再次确认yes，几秒钟后，所有资源消失。terraform.tfstate文件也会被清空（或标记为已销毁）。

注意：destroy是不可逆的。它会删除state中记录的所有资源。所以，state文件的安全，就是你基础设施的安全。这也是为什么远程后端是强制要求。

4. 超越“Hello World”：模块化、变量、远程 State，构建可维护的生产级代码

写完main.tf创建一台服务器，只是万里长征第一步。真实项目里，你面对的是几十个服务、上百个资源、多个环境（dev/staging/prod）、多个团队协作。如果所有代码都堆在一个main.tf里，不出三个月，它就会变成一个谁都看不懂、谁都不敢动的“意大利面条”。

4.1 变量（Variables）：把“写死的字符串”变成“可配置的开关”

看回main.tf，里面到处是硬编码：

• region = "us-east-1"
• ami = "ami-0c55b159cbfafe1f0"
• instance_type = "t2.micro"
• key_name = "my-key-pair"

这显然不行。Dev 环境用t2.micro，Prod 环境要用m5.2xlarge；Staging 用 Ubuntu，Prod 可能要用 Amazon Linux 2；Key Pair 名字在不同环境也不同。解决方案：变量（Variables）。

在my-first-ec2目录下，创建variables.tf：

variable "region" { description = "The AWS Region to deploy resources" type = string default = "us-east-1" } variable "ami_id" { description = "The AMI ID for the EC2 instance" type = string # no default! This forces the user to provide it } variable "instance_type" { description = "The EC2 instance type" type = string default = "t2.micro" } variable "key_name" { description = "The name of the EC2 Key Pair" type = string }

然后，修改main.tf，把所有硬编码替换成var.xxx：

provider "aws" { region = var.region } resource "aws_instance" "example" { ami = var.ami_id instance_type = var.instance_type key_name = var.key_name # ... rest unchanged }

现在，terraform apply会提示你输入ami_id和key_name。更好的方式是创建terraform.tfvars文件：

# terraform.tfvars ami_id = "ami-0c55b159cbfafe1f0" key_name = "my-key-pair"

Terraform 会自动加载同名的.tfvars文件。你还可以用-var-file=prod.tfvars指定不同环境的变量文件。变量让代码具备了“一次编写，多处部署”的能力。

4.2 模块（Modules）：把“重复造轮子”变成“搭积木”

假设你不仅要创建 Web 服务器，还要创建数据库、缓存、负载均衡器。如果每个都像main.tf那样写一遍，VPC、子网、安全组的代码会复制粘贴 5 遍，稍有不慎，一个地方改了，其他地方没同步，环境就不一致了。

Terraform 的答案是模块（Modules）。模块就是一个封装好的、可复用的代码包。你可以把 VPC 的创建逻辑，封装成一个modules/vpc目录；把 RDS 实例的创建逻辑，封装成modules/rds。

创建modules/vpc/main.tf：

# modules/vpc/main.tf resource "aws_vpc" "this" { cidr_block = var.cidr_block tags = { Name = var.name } } resource "aws_subnet" "this" { count = length(var.azs) vpc_id = aws_vpc.this.id cidr_block = element(var.subnet_cidrs, count.index) availability_zone = element(var.azs, count.index) map_public_ip_on_launch = var.map_public_ip_on_launch tags = { Name = "${var.name}-subnet-${count.index}" } }

创建modules/vpc/variables.tf：

variable "cidr_block" { type = string } variable "name" { type = string } variable "azs" { type = list(string) } variable "subnet_cidrs" { type = list(string) } variable "map_public_ip_on_launch" { type = bool }

然后，在你的主main.tf里，直接调用这个模块：

module "vpc" { source = "./modules/vpc" cidr_block = "10.0.0.0/16" name = "my-app-vpc" azs = ["us-east-1a", "us-east-1b"] subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"] map_public_ip_on_launch = true } # 现在，你可以用 module.vpc.vpc_id 来引用创建好的 VPC ID resource "aws_instance" "web" { # ... vpc_security_group_ids = [aws_security_group.web.id] } resource "aws_security_group" "web" { vpc_id = module.vpc.vpc_id # 关键：跨模块引用 # ... }

模块化带来了三大好处：复用性（一个 VPC 模块，Web、DB、Cache 都能用）、一致性（所有环境的 VPC 都来自同一份代码）、可维护性（VPC 逻辑有 Bug，只改modules/vpc一处，所有调用者自动受益）。

4.3 远程 State：让团队协作不再是一场灾难

前面提到，terraform.tfstate必须存远程。现在，我们来实战配置它。回到main.tf，修改terraform块：

terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } # 新增：远程后端配置 backend "s3" { bucket = "my-company-tfstate-prod" # 替换为你自己的 S3 桶名 key = "global/terraform.tfstate" # state 文件在桶内的路径 region = "us-east-1" dynamodb_table = "my-company-tfstate-lock" # DynamoDB 表名，必须提前创建 } }

关键步骤：

1. 创建 S3 桶：在 AWS 控制台，创建一个名为my-company-tfstate-prod的桶。务必开启版本控制（Versioning）。这是防止误删 state 的最后一道防线。
2. 创建 DynamoDB 表：创建一个名为my-company-tfstate-lock的表，主键为LockID（String 类型）。Terraform 会用它来加锁。
3. 赋予 IAM 权限：确保你用来运行 Terraform 的 IAM 用户，拥有对这个 S3 桶的s3:GetObject,s3:PutObject,s3:ListBucket,s3:DeleteObject权限，以及对 DynamoDB 表的dynamodb:GetItem,dynamodb:PutItem,dynamodb:DeleteItem权限。

配置好后，执行terraform init。Terraform 会提示：

Do you want to copy existing state to the new backend? Pre-existing state was found while migrating the previous "local" backend to the newly configured "s3" backend. No existing state was found in the newly configured "s3" backend. Do you want to copy this state to the new "s3" backend? Enter "yes" to copy and "no" to start with an empty state.

输入yes。它会把本地的terraform.tfstate上传到 S3。从此，所有团队成员，只要拥有正确的 IAM 权限，运行terraform apply，都会操作同一个、受保护的 state 文件。协作变得安全、有序、可审计。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

Terraform 学习曲线平缓，但有几个“坑”，几乎每个新手都会踩，而且踩得非常疼。我把它们整理成速查表，并附上我亲测有效的排查思路。

5.1 “Error: No valid credential sources found for AWS Provider” —— 凭证失效的 10 种可能

这是terraform plan或apply时最常遇到的报错。意思是 Terraform 找不到 AWS 凭证。别急着重装，按顺序排查：

实操心得：我给自己写了一个tf-env.sh脚本，每次进入 Terraform 项目目录，就source tf-env.sh。它会检查环境变量、打印当前 region、并运行aws sts get-caller-identity验证凭证。这让我在 5 秒内就能确认凭证环节是否 OK，省下大量无效排查时间。

5.2 “Error: Error running plan: 1 error(s) occurred” —— 状态文件损坏的急救指南

当terraform plan报错，且错误信息里包含state、lock、corrupted等关键词，基本可以断定是 state 文件出了问题。常见场景：terraform apply执行到一半被 Ctrl+C 中断；多人同时apply导致 DynamoDB 锁未释放；S3 桶权限配置错误导致写入失败。

急救三步法：

1. 检查锁状态：首先，去 DynamoDB 控制台，找到你的my-company-tfstate-lock表，搜索LockID为global/terraform.tfstate的记录。如果Status是locked，且Who字段显示是某个已终止的进程，手动删除这条记录。这是最常见、最安全的解法。
2. 强制解锁（慎用）：如果第一步无效，或者你找不到 DynamoDB 表，可以尝试terraform force-unlock <LOCK_ID>。LOCK_ID就是上一步查到的LockID值。警告：此操作有风险，仅在确认无人正在操作时使用。
3. State 文件修复（终极手段）：如果 state 文件本身损坏（比如 S3 上的文件是空的、或 JSON 格式错误），你需要terraform state pull > backup.tfstate先备份当前（可能损坏的）state，然后terraform state rm aws_instance.example删除损坏的资源记录，最后terraform import aws_instance.example i-1234567890abcdef0用import命令，把现实中存在的资源“重新导入”到 state 中。import是一个精细活，需要你准确知道资源的云上 ID（如 EC2 实例 IDi-xxx），并且要确保 HCL 代码和现实资源的属性完全匹配，否则后续apply会出错。

实操心得：State 是心脏，备份是生命线。我们团队的 SOP 是：每次重大apply前，terraform state pull > state-before-$(date +%Y%m%d-%H%M%S).json；每次apply后，terraform state pull > state-after-$(date +%Y%m%d-%H%M%S).json。这些文件都存