🚀 Terraform 第6天：构建专业的 Terraform 项目结构

Source: Dev.to

为什么要组织 Terraform 文件？

初学者常常把所有内容放在一个文件里：

• Providers（提供者）
• Resources（资源）
• Variables（变量）
• Outputs（输出）
• Backend（后端）
• Locals（本地值）

这只适用于非常小的项目。随着基础设施的增长，单个文件会变得：

• ❌ 难以阅读
• ❌ 难以更新
• ❌ 容易出错
• ❌ 不利于团队协作
• ❌ 无法扩展

第 6 天引入了多文件的做法，为后续的模块、环境和可复用基础设施等概念奠定基础。

推荐的 Terraform 项目结构

Terraform 会自动加载所有 .tf 文件，不论文件名如何。一个清晰的结构如下：

project/
├── main.tf          # resources
├── variables.tf     # input variables
├── outputs.tf       # output declarations
├── providers.tf     # provider configuration (AWS, etc.)
├── backend.tf       # remote backend configuration
├── locals.tf        # local reusable values
├── .gitignore       # exclude sensitive/state files
└── terraform.tfvars # default variable values (optional)

关键点
Terraform 并不在乎文件的顺序或名称——它会在内部将所有内容合并。上述命名约定是为了可读性和协作的最佳实践。

实践：拆分 Terraform 文件

在第 6 天的示例项目中，讲师演示了如何将配置移动到专门的文件中。

backend.tf

terraform {
  backend "s3" {
    bucket = "my-terraform-backend"
    key    = "dev/terraform.tfstate"
    region = "us-east-1"
  }
}

providers.tf

provider "aws" {
  region = var.region
}

• 输入变量 → variables.tf
• 本地值 → locals.tf
• 输出 → outputs.tf
• 资源 → main.tf

这种分离让项目更整洁，错误也更容易定位。

为项目加固：创建 .gitignore

切勿将 Terraform 状态文件或 .terraform 目录提交到 GitHub。

.gitignore

.terraform/
terraform.tfstate
terraform.tfstate.backup
crash.log
*.tfvars

为什么？

• 状态文件包含敏感信息。
• .terraform 文件夹存放插件和不必要的元数据。
• 备份文件和崩溃日志可能泄露内部细节。

将这些内容排除在版本控制之外，对安全和保持仓库历史整洁至关重要。

为真实项目做规划：超出基础的做法

1. 环境文件夹

environments/
├── dev/
├── stage/
└── prod/

每个环境可以拥有自己的 main.tf、variables.tf、terraform.tfvars 和后端配置。

2. 基于模块的结构

modules/
├── networking/
├── compute/
└── security/

模块有助于复用，但需要更深入的理解——后续挑战中会涉及。

3. 单一代码库配合多个 tfvars

terraform apply -var-file=dev.tfvars
terraform apply -var-file=prod.tfvars

这种方式为企业级部署提供了最大的灵活性。初学者应先掌握文件分离，再深入模块化。

结论

第 6 天改变了我对 Terraform 项目的思考方式。摆脱了单一凌乱的文件后，我现在懂得：

• 如何正确组织 Terraform
• 如何保护敏感数据
• 如何为多环境准备
• 如何向专业、模块化的基础设施扩展

这种结构将成为后续所有内容的支柱。

明天： Terraform 类型约束 — 确保变量得到验证并可靠。 🚀