软件开发架构-10个关于Terraform改善基础架构的最佳实践

Terraform 是一种非常流行的开源 IaC（基础设施即代码）工具，用于定义和提供完整的基础设施。Terraform 于 2014 年推出，其采用率已在全球范围内快速增长，越来越多的开发人员正在学习 Terraform 并尝试在其组织中部署基础设施。

如果您已经开始使用 Terraform，则必须采用最佳实践来更好地配置生产基础设施。本文章将总结10个关于 Terraform 改善基础架构的最佳实践。

结构化

当您使用 Terraform 处理大型生产基础设施项目时，需要遵循适当的目录结构来应对项目中可能出现的复杂性。建议为不同目的建立单独的目录。如果您在开发、暂存和生产环境中使用 Terraform，请为每个环境设置单独的目录。

Terraform 配置也应该是分开的，因为经过一段时间后，不断增长的基础设施的配置将变得更加复杂。

geekflare@geekflare:~$ tree terraform_project/
terraform_project/
├── dev
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── modules
│ ├── ec2
│ │ ├── ec2.tf
│ │ └── main.tf
│ └── vpc
│ ├── main.tf
│ └── vpc.tf
├── prod
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
└── stg
├── main.tf
├── outputs.tf
└── variables.tf
6 directories, 13 files

您可以在文件 main.tf 本身内编写所有的 Terraform 代码（模块、资源、变量、输出），同时为变量和输出设置单独的 Terraform 代码使其更具可读性和易于理解。

命名规则

Terraform 中使用命名规则让资源易于理解、一目了然。

例如，假设您要为项目中的不同环境创建三个不同的工作区。与其将环境命名为env1 、env2 、env3 ，不如尝试使用dev、stage、prod 来命名。从名称本身来看，很明显每个环境都代表着不同的工作空间。资源、变量、模块等的也遵循类似的规则。

Terraform 中的资源名称应以相关资源名称开头，后跟下划线和其他详细信息。例如，用于在 AWS 中为 route table 创建 Terraform 对象的资源名称为 aws_route_table。

所以如果正确地遵循命名规则，即使是复杂的代码也会更容易理解。

使用共享模块

强烈建议使用可用的官方 Terraform 模块。直接使用现有模块，能够有效节省时间和精力。Terraform registry 有很多现成可用的模块，企业可以根据需要对现有模块进行更改。

此外，每个模块应该只专注于基础设施的一个方面，比如创建 AWS EC2 实例、设置 MySQL 数据库等。举个例子，如果您想在 terraform 代码中使用 AWS VPC软件开发架构，可以直接使用 -simple VPC。

module "vpc_example_simple-vpc" {
source
= "terraform-aws-modules/vpc/aws//examples/simple-vpc"
version = "2.48.0"
}

使用最新版本

Terraform 开发社区非常活跃，新功能发布频繁。建议在发布新的主要版本时使用最新版本的 Terraform。您可以轻松升级到最新版本。如果跳过多个主要版本，升级将变得非常复杂。

运行terraform -v命令以检查版本更新。

geekflare@geekflare:~$ terraform -v
Terraform v0.11.14
Your version of Terraform is out of date! The latest version
is 0.12.0. You can update by downloading from www.terraform.io/downloads.html

备份系统状态

请始终备份 Terraform 的状态文件，这些文件跟踪基础设施的元数据和资源。默认情况下，这些名为terraform.tfstate的文件本地存储在工作区目录中。

如果没有这些文件，Terraform 将无法确定在基础设施上部署了哪些资源。因此，必须备份状态文件。默认情况下，terraform.tfstate.backup会被创建并用来保存状态文件的备份。

geekflare@geekflare:~$ tree terraform_demo/
terraform_demo/
├── awsec2.tf
├── terraform.tfstate
└── terraform.tfstate.backup
0 directories, 3 files

如果要将备份状态文件存储到其他位置，在 terraform 命令中使用-backup标记并提供位置路径。大部分情况下，一个项目会有多个开发人员参与。因此为了让开发人员方便访问状态文件。应该使用terraform_remote_state数据源将其存储在远程位置。

以下示例将备份到 S3。

data "terraform_remote_state" "vpc" {
backend = "s3"
config = {
bucket = “s3-terraform-bucket”
key = “vpc/terraform.tfstate"
region = “us-east-1”
   }
}

锁定状态文件

可能有多个场景，其中不止一个开发人员试图同时运行 Terraform 配置。这可能导致 terraform 状态文件损坏甚至数据丢失。锁定机制能够有效防止此类情况发生，确保一次只有一个人在运行 terraform 配置，并且没有冲突。

下面是使用 DynamoDB 锁定位于远程位置的状态文件的示例。

resource “aws_dynamodb_table” “terraform_state_lock” {
name = “terraform-locking”
read_capacity = 3
write_capacity = 3
hash_key = “LockingID”
attribute {
name = “LockingID”
type = “S”
   }
}
terraform {
backend “s3” {
bucket = “s3-terraform-bucket”
key = “vpc/terraform.tfstate”
region = “us-east-2”
dynamodb_table = “terraform-locking”
   }
}

当多个用户尝试访问状态文件时，DynamoDB 数据库名称和主键将用于状态锁定并保持一致性。注意：并非所有后端都支持锁定。

使用自变量

self变量是一种特殊的变量，当您在部署基础设施之前不知道变量的值时可以使用它。假设您要使用仅在 terraform apply 命令后部署的实例的 IP 地址，也就是在它启动并运行之前您是不知道 IP 地址的。

在这种情况下，您可以使用自变量self.ATTRIBUTE。在这个例子中软件开发架构，您可以使用self.ipv4_address作为自变量来获取实例的 IP 地址。这些变量只允许在 terraform 配置的连接和配置块上使用。

connection {
host = self.ipv4_address
type = "ssh"
user = var.users[2]
private_key = file(var.private_key_path)
}

最小化爆炸半径

爆炸半径（Blast Radius）是衡量如果流程没有按计划进行时可能发生的损害的量度。

例如，如果您在基础设施上部署了一些 Terraform 配置，但配置没有得到正确应用，那么对基础设施造成的损害会有多大。因此，为了尽量减少故障影响范围，建议每次配置的基础设施数量不宜过多。即便出现问题，对基础设施的损害也能控制在较小范围，并且可以迅速得到纠正。一次性配置大量基础设施是非常危险的。

使用 var 文件

在 terraform 中，您可以创建一个带有扩展名的文件.tfvars，并使用-var-file此文件传递给 terraform apply 命令。这个方式可以帮助您传递那些您不想放入 terraform 配置代码中的变量。

始终建议通过-var-file在本地传递密码、密钥等变量，而不是将其保存在 terraform 配置或远程位置版本控制系统中。

例如，如果您想使用 terraform 启动 ec2 实例，您可以使用-var-file传递访问密钥和其他机密信息。创建文件 terraform.tfvars 并将密钥放入此文件中。

geekflare@geekflare:~$ gedit terraform.tfvars
access_key = "AKIATYWSDFYU5DUDJI5F"
secret_key = "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"

然后在 terraform 命令中使用这个 var 文件。

geekflare@geekflare:~$ terraform apply -var-file=/home/geekflare/terraform.tfvars

使用 Docker

当您运行 CI/CD 流水线构建作业时，建议使用 docker 容器。Terraform 提供了可以直接使用的官方 Docker 容器。如果需要更改 CI/CD 服务器，您可以轻松地在容器内传递基础设施。

在生产环境上部署基础设施之前，您还可以在 docker 容器上测试基础设施，非常容易部署。通过结合 Terraform 和 Docker，您可以获得可移植、可重用、可重复的基础设施。

参考链接：