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/