第 1 章 Terraform 概述
1.1 Terraform 介绍
Terraform 是 HashiCorp 公司旗下的 Provision Infrastructure 产品, 是 AWS APN Technology Partner 与 AWS DevOps Competency Partner。Terraform 是一个 IT 基础架构自动化编排工具，它的口号是“Write, Plan, and Create Infrastructure as Code”, 是一个“基础设施即代码”工具，类似于 AWS CloudFormation，允许您创建、更新和版本控制的 AWS 基础设施。
Terraform 基于 AWS Go SDK 进行构建，采用 HashiCorp 配置语言（HCL）对资源进行编排，具体的说就是可以用代码来管理维护 IT 资源，比如针对 AWS，我们可以用它创建、修改或删除 S3 Bucket、Lambda,、EC2、Kinesis、VPC 等各种资源。并且在真正运行之前可以看到执行计划(即干运行-dryrun)。由于状态保存到文件中，因此能够离线方式查看资源情况（前提是不要在 Terraform 之外对资源进行修改）。Terraform 配置的状态除了能够保存在本地文件中，也可以保存到 Consul, S3 等处。
Terraform 是一个高度可扩展的工具，通过 Provider 来扩展对新的基础架构的支持，几乎支持所有的云服务平台，AWS 只是 Terraform 内建 Providers 中的一种。
在 Terraform 诞生之前，我们对 AWS 资源的操作主要依赖 Console、AWS CLI、SDK 或 Serverless。AWS CLI 什么都能做，但它是无状态的，必须明确用不同的命令来创建、修改和删除。Serverless 不是用来管理基础架构的，用 Lambda 创建资源是很麻烦的事。AWS 提供的 CloudFormation，虽然功能非常强大，但是大量的 JSON 代码阅读困难。
1.2 与 CloudFormation 的区别
AWS CloudFormation 允许将基础设施的细节写入配置文件中，配置文件允许基础设施弹性创建、修改和销毁。Terraform 类似地使用配置文件来详细描述基础架构设置，并且可以进一步组合多个 Providers 和服务。它提供统一 HCL 语法，为使用不同的平台，运维人员无需去学习每一种平台， Terraform 还通过使用执行计划的概念将计划阶段与执行阶段分开。
通过运行 terraform plan，刷新当前状态并查询配置以生成动作计划。该计划包括将采取的所有行动：将创建，销毁或修改哪些资源。可以对其进行检查，以确保运行正常。运用 terraform graph，该计划可以被可视化显示依赖的顺序。一旦捕获了计划，执行阶段只能限于计划中的操作。
Terraform 的主要特点如下：
基础架构代码（Infrastructure as Code）
使用 HCL 高级配置语法描述基础架构。这样可以让数据中心的蓝图进行版本控制，像其他代码一样对待，基础设施可以共享和重用。
执行计划（Execution Plans）
Terraform 有一个“planning”步骤，它生成一个执行计划。当调用时，执行计划显示所有的操作，能有效避免操作人口山水对基础设施的误操作。
资源图表（Resource Graph）
Terraform 构建了所有资源的图形，并且并行化了任何非依赖资源的创建和修改。因此，Terraform 尽可能高效地构建基础架构，操作人员可以深入了解其基础架构中的依赖关系。
更改自动化（Change Automation）
复杂的变更集可以通过很少的人工交互应用到基础设施中，使用前面提到的执行计划和资源图表, 将清楚的知道 Terraform 发生的变化及顺序, 避免了许多可能的人为错误。
第 2 章 Terraform 入门
本章将主要介绍 Terraform 的安装及初始环境配置。
2.1 Terraform 安装
可以到如下网站进行下载，选择所需要的二进制版本，支持 Linux、Windows、macOS 及 BSD，目前最新版本为 v0.10.8。
https://www.terraform.io/downloads.html
需要基于源码编译安装的可以到 github 下载。
https://github.com/hashicorp/terraform
将安装包解压后，会得到名为 terraform 的可执行文件，直接更新 PATH 环境变量即可运行。
2.2 配置介绍
Terraform 使用文本文件来描述基础设施和设置变量。这些文件称为 Terraform 配置，并以 .tf 结尾。本节介绍这些文件的格式以及它们的加载方式。
配置文件的格式可以有两种格式：Terraform 格式和 JSON。Terraform 格式更加人性化，支持注释，并且是大多数 Terraform 文件通常推荐的格式。JSON 格式适用于机器创建，修改和更新，也可以由 Terraform 操作员完成。Terraform 格式后缀名以.tf 结尾，JSON 格式后缀名以.tf.json 结尾。详细说明请参考如下链接：
https://www.terraform.io/docs/configuration/index.html
2.2.1 加载顺序与语义
在调用加载 Terraform 配置的任何命令时，Terraform 将按字母顺序加载指定目录中的所有配置文件。
加载文件的后缀名必须是.tf 或.tf.json。否则，文件将被忽略。多个文件可位于同一目录中。Terraform 配置文件可以一个是 Terraform 语法，另一个是 JSON 格式。
覆盖文件是一个例外，因为它们在所有非覆盖文件之后按字母顺序加载。加载文件中的配置将相互附加。这具有相同名称的两个资源不会合并，而是会导致验证错误。
配置中定义的变量，资源等的顺序并不重要。Terraform 配置是声明式的，因此对其他资源和变量的引用不依赖于它们定义的顺序。
2.2.2 配置语法
Terraform 配置的语法称为 HashiCorp 配置语言（HCL）。Terraform 还可以读取 JSON 配置。但是，对于一般的 Terraform 配置，我们建议使用 HCL Terraform 语法。语法说明可以参考如下：
https://www.terraform.io/docs/configuration/syntax.html
以下是 Terraform HCL 语法的示例：
An AMI
variable “ami” {
description = “the AMI to use”
}
/* A multi
line comment. */
resource “aws_instance” “web” {
ami = “${var.ami}”
count = 2
source_dest_check = false
connection {
user = “root”
}
}
Terraform 配置的语法是 HashiCorp 独创的 HCL(HashiCorp configuration language), 它可以兼容 JSON 格式，可以采用任何文本编辑器进行配置文件的更新。
http://hashivim.github.io/vim-terraform/
可以安装 hashivim/vim-terraform 插件，在 Vim 中实现 HCL 语法加亮。写好的 *.tf 文件后可以调用 terraform fmt 对配置文件进行格式化。
2.3 AWS Provider 配置
AWS Provider 被用来与 AWS 支持的许多资源进行交互。在使用该提供程序之前, 需要使用适当的 Credentials 进行配置。
https://www.terraform.io/docs/providers/aws/index.html
AWS Provider 提供了一种提供身份验证凭据的灵活方法,主要支持如下四种方式:
1）静态凭据
2）环境变量
3）共享凭据文件
4）EC2 角色
可以借助 Terraform 的多 Provider 实例配置，实现对多个 Region 的管理，例如：
2.4 HelloWorld
本章节将演示如何利用 Terraform 进行 S3 桶的自动化构建、修改、删除。
2.4.1 创建配置文件
新建 helloworld 目录，并编辑一个名为 s3demo.tf 的文件，具体内容如下：
运行 terraform fmt 对当前目录下的所有配置文件进行格式化。有关 S3 更详细的配置可以参考
https://www.terraform.io/docs/providers/aws/r/s3_bucket.html
注：resource “aws_s3_bucket” “s3_bucket” 中，resource 后第一个是 TYPE, 即资源名，第二个参是 NAME，类型和名称的组合必须是唯一的。其实 “s3_bucket” 在这里没什么用，只是一个描述或助记符而已，在作为变量引用的时候就要用到它，”${aws_s3_bucket.s3_bucket.arn}”, 引用时不需要知道实际的名称。
我们使用 shared_credentials_file 中的 profile, 请确定您以预先生成好的 credentials 文件及有效的 profile。
2.4.2 初始化工作目录
执行完了 terraform init 之后会在当前目录中生成 .terraform 目录，并依照 *.tf 文件中的配置下载相应的插件，下载可能需要等待一段时间。
2.4.3 运行管理命令
2.4.3.1 terraform plan
完成前面的准备工作之后，可以开始运行 Terraform 的管理命令了。Terraform 在正式执行之前提供了预览执行计划的机会，让我们清楚的了解将要做什么。
由此计划还能知道关于 aws_s3_bucket 有些什么配置项，比如配置中可以加上 acceleration_status = “Enabled”
2.4.3.2 terraform apply
这样便在 AWS 上创建了一个名为”my-tf-test-bucket003“的 S3 桶, 同时会在当前目录中生成一个状态文件 terraform.tfstate, 它是一个标准的 JSON 文件。这个文件对 Terraform 来说很重要，它会影响 terraform plan 的决策，虽然不会影响到实际的执行效果。
terraform state [list|mv|pull|push|rm|show]用来操作状态文件。
此时什么也不改，再次执行 terraform plan, 会显示没什么要做的。
我们将 s3demo.tf 文件中的 tags.Environment: “Dev” 改成”Dev001″，运行 plan
为什么说 terraform plan 是基于状态文件 terraform.tfstate 作出的呢？我们可以删除这个状态文件，然后执行 terraform plan 看看
Terraform 由于缺乏 terraform.tfstate 对比，所以认为是要添加一个 bucket, 但是实际执行 terraform apply 时，连接到远端 AWS, 发现该 bucket 已存在就报告错误。terraform apply 总能给出正确的操作结果。同理如果状态文件中说有那个 bucket, terraform plan 会说是更新，但 AWS 没有那个 bucket，实际执行 terraform apply 也会进行添加的。
2.4.3.3 资源更名
如果把 s3demo.tf 中的 bucket = “my-tf-test-bucket001″改成 bucket = ” my-tf-test-bucket003“，则将重命名桶，用 terraform plan 看下计划
实际上 terraform apply 也是先删除旧的，再创建新的。Terraform 像 git 一样用不同颜色和 +/- 号来显示变动操作。
2.4.3.4 terraform destroy
terraform destroy 命令，把 *.tf 文件中配置的所有资源从 AWS 上清理掉。
2.5 工作目录布局
Terraform 运行时会读取工作目录中所有的 *.tf, *.tfvars 文件，所以我们不必把所有的东西都写在单个文件中去，应按职责分列在不同的文件中，例如
在执行像 terraform plan 或 terraform apply 等命令的时候，可以按下 ctrl + c 让控制台输出详细的日志信息。
————
使用 Terraform 在 AWS 中国区域实现自动化部署指南系列（一） TERRAFORM 入门（本博文）
使用 Terraform 在 AWS 中国区域实现自动化部署指南系列（二） TERRAFORM 进阶
作者介绍：
韩旭明
亚马逊 AWS 合作伙伴解决方案架构师。历任惠普，埃森哲等公司，为中国石油，国家电网等客户提供服务，十八年工作经历中，在众多项目中担任解决方案架构师、咨询经理等职务，为客户提供云计算咨询、架构设计、实施，IT 运维管理等，并在云计算的架构，安全，与运维管理有丰富经验。
本文转载自 AWS 技术博客。
原文链接：
https://amazonaws-china.com/cn/blogs/china/aws-china-region-guide-series-terraform1/
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论