GitLab CI/CD部署AWS无服务器应用：Terraform Plan阶段失败排查

问题解答 #

1. 明明项目目录中有tf文件，为何Terraform提示目录中无配置文件？ #

你的流水线在before_script里执行了mkdir -p $TF_ROOT（创建terraform目录）并cd $TF_ROOT进入该目录，但你的Terraform配置文件实际存放在Git仓库的根目录，而非这个新建的空目录。Terraform在空目录执行init自然会提示无配置文件。

你提到Fmt和Validate阶段运行正常，大概率是测试时的特殊情况——按当前配置逻辑，这两个阶段同样会在空目录执行，应该也会报错。

2. 每次运行流水线时，mkdir $TF_ROOT命令是否会创建空目录？ #

是的。GitLab Runner每次执行流水线时，都会拉取全新的仓库代码到临时工作目录，这个目录是完全干净的。mkdir -p $TF_ROOT会检查terraform目录是否存在，不存在就创建一个空目录——所以每次流水线执行到这一步，都会生成一个空的terraform目录。

3. 修复方案与GitLab镜像/目录机制讲解 #

修复后的.gitlab-ci.yml配置

image:
  name: hashicorp/terraform:light
  entrypoint:
    - '/usr/bin/env'
    - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

stages:
  - fmt
  - validate
  - plan
  - apply

variables:
  # 若TF文件在仓库根目录则设为.；若在子目录则设为对应路径（如terraform）
  TF_ROOT: "."
  AWS_ACCESS_KEY_ID: "$AWS_ACCESS_KEY_ID"
  AWS_SECRET_ACCESS_KEY: "$AWS_SECRET_ACCESS_KEY"
  AWS_DEFAULT_REGION: "$AWS_DEFAULT_REGION"
  TF_BACKEND_BUCKET: "$TF_BACKEND_BUCKET"
  TF_BACKEND_KEY: "$TF_BACKEND_KEY"
  TF_BACKEND_DYNAMODB_TABLE: "$TF_BACKEND_DYNAMODB_TABLE"
  # 需在GitLab项目变量中配置TFVARS_FILE的值（如prod.tfvars）
  TFVARS_FILE: "$TFVARS_FILE"

before_script:
  - terraform --version
  # 直接进入TF配置所在目录，无需创建空目录
  - cd $TF_ROOT
  - terraform init -reconfigure 
      -backend-config="bucket=$TF_BACKEND_BUCKET" 
      -backend-config="key=$TF_BACKEND_KEY" 
      -backend-config="region=$AWS_DEFAULT_REGION" 
      -backend-config="dynamodb_table=$TF_BACKEND_DYNAMODB_TABLE"
  - echo "当前工作目录: $(pwd)"
  - echo "变量文件路径: $TFVARS_FILE"
  - ls -al

format:
  stage: fmt
  script:
    - terraform fmt -check
  only:
    - branches

validate:
  stage: validate
  script:
    - terraform validate
  only:
    - branches

plan:
  stage: plan
  script:
    # 提前检查变量文件是否存在
    - test -f "$TFVARS_FILE" || (echo "变量文件$TFVARS_FILE不存在" && exit 1)
    - terraform plan -var-file="$TFVARS_FILE" -out=tfplan
  only:
    - branches

apply:
  stage: apply
  script:
    - test -f "$TFVARS_FILE" || (echo "变量文件$TFVARS_FILE不存在" && exit 1)
    - terraform apply -auto-approve tfplan
  environment:
    name: dev
    url: "https://mycompany.awsapps.com/start/#"
  only:
    - main
  when: manual

关键修复点

• 修正TF_ROOT：根据实际TF文件位置设置，根目录设为.，子目录则设对应路径，避免切换到空目录。
• 移除多余的mkdir命令：防止创建空目录脱离代码存放路径。
• 修复entrypoint路径错误：原配置usr/bin/env缺少开头的/，会导致命令无法找到，修正为/usr/bin/env。
• 增加变量文件检查：避免$TFVARS_FILE未配置时出现空路径错误。
• 修正apply命令：terraform apply无需-out参数，直接使用plan生成的tfplan文件即可。

GitLab镜像与目录工作机制

1. 镜像运行逻辑

   • 指定image后，Runner会拉取该镜像作为执行环境，所有阶段默认在这个容器中运行（可单独为阶段指定镜像）。
   • entrypoint用于覆盖镜像默认入口命令，确保环境变量和系统路径正常工作——路径错误会导致基础命令无法执行。

2. 工作目录逻辑

   • 每次流水线启动时，Runner会将仓库代码克隆到临时工作目录（如/builds/<用户名>/<项目名>），这是所有命令的初始执行目录。
   • 所有before_script和阶段script命令都在此目录执行，除非用cd切换路径。
   • 不要随意创建空目录并切换，否则会脱离代码存放路径，导致找不到项目文件。

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