GitOps风格的Terraform执行流程

前言

GitOps的本质并不依赖于具体工具，而是取决于部署流程是否以Git为唯一事实源，能自动执行，并且能够完整追踪操作和变更。

Terraform本身不是GitOps，而是通过CI/CD或工作流引擎等DevOps工具，把Terraform执行流程设计成GitOps风格。

一、Terraform

Terraform是Hashicorp开源的1款基础设施即代码 (IaC) 的工具，代码化的方式定义和管理云基础设施。

Terraform提供了“Provider”的插件机制，每个Provider面向一个独立的服务提供商的插件，可让您与不同的云服务提供商通过 API 与其进行交互，进而实现对不同云基础设施资源的自动化管理。

例如：您可以使用面向阿里云的 Terraform Provider 来定义和管理阿里云的基础设施。

1.架构

2.项目代码

3.工作流程

这张图展示了1个使用Terraform在Azure Cloud上部署Web应用的工作流程。以下是详细解释：

Write code（编写代码）

流程从左上角的 “Write code” 开始，表示编写 Terraform 配置代码的过程。

main.tf（主配置文件）

编写的代码存储在一个名为 “main.tf” 的文件中，这个文件是 Terraform 的主配置文件。

2.terraform init 初始化

从 “main.tf” 文件出发，箭头指向 “terraform init” 操作。这一步是 Terraform 的初始化步骤，用于初始化工作目录，下载所需的提供者插件等。

3.terraform plan 计划

初始化后，进入 “terraform plan” 步骤。这一步用于生成一个执行计划，显示 Terraform 将执行哪些操作来达到期望的基础设施状态。

4.Approve 批准

在 “terraform plan” 之后，有一个 “Approve” 步骤，表示需要人工审查并批准执行计划。这个步骤由一个绿色的对勾图标表示。

5.terraform apply 应用

批准后，进入 “terraform apply” 步骤。这一步用于实际执行基础设施的创建、更新或删除操作。

terraform.tfstate（状态文件）

在 “terraform apply” 操作之后，生成一个 “terraform.tfstate” 文件。这个文件记录了当前基础设施的状态。

6.基础设施创建成功

整个流程的最终目标是在 Azure Cloud 上部署基础设施。图的右侧展示了 Azure Cloud 中的资源结构：

• • • Availability Zone 1 和 Availability Zone 2（可用区 1 和可用区 2）：这两个区域用于提供高可用性。
    • Web App（Web 应用）：在每个可用区内都部署了一个 Web 应用，这些应用由蓝色的图标表示。

以上执行流程主要涉及以下几类文件：

.tf 文件

这是最核心的配置文件，用于定义基础设施资源相关内容。

声明要创建的各类资源（像云服务器、数据库、存储桶等），同时可以设定资源的具体属性、参数等，还能定义变量、输出变量以及模块调用等情况，

示例如下：

# 定义一个阿里云的OSS存储桶资源

resource "alicloud_oss_bucket" "my_bucket" {

  bucket = "my-test-bucket"

  acl = "private"

}

.tfvars  文件 

.tfvars文件主要功能是为.tf文件中定义的变量赋值。

在不同的部署环境（如开发环境、生产环境）中，变量的值往往不同，通过.tfvars文件可以灵活地指定这些具体值，方便配置复用；

例如：

region = "us-west-1"

instance_type = "t2.micro"

versions.tf

主要用于声明期望的版本要求，指定

• Terraform核心版本范围
• 各个 Provider的版本范围
• 模块大致的版本

它更多是1种宽泛的、基于规则的版本设定，给出了一个允许使用的版本区间。例如在versions.tf里写 

provider "aws" { version = "~> 4.0" }，表示希望使用接近 4.0 版本的 AWS Provider，但具体是 4.0 几并不明确限定。

# 指定Terraform核心版本要求
terraform {
  required_version = ">= 1.1.0"
}

# 指定AWS Provider版本要求
provider "aws" {
  version = "~> 4.0"
}

# 指定具体模块及版本
module "my_web_app" {
  source  = "my-org/my-repo/my-web-app"
  version = "2.0.0"
}

.terraform.lock.hcl  文件

Terraform在首次运行terraform init命令初始化Terraform工作目录，或者在添加/更新提供者或模块时自动生成或更新.terraform.lock.hcl文件。

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of kreuzwerker/docker...
- Installing kreuzwerker/docker v2.12.2...
- Installed kreuzwerker/docker v2.12.2 (self-signed, key ID 24E54F214569A8A5)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

这确保了文件能够及时反映当前项目所依赖的资源的最新版本信息。

当Terraform 执行初始化（terraform init ）等操作时，会根据versions.tf里的要求去查找并下载符合条件的具体版本，然后把实际用到的这些版本信息记录到terraform.lock.hcl文件中。

比如按照上述 AWS Provider 的要求，实际下载使用了 4.0.5 版本，就会在这个文件里明确记录下来，后续再次执行相关操作时，就会固定使用这个已经锁定的 4.0.5 版本，避免因意外引入不同版本而出现兼容性问题

# 示例的部分内容，展示锁定的模块及版本信息

provider "registry.terraform.io/hashicorp/aws" {

  version = "4.64.0"

  hashes = [

    "h1:abcdefg123456789...",

  ]

}

versions.tf和terraform.lock.hcl文件的区别

虽然versions.tf设定了版本的大致要求，但terraform.lock.hcl通过锁定实际使用版本来进一步增强版本管理的精确性、一致性和稳定性；

二者相互配合共同完善Terraform项目的版本管理工作。

terraform.tfplan文件

- 执行terraform plan命令后会生成该文件，它呈现了Terraform根据当前配置将要对基础设施资源做出的更改计划，清晰列出哪些资源会被创建、哪些要更新、哪些会被删除等内容，方便提前查看操作规划。

.tfstate文件

由Terraform backend管理存储的状态文件，记录着已创建资源的实际状态信息，像资源的具体ID、当前的属性详情、资源间的关联关系等。

Terraform依据这份文件里的状态去执行后续的更新、删除等操作。

为了便于团队协作，通常存在S3对象存储；

.tfstate文件通常为JSON格式可以使用Ansible调用生产主机清单（inventory）；

本地存储

在使用terrafom apply执行部署计划之后，当前目录中就产生了名叫 “terraform.states” 的 Terraform 的状态文件，该文件中记录了已部署资源的状态。

默认情况下，在执行部署计划后，Terraform 的状态文件会存储在本地，但是这样往往就造成一些弊端：

（1）不适用团队之间协助，就好比在数据库中对同一条数据进行操作时，就会引起异常

（2）状态文件中包含一些机密信息，会造成一定的机密泄露

（3）如果不慎将本地的状态文件删除掉的话，已执行部署计划的资源的管理将很难在通过Terraform进行管理

所以，Terraform 是支持在远端存储状态文件，也就是在 Azure Storage Account 中存储远端状态文件，Terraform 状态的存储是由1个称之为Backend的组件决定的

远端存储

面对本地状态存在的问题，当使用远端状态存储时，这些问题将会得到解决：

1. 远端状态文件会自动更新

   当远程存储时，状态文件会自动更新，即一旦配置了远程后端，每次运行 plan 或 apply 命令时，Terraform 将自动从远端加载状态文件。除此之外，它还会在每次 apply 后自动将状态文件同步存储在远端中，因此不存在手动错误的情况。

2. 远端状态文件支持状态锁定

   当执行Terraform命令时，可以对远端状态文件进行加锁，这样如果多个开发人员同时运行 terraform apply，它不会因同时更新而损坏。

3. 远端状态文件存储比本地存储更安全

   OSS Bucket 支持本地传输加密和远端加密功能。此外，OSS Bucket 包括多种配置访问权限的方法，因此你可以以精细化的方式控制状态文件的访问权限。

二、GitOps风格的Terraform执行流程

Terraform虽然解决了基础设施写成代码的（IaC）的核心问题，但无法满足企业多人如何安全、可控、可审计地协作管理代码化基础设施需求。

Terraform本身不是GitOps工具，但可以借助Jenkins/Atlantis/ArgoWorkflows等工具，把Terraform执行流程设计成GitOps风格，使Terraform具备流程与平台能力。

Atlantis、TerraformCloud 和 Spacelift 天生支持 Git 驱动Terraform，是开箱即用的Terraform GitOps解决方案。

而Jenkins和ArgoWorkflows则需要自己设计自动化流程，间接实现GitOps风格的Terraform自动化。

工具	GitOps 属性	特点
Jenkins	✅（通过 Pipeline 实现）	通过监听 Git 仓库变更触发 Pipeline 执行 terraform plan 和 terraform apply；高度灵活，可加审批、通知、条件逻辑，但需要自行维护 Pipeline 和执行环境
Atlantis	✅	PR 评论触发 Terraform plan/apply，Git 驱动，开箱即用，适合中小团队
Terraform Cloud	✅	托管 Terraform，支持 Git 驱动、策略、审计和 state 管理
Spacelift	✅	企业级 Terraform GitOps 平台，支持复杂审批、多团队管理和策略控制
Argo Workflows	✅（间接）	监听 Git 变更触发 Workflow 执行 Terraform，支持复杂任务编排，但需要自行设计 Git → Workflow → Terraform 流程

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

参考