Terraform 改善基础架构的十个实践-IT技术-益华网络-网站建设_小程序开发|网页设计

Terraform 改善基础架构的十个实践

发布时间：2025-05-20 03:53:49 作者：益华网络来源：undefined 浏览量（0）点赞（0）

摘要：Terraform 是一种非常流行的开源 IaC（基础设施即代码）工具，用于定义和提供完整的基础设施。Terraform 于 2014 年推出，其采用率已在全球范围内快速增长，越来越多的开发人员正在学习 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.tf6 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.14Your version of Terraform is out of date! The latest versionis 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.backup0 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 配置，但配置没有得到正确应用，那么对基础设施造成的损害会有多大。因此，为了尽量减少故障影响范围，建议每次配置的基础设施数量不宜过多。即便出现问题，对基础设施的损害也能控制在较小范围，并且可以迅速得到纠正。 一次性配置大量基础设施是非常危险的

。