continuous-integration - 具有多个 Terraform 配置的有效 GitLab CI/CD 工作流程？

Question

我的团队将 AWS 用于我们的基础设施，跨越 3 different AWS accounts .我们将它们简称为 sandbox、staging 和 production。

我最近针对我们的 AWS 基础设施设置了 Terraform，它的层次结构映射到我们的账户，然后通过应用程序或 AWS 服务本身。 repo 结构看起来像这样:

staging
  iam
    groups
      main.tf
    users
      main.tf
  s3
    main.tf
sandbox
  iam
    ...
production
  applications
    gitlab
      main.tf
  route53
    main.tf
  ...

我们为每个 AWS 服务(例如 IAM 或 S3)或应用程序(例如 GitLab)使用单独的配置，因此我们最终不会为每个账户生成巨大的 .tf 文件很长时间才能为任何一项更改应用更新。理想情况下，我们希望摆脱基于服务的配置方法，转向更多基于应用程序的配置，但无论哪种方式，手头的问题都是一样的。

当从命令行手动应用更新时，这种方法一直运行良好，但我喜欢将其移至 GitLab CI/CD 以更好地自动化我们的工作流程，而这正是问题所在。

在我现有的设置中，如果我对 staging/s3/main.tf 进行单个更改，GitLab 似乎没有开箱即用的好方法来仅运行terraform plan 或 terraform apply 该特定配置。

如果我改为将所有内容移动到整个 AWS 帐户的单个 main.tf 文件中(或多个文件但绑定(bind)到单个状态文件)，我可以简单地让 GitLab 触发一个工作来完成plan 或 apply 仅适用于该配置。根据我们在每个账户中拥有的 AWS 资源数量，运行可能需要 15 分钟，但我认为这是一个潜在的选择。

看来我的问题最终可能与 GitLab 如何处理“monorepos”有关，而不是 Terraform 如何处理其工作流(毕竟，如果我简单地告诉它 什么，Terraform 会很乐意计划/应用我的更改已经改变)，尽管我也有兴趣听听人们如何构建他们的 Terraform 环境给定 - 或者为了完全避免 - 这些限制。

有没有人在他们的环境中解决过这样的问题？

Answer 1

Terraform 的好处在于它是幂等的，因此即使没有任何更改，您也可以直接应用，而且无论如何这都是一个无操作操作。

如果出于某种原因您真的只想在情况发生变化时在特定目录上运行计划/应用程序，那么您可以使用 only.changes 来实现。这样 Gitlab 只会在指定的文件发生更改时运行该作业。

因此，如果您有现有的结构，那么它就像做这样的事情一样简单:

stages:
  - terraform plan
  - terraform apply

.terraform_template:
  image: hashicorp/terraform:latest
  before_script:
    - LOCATION=$(echo ${CI_JOB_NAME} | cut -d":" -f2)
    - cd ${LOCATION}
    - terraform init

.terraform_plan_template:
  stage: terraform plan
  extends: .terraform_template
  script:
    - terraform plan -input=false -refresh=true -module-depth=-1 .

.terraform_apply_template:
  stage: terraform apply
  extends: .terraform_template
  script:
    - terraform apply -input=false -refresh=true -auto-approve=true .

terraform-plan:production/applications/gitlab:
  extends: .terraform_plan_template
  only:
    refs:
      - master
    changes:
      - production/applications/gitlab/*
      - modules/gitlab/*

terraform-apply:production/applications/gitlab:
  extends: .terraform_apply_template
  only:
    refs:
      - master
    changes:
      - production/applications/gitlab/*
      - modules/gitlab/*

我还假设存在共享位置的模块，以表明此模式还可以在存储库的其他地方查找更改，而不仅仅是您运行 Terraform 所针对的目录。

如果情况并非如此，并且您的结构更扁平并且您很高兴拥有一份申请工作，那么您可以将其简化为:

stages:
  - terraform

.terraform_template:
  image: hashicorp/terraform:latest
  stage: terraform
  before_script:
    - LOCATION=$(echo ${CI_JOB_NAME} | cut -d":" -f2)
    - cd ${LOCATION}
    - terraform init
  script:
    - terraform apply -input=false -refresh=true -auto-approve=true .
  only:
    refs:
      - master
    changes:
      - ${CI_JOB_NAME}/*

production/applications/gitlab:
  extends: .terraform_template

一般来说，这可以通过允许 Terraform 在每次推送时针对所有适当的目录运行来避免(可能只适用于推送到 master 或其他适当的分支)，因为如前所述，Terraform 是幂等的，所以它不会如果什么都没有改变，就不要做任何事情。这还有一个好处，如果您的自动化代码没有改变，但您的提供者发生了某些变化(例如有人打开了一个安全组)，那么 Terraform 将在下次触发时将其恢复到应有的状态。