GitLab CI 集成 Terraform 的核心是构建可触发、预览、审批与回滚的标准化流水线，需配置远程后端（如 S3 + DynamoDB）统一状态并启用锁机制，分 validate→plan→apply 三阶段控制变更，按环境分层组织代码，结合安全校验与自动化测试保障合规。
GitLab CI 集成 Terraform 实现资源部署，核心是把基础设施变更变成可触发、可预览、可审批、可回滚的标准化流水线。不是简单跑几条命令，而是建立一套带状态保护、环境隔离和人工卡点的交付机制。
用远程后端统一管理状态
本地执行 terraform apply 会把 state 写在本地，多人协作极易冲突或丢失。必须配置远程后端（如 AWS S3 + DynamoDB 或 Azure Storage + Blob），让所有流水线共享同一份权威状态，并启用锁机制防止并发写入。
- S3 后端示例：在
backend.tf中声明 bucket、key、region 和 dynamodb_table（用于锁） - GitLab CI 变量中安全注入
AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY，避免硬编码 - 每次
terraform init自动拉取最新 state，确保 plan 基于真实现状
分三阶段流水线控制变更节奏
不建议直接 auto-apply。标准做法是拆成 validate → plan → apply 三个 stage，每个 stage 有明确职责和准入条件。
- validate：检查语法、变量定义、provider 配置是否合法，失败即阻断后续流程
-
plan：生成变更计划（JSON 格式），保存为 artifact 供人工审查；可加
terraform show -json planfile提取关键变更摘要 -
apply：仅在 main 分支或通过 MR approval 后触发，且需手动确认（GitLab 的
when: manual）
按环境分层组织代码与流水线
开发、测试、生产不能共用同一套 tf 文件。推荐用目录隔离 + 变量注入方式实现环境复用：
- 结构示例：
environments/dev/、environments/prod/，每个目录含main.tf和terraform.tfvars - CI job 中通过
cd environments/$CI_ENVIRONMENT_NAME切换上下文，配合TF_VAR_env=$CI_ENVIRONMENT_NAME注入变量 - GitLab 的 environment 功能可自动标记部署记录，关联到具体分支或 tag
加一道安全校验和自动化测试
光靠 plan 不足以保证合规。建议嵌入基础校验逻辑，把策略“代码化”：
- 用
terraform validate -json结合 jq 提取错误信息，拦截明显违规（如未设 tags、未启用加密） - 对关键模块（如 RDS、S3）编写 Terratest 单元测试，验证输出属性是否符合预期
- 在 plan 阶段调用自定义脚本扫描
plan.json，检测是否包含replace或destroy类高危动作，触发额外审批
