GrowingIO Terraform 实践

关注

原创最新推荐文章于 2026-06-02 08:37:44 发布 906 阅读 AI 写同款· GEO 优化 ›

Terraform入门到精通 Terraform 是一种开源的基础设施即代码（Infrastructure as Code，IaC）工具，由 HashiCorp 公司开发。它允许用户通过编写声明式的配置文件（通常是 HCL，即 HashiCorp 配置语言）来定义和管理云基础设施资源，从而实现基础设施的自动化部署、管理和更新。阅读详情

背景

为满足 GrowingIO 客户多样性的需求，在公有云设施上使用 Terraform 作资源管理。采取 Terrform 具有以下相关优势：

多云支持，主流云厂商均提供对应的Provider支持。
自动化管理基础结构，可重复对资源进行编排使用。
基础架构即代码(Infrastructure as Code)，允许保存基础设施状态，便于追踪管理。
统一的语法来管理不同的云服务，实现标准化管理。

Terraform 介绍

概念

Terraform是一个开源 IAS 工具，提供一致的 CLI工作流，可管理数百个云服务。 Terraform通过将云厂商提供的 API 编写为声明式配置文件，通过Terraform的命令行接口，可将资源调度配置应用到任意支持的云上，并实现版本控制。更多详情请参见HashiCorp Terraform。

Terraform通过不同的Provider来支持不同云平台。国外云服务商如 Azure， AWS， GoogleCloud， DigtalOcean，国内云服务商如 Aliyun， TencentCloud， Ucloud， BaiduCloud均有提供官方的 Provider。

架构

Terraform通过解析用户书写的HCL(HashiCorp Configuration Language)格式的DSL文件，然后通过Terraform core与各云厂商提供的Providers进行交互，从而进行相关资源的调度。各云厂商依HCL代码风格，将自家资源调用API重新封装，以生成对应的 Providers。

项目实践

项目设计

客户项目存在多个同构环境，环境交付需要一致。
每个环境中存在中多个项目，各项目对资源调度需求各异。
每个项目需要使用EC2、ELB、EBS、 EMR等多种资源。

项目实现

项目结构

# tree -L 3 .
├── README.MD  
├── module
│   ├── app1
│   │   ├── config.tf
│   │   ├── locals.tf
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   └── variables.tf
│   ├── global
│   │   └── config.tf
└── dev
    ├── main.tf
    └── output.tf

目录结构拆解：

module中依项目名进行封装。其中 app1为项目名。
global为全局参数设置。
dev为各环境对 module的引用封装。

module细节：

config.tf为配置的相关参数，如 Providers的相关参数设定。
locals.tf为变量的计算生成与其它变量引用，如 module 的引用与一些复杂变量的重生成。
main.tf为 resource 与 data 相关的资源编排调用。
outputs.tf为项目输出值，如创建 ecs之后主机的 ip 等。
variables.tf 为传参的相关设置，如需创建 ecs的数量。

`module` 封装

module 的资源引用

在对资源调度的实施过程中，往往需要多次重复作业，故需将多个原子操作，统一封装成module，后续在外部引用module并传入对应参数即可。

apply构建文件代码:

# dev/main.tf
...
module "app1" {
  source                                 = "../module/app1"
  aws_ec2_create_number                  = 3
  ...
}

module 的条件判断

在 Terraform 中，往往将循环与判断结合使用，主要使用场景有两种：

确认变量形式
确认资源是否创建

如创建 ecs时的主机名设置，当创建多台主机时，主机名需数字后缀以区分，而只有一台主机时，不需要数字后缀。

全局变量

在Terraform中，官方为了层级的简洁，默认不推荐使用全局变量，因为全局变量的设置，会出现所见非所得的现象，详见Terraform global variables

但在实际生产中，却有相关需求，如 aws_profile_name在每个项目中均一致，同时后期因为用户的 profile 设置不一致而需要统一变更。

我们可以将此类参数写入一个 module之中。

# module/global/config.tf
...
output "aws_profile_name" {
  value = "default"
}
...

在各项目中的module，再次对global的module作引用。

# module/application/locals.tf
...
// In order to make global variables --beginning
module "global" {
  source = "../global"
}

locals {
  ...
  aws_profile_name = module.global.aws_profile_name
}
// In order to make global variables --end
...

最后在项目中，作对应自身module的locals值作相关的引用。

# module/application/config.tf
...
Provider "aws" {
  profile = var.aws_profile_name == "" ? local.aws_profile_name :  var.aws_profile_name
  ...
}
...

环境隔离

在Terraform中，隔离一般有两种：

workspace隔离
目录隔离

在 workspace隔离中，需要使用 terraform workspace子命令，与 git branch类似，但是 terraform workspace 中的隔离，并不直观，在生产中容易出现误操作，所以对于不同环境的 module调用，本项目中采用了目录隔离。

# dev/main.tf
...
module "app1" {
  source                                 = "../module/app1"
  aws_ec2_create_number                  = 3
  ...
}

# stage/main.tf
...
module "app1" {
  source                                 = "../module/app1"
  aws_ec2_create_number                  = 3
  ...
}

项目心得

Terraform 在基础资源编排中，使用方便，语法简洁，但由于各云厂商提供 Provider的风格并不完全统一，一定程度上增加了多云混合使用的成本。特别是对于国内非 AWS用户而言，国内部分云厂商提供的Provider，支持的资源种类相较于 AWS 偏少，部分场景可能无法实现。

同时也因为 Terraform的语法对于一些高级特性的支持欠缺，导致在部分复杂的场景中，有些捉襟见肘，而更多需要 Provider去提供对应功能。虽然有 module的设计，可以进行代码复用，但也有因部分参数无法动态区分，而不得不创建多个 module以区分，这点在国内云厂商提供的 Provider中尤为明显。

小结

本文简单介绍了Terraform的基本概念以及采用Terraform的原由。

同时例举了在生产实践中Terraform的目录结构编排与环境隔离，详细说明如何通过传参来动态调整资源编排的实际传参与调度，如何通过多次组合计算以动态生成新的参数来规避Terraform对高级特性支持的欠缺，以及如何构建全局变量以解决全局动态传参。基于篇幅限制， Terraform的使用无法逐一说明，对Terraform有兴趣的同学可自行学习了解。

参考

Mikael Krief. Terraform Cookbook: Efficiently define, launch, and manage Infrastructure as Code across various cloud platforms. Packt Publishing 2020
Scott Winkler. Terraform in Action. Manning 2021
Yevgeniy Brikman. Terraform: Up & Running: Writing Infrastructure as Code. O'Reilly Media 2019
Terraform