时间戳

首页 > 解决方案 > 在 Terraform 中，如何使用另一个部署的资源？

terraform - 在 Terraform 中，如何使用另一个部署的资源？

问题描述

Terraform v0.12.x

这是我的另一篇文章如何使用 Terraform 模块进行代码重用的后续问题？.

我有 2 个旨在重用其他模块的模块。我的目录结构是...

/terraform/
/terraform/blue/main.tf
/terraform/green/main.tf
/terraform/module_snapshot/main.tf
/terraform/module_ebs/main.tf

我想module_ebs/main.tf在两个部署之间重复使用，blue/main.tf并且green/main.tf. 它只是做

resource "aws_ebs_volume" "ebs" {
  availability_zone = "us-east-1a"
  snapshot_id       = "sn-123456abcded"
  size              = 500
  type              = "gp2"
  tags = {
    Name        = "test-ebs"
  }
}

output "ebs_id" {
  value       = aws_ebs_volume.ebs.id
  description = "Volume id of the EBS volume"
}

这个想法是使用（它有一个名为 的输出）green/main.tf创建一个 EBS 卷。module_ebs/main.tfebs_id

provider "aws" {
  region = "us-east-1"
}

terraform {
  required_version = ">= 0.12.17, < 0.13"
  backend "s3" {
    bucket = "my-terraform-states"
    key    = "test-modules/terraform.tfstate"
    region = "us-east-1"
  }
}

module "green_ebs" {
  source "../module_ebs"
}
output "green_ebs_id" {
  value = module.green_ebs.ebs_id
}

当我这样做时，我得到了所需的 EBS 卷

$ cd /terraform/green
$ terraform plan -out out.o
$ terraform apply "out.o"
green_ebs_id = "vol-123456abcdef"

现在我想blue/main.tf拍下 green 的 EBS 卷的快照，所以我做了

provider "aws" {
  region = "us-east-1"
}

terraform {
  required_version = ">= 0.12.17, < 0.13"
  backend "s3" {
    bucket = "my-terraform-states"
    key    = "test-modules/terraform.tfstate"
    region = "us-east-1"
  }
}

module "green" {
  source "../module"
}
module "snapshot" {
  source "../module_snapshot"
  green_ebs_id = module.green.green_ebs_id
}
output "blue_ebs_id" {
  value = module.blue_ebs.ebs_id
}

但是，当我运行上面的脚本时，它（当然）也会运行green/main.tf，这当然会破坏它的 EBS 卷并创建另一个，这不是我想要做的。

$ cd /terraform/blue
$ terraform plan -out out.o
# module.green.aws_ebs_volume.ebs will be destroyed
- resource "aws_ebs_volume" "ebs" {
...
}

如何在不破坏和重新创建它们的情况下使用另一个部署的资源？

标签： terraformterraform-provider-aws

解决方案

如何实现这一点有几种不同的变体，它们在考虑耦合、隐式关系与显式接口等方面有一些不同的权衡。

一种常见的方法是建立一些约定，通过这些约定，下游配置可以使用数据源间接找到由上游配置创建的对象。在您的情况下，这可能涉及为您的 EBS 卷设计一个两个配置都同意的标记方案，以便第二个配置可以找到由第一个配置创建的对象。

在第一个配置中：

resource "aws_ebs_volume" "ebs" {
  availability_zone = "us-east-1a"
  snapshot_id       = "sn-123456abcded"
  size              = 500
  type              = "gp2"
  tags = {
    Name = "production-appname"
  }
}

在第二种配置中：

data "aws_ebs_volume" "example" {
  filter {
    name   = "tag:Name"
    values = ["production-appname"]
  }
}

此示例中的约定是“名称”标签将具有值“生产应用程序名称”。对于您的目的而言，这可能不是完全正确的约定，但它展示了总体思路。然后第二个配置可以通过data.aws_ebs_volume.example.id.

正如我在开篇中提到的，上述方法进行了一些设计权衡：

  • 耦合度相对较低，因为第二个模块只需要之前创建的带有特定标签的 EBS 卷，因此您可以稍后重构您的系统，以便在不同的 Terraform 配置中创建 EBS 卷，或者使用除了 Terraform 之外的其他软件，对下游没有任何改变。
  • 但是，这两者之间的联系是隐含的，因为它依赖于共享约定而不是显式接口。这可能会使整个系统架构更难理解，除非您小心地将这些隐式约定记录在您的团队知道要查看的地方。

另一种变体是让您的上游配置将信息显式发布到专门用于该目的的配置存储中。例如，在 AWS 中，您可能会使用 AWS SSM Parameter Store，它在 Terraform 中使用aws_ssm_parameter托管资源类型和数据源表示：

resource "aws_ssm_parameter" "foo" {
  name  = "appname_ebs_volume_id"
  type  = "String"
  value = aws_ebs_volume.ebs.id
}

data "aws_ssm_parameter" "foo" {
  name = "appname_ebs_volume_id"
}

同样，这两种配置之间有一个共享约定，但约定是写入专门用于存储配置的位置，因此“集合点”（在本例中为 SSM 参数）在两个上游都清楚地表示和下游配置，保持相似级别的耦合但增加了明确性。

最后一个选项是利用大多数“真实”Terraform 配置将其状态快照保存在远程网络位置这一事实。数据源是一个特殊的terraform_remote_state数据源，它从远程位置读取状态快照并提取存储在那里的根模块输出，因此您可以在其他地方使用该数据。因此，您可以利用您在第一个模块中声明的输出来填充第二个模块中的资源配置，只要应用第二个模块的每个人都有足够的访问权限来从第一个模块中读取最新的状态快照。

我认为，第三种选择与第一种相反：

  • 耦合性很高，因为下游配置被配置为直接从其他配置的状态读取这个值。如果您稍后要重构并将 EBS 卷移动到不同的 Terraform 配置或使用其他软件对其进行管理，则需要编辑第二个配置以使其了解新源。
  • 但是，这可能是最明确的选项，因为 EBS 卷 ID 显然是有意从第一个配置中导出为在别处使用的值，而第二个配置准确描述了哪个子系统负责生成该值。

在所有情况下，这些选项都不是“正确”或“错误”，但我个人认为第二个选项是其他两个选项之间的一个很好的折衷方案，因为它缓和了两个相互竞争的设计考虑。选择哪一个将取决于您要描述的系统的目标和约束，但如果您的情况没有明确的“赢家”，我认为第二个是一个很好的默认值。

在 Terraform 文档指南Module Composition中有一些关于以灵活方式减少耦合和分解系统的技术的一般指导。它不是专门关于跨多个单独的 Terraform 配置拆分基础设施，但其中描述的技术可以帮助您进行设置，以便您可以更轻松地更改有关如何在以后分解系统的决定，以便您可以推迟添加多个单独的复杂性配置，直到您发现真正需要这样做。

推荐阅读