将Terraform重新组织为灵活的变量化形式
重新将Terraform重构为灵活的变量化
首先
我之前接触了Terraform，并尝试构建了一些AWS资源。
在介绍给其他人使用并让他们尝试时，我遇到了一个问题。
那就是AWS资源的名称会发生重复……
为了解决这个问题，我对代码进行了修正，只改变了变量定义而不改动Terraform的描述。
改造前的Terraform
根据我们公司的规定，在AWS资源名称的开头要添加可以识别创建者的员工编号等信息。请将下面的terraform中的「xxxxxxxx」替换为员工编号。
resource "aws_codecommit_repository" "xxxxxxxx_test" {
repository_name = "xxxxxxxx_test"
description = "This is the Sample App Repository"
}
展开这个 Terraform 给有兴趣的人试用时，如果 repository_name 重复会导致错误。
改造后的 Terraform
因此，我们改进了Terraform，不再将员工编号等个人信息保存在其中，而是通过变量进行补充。我们将原先的「xxxxxxxx」替换为「${var.user_prefix}」。
resource "aws_codecommit_repository" "repository" {
repository_name = "${var.user_prefix}_test"
description = "This is the ${var.user_prefix} Sample App Repository"
}
变量定义文件
在这个文件中，我们将定义使用了哪些变量，并设置了AWS连接配置。
值得注意的是，该文件中不包含任何特定信息。
# AWS接続に必要な個人情報の宣言
variable "aws_access_key" {}
variable "aws_secret_key" {}
variable "aws_region" {}
# AWS接続設定
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "${var.aws_region}"
}
# 使用する変数の宣言
variable "user_prefix" {}
固有情报定义文件 –
然后，我们在这个文件中定义了特有信息。
虽然我也考虑过特有信息定义文件是否可以使用通用的文件名，但我决定将文件分为个人单位。
之所以采用这种思路，是因为我认为这种方式可以应用于按照环境单位划分，如开发、验证、商业等，而不仅仅是按个人信息划分。
文件名可以任意设置，但为了方便理解，我们使用员工编号命名为「xxxxxxxx.tfvars」。
※已对个人信息进行脱敏处理。
# AWS接続情報
aws_access_key = "xxxxxxxx"
aws_secret_key = "xxxxxxxx"
aws_region = "us-west-2"
# 社員番号
user_prefix = "xxxxxxxx"
指定一个固有情报定义文件来执行terraform plan。
我們選擇一個選項以母語中文改述：
現在，我們將指定特定的信息定義文件並執行terraform plan。
我們可以確認變數部分已經正確地被替換為特定的信息並執行。
# terraform plan -var-file=xxxxxxxx.tfvars
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
+ create
Terraform will perform the following actions:
# aws_codecommit_repository.repository will be created
+ resource "aws_codecommit_repository" "repository" {
+ arn = (known after apply)
+ clone_url_http = (known after apply)
+ clone_url_ssh = (known after apply)
+ description = "This is the xxxxxxxx Sample App Repository"
+ id = (known after apply)
+ repository_id = (known after apply)
+ repository_name = "xxxxxxxx_test"
+ tags_all = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if
you run "terraform apply" now.
执行terraform apply时指定固有情报定义文件。
那么，现在我们将指定固有信息定义文件，并执行terraform apply。可以确认变量部分已经正确地替换为特定的信息进行了构建。
# terraform apply -var-file=xxxxxxxx.tfvars -auto-applove
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
+ create
Terraform will perform the following actions:
# aws_codecommit_repository.repository will be created
+ resource "aws_codecommit_repository" "repository" {
+ arn = (known after apply)
+ clone_url_http = (known after apply)
+ clone_url_ssh = (known after apply)
+ description = "This is the xxxxxxxx Sample App Repository"
+ id = (known after apply)
+ repository_id = (known after apply)
+ repository_name = "xxxxxxxx_test"
+ tags_all = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_codecommit_repository.repository: Creating...
aws_codecommit_repository.repository: Creation complete after 2s [id=xxxxxxxx_test]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
验证后将删除
不是一个持续的环境，而是为了验证而创建的环境，最后会将其删除。
在删除时，也指定了特定信息定义文件进行删除。
因为这次只有一个目标资源，所以没有指定“-target”。
# terraform destroy -var-file=xxxxxxxx.tfvars
aws_codecommit_repository.repository: Refreshing state... [id=xxxxxxxx_test]
Note: Objects have changed outside of Terraform
Terraform detected the following changes made outside of Terraform since the last "terraform apply":
# aws_codecommit_repository.repository has been changed
~ resource "aws_codecommit_repository" "repository" {
id = "xxxxxxxx_test"
+ tags = {}
# (7 unchanged attributes hidden)
}
Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using
ignore_changes, the following plan may include actions to undo or respond to these changes.
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
- destroy
Terraform will perform the following actions:
# aws_codecommit_repository.repository will be destroyed
- resource "aws_codecommit_repository" "repository" {
- arn = "arn:aws:codecommit:xxxxxxx:xxxxxxxx:xxxxxxxx_test" -> null
- clone_url_http = "https://git-codecommit.us-west-2.amazonaws.com/v1/repos/xxxxxxxx_test" -> null
- clone_url_ssh = "ssh://git-codecommit.us-west-2.amazonaws.com/v1/repos/xxxxxxxx_test" -> null
- description = "This is the xxxxxxxx Sample App Repository" -> null
- id = "xxxxxxxx_test" -> null
- repository_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx" -> null
- repository_name = "xxxxxxxx_test" -> null
- tags = {} -> null
- tags_all = {} -> null
}
Plan: 0 to add, 0 to change, 1 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
aws_codecommit_repository.repository: Destroying... [id=xxxxxxxx_test]
aws_codecommit_repository.repository: Destruction complete after 1s
Destroy complete! Resources: 1 destroyed.
最后
过去的验证工作没有很好地意识到变量化的重要性，但通过进行变量化处理，我们成功地改进了配置结构，以便在运行时不需要进行太多的修改。
现在，只需修改特定信息定义文件，志愿者也可以进行相同的验证。
虽然尚未进行调查，但我开始考虑将此专有信息定义文件保留在其他地方，而不是作为文件保留，并在运行时从那里进行补充的机制是否可行？
如果这样做，只需修改保存有专有信息的地方，而无需对文件进行任何修改，我认为我们将能够灵活地构建环境。
在考虑这方面的构想时，我希望能够与一起合作的志愿者进行讨论并推进研究。
