关于基础架构: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 配置，但配置没有失去正确利用，那么对基础设施造成的侵害会有多大。因而，为了尽量减少故障影响范畴，倡议每次配置的基础设施数量不宜过多。即使呈现问题，对基础设施的侵害也能管制在较小范畴，并且能够迅速失去纠正。一次性配置大量基础设施是十分危险的。

在 terraform 中，您能够创立一个带有扩展名的文件 <em>.</em>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

当您运行 CI/CD 流水线构建作业时，倡议应用 docker 容器。Terraform 提供了能够间接应用的官网 Docker 容器。如果须要更改 CI/CD 服务器，您能够轻松地在容器内传递基础设施。

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

参考链接：
https://geekflare.com/terraform-best-practices/

关于基础架构:Terraform-改善基础架构的十个最佳实践

结构化

命名规定

应用共享模块

应用最新版本

备份零碎状态

锁定状态文件

应用自变量

最小化爆炸半径

应用 var 文件

应用 Docker