我想看看我们的Terraform代码是否可以以编程方式找出下一个用于VPC的CIDR。
VPC CIDR范围172.20.1-255.0 / 24
到目前为止，我有：
data "aws_vpcs" "existing_vpcs" {
}
data "aws_vpc" "details" {
count = "${length(data.aws_vpcs.existing_vpcs.ids)}"
id = "${element(data.aws_vpcs.existing_vpcs.ids, count.index)}"
}
output "all_vpc_ids" {
value = "${data.aws_vpcs.existing_vpcs.ids}"
}
output "current_vpc_cidrs" {
value = "${data.aws_vpc.details.*.cidr_block}"
}
output "Current VPCs" {
value = "${length(data.aws_vpcs.existing_vpcs.ids)}"
}
这将输出如下内容：
Outputs:
Current VPCs = 8
all_vpc_ids = [
vpc-xxx,
vpc-xxx,
]
current_vpc_cidrs = [
172.20.1.0/24,
172.20.5.0/24,
]
我想将变量设置为172.20.2.0/24，因为从技术上讲，它是下一个可用的变量。
最佳答案
Terraform的数据源功能旨在获取不经常更改的数据，并且（通常）仅由于代表操作员的故意行为而更改的数据。不幸的是，下一个“可用”的CIDR块不是一个好的选择，因为创建下一个VPC的行为会改变结果，导致最终的配置永远不会收敛。
相反，Terraform希望这种分配会明确进行。在这种情况下，这意味着为您的网络建立一个明确的编号约定，然后您可以在Terraform配置中对其进行描述，从而允许Terraform根据配置中已有的信息来查找或计算合适的VPC。
例如，AWS用户经常定义一个映射，以便在中央表中为每个区域和区域可用区分配一个数字（例如，直接在配置中提供地图值，或通过数据源访问的外部系统），然后为可以通过查询该表来发现VPC或子网。
如果您的系统具有定期创建和销毁网络的异常特征，而与AWS区域和可用区域没有直接关系，我建议您使用Terraform之外的一些外部软件来管理子网的分配，然后通过由将该软件作为input variable导入Terraform。这样，可以将该决定记录在该外部系统中（例如在数据库中），并在以后需要更改时再次调用。
具有异常用例的用户有时还发现将其配置的主要部分分解为可重用模块，然后动态生成（使用预处理工具）最小的根模块，该最小的根模块使用一些数据或决策调用该模块是更好的选择在Terraform之外。这种用法不在Terraform的主要用例之内，但可以使它起作用。对于非常动态的环境，Terraform可能不是适合该工作的工具。