基于Terraform模块的多环境GitLab CI/CD搭建咨询

前置准备 #

1. 配置Terraform远程状态
   本地执行时用的是本地状态文件，CI环境必须改用远程状态避免状态丢失或冲突。每个服务（staging/eks、staging/lambda等）要单独配置隔离的远程状态，比如用AWS S3或GitLab内置的Terraform状态存储。
   以S3为例，在每个服务目录的.tf文件中添加：

   terraform {
     backend "s3" {
       bucket = "你的状态存储桶名称"
       key    = "staging/eks/terraform.tfstate" # 每个服务对应唯一key
       region = "你的区域"
     }
   }
   

   本地执行一次terraform init完成状态迁移，确保CI能读取到正确的远程状态。

2. 配置GitLab Runner权限
   给GitLab Runner分配云服务商的最小权限（比如AWS IAM角色），权限范围仅覆盖当前需要部署的资源类型（EKS、Lambda、S3等），避免过度授权。推荐用GitLab OIDC角色代替硬编码的Access Key，提升安全性。

编写GitLab CI配置文件（.gitlab-ci.yml） #

核心思路是用矩阵作业实现多服务的独立部署，同时通过变更触发规则避免不必要的CI执行。以下是完整配置示例：

stages:
  - plan
  - apply

# 定义Terraform基础作业模板
.terraform_base:
  image: hashicorp/terraform:latest
  before_script:
    - cd ${SERVICE_DIR}
    - terraform init -input=false

# 生成部署计划的作业
terraform-plan:
  extends: .terraform_base
  stage: plan
  script:
    - terraform plan -out=plan.tfplan -input=false
  artifacts:
    paths:
      - ${SERVICE_DIR}/plan.tfplan
  parallel:
    matrix:
      - SERVICE_DIR: ["staging/eks", "staging/lambda", "staging/s3"]
  only:
    changes:
      - modules/${SERVICE_DIR#staging/}/**/* # 对应模块变更触发
      - ${SERVICE_DIR}/**/* # 服务配置变更触发

# 执行部署的作业（需手动确认）
terraform-apply:
  extends: .terraform_base
  stage: apply
  script:
    - terraform apply -input=false plan.tfplan
  dependencies:
    - terraform-plan
  parallel:
    matrix:
      - SERVICE_DIR: ["staging/eks", "staging/lambda", "staging/s3"]
  only:
    changes:
      - modules/${SERVICE_DIR#staging/}/**/*
      - ${SERVICE_DIR}/**/*
  when: manual
  allow_failure: false

关键细节说明 #

• 独立部署触发：通过only: changes规则，只有当对应服务的配置文件（staging/xxx/）或关联模块（modules/xxx/）发生变更时，才会触发该服务的CI作业，避免全量执行。
• 手动确认部署：when: manual确保apply操作需要人工确认，防止误操作导致的基础设施变更。
• 状态隔离：每个服务使用独立的远程状态文件，避免不同服务的状态互相干扰。
• 依赖一致性：将每个服务目录下的terraform.lock.hcl提交到Git，确保CI环境使用的依赖版本与本地一致。

测试与过渡 #

1. 先提交配置文件到GitLab，触发plan作业，检查是否能正常初始化Terraform并生成部署计划。
2. 手动触发对应服务的apply作业，验证CI环境能否成功完成部署，对比本地执行的结果确保一致。

内容的提问来源于stack exchange，提问作者egib