Terraform следующий доступный CIDR на AWS

Question

Я хотел бы узнать, возможно ли для нашего кода Terraform программно определить следующий CIDR, который будет использоваться для VPC.

Диапазон CIDR VPC 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, поскольку она технически следующая.

Answer 1

Если я правильно понял ваш вопрос. Вы можете использовать функцию cidrnet с count. Для автоматического выбора из сетевого адреса VPC.

resource "aws_subnet" "private" {
 count         = "${var.pvt_subnet_count}"
 cidr_block    = "${cidrsubnet(var.network_address_space,8,count.index + 1)}"
 vpc_id        = "${aws_vpc.ozonevpc.id}"}

Answer 2

Может быть, это может помочь вам в вашем квесте:

https://github.com/afaleti/vpc-free

https://www.terraform.io/docs/configuration-0-11/interpolation.html#cidrsubnet-iprange-newbits-netnum-

Answer 3

Функция источников данных Terraform предназначена для выборки данных, которые изменяются нечасто и (обычно) изменяются только в результате преднамеренных действий от имени оператора. Следующий «доступный» блок CIDR, к сожалению, не является подходящим кандидатом для этого, поскольку сам процесс создания next VPC изменит результат, в результате чего полученная конфигурация никогда не сойдется.

Вместо этого Terraform ожидает, что такого рода назначение будет выполнено явно. В этой ситуации это будет означать установление явного соглашения о нумерации для ваших сетей, которое вы затем сможете описать в конфигурации Terraform, что позволит Terraform найти или рассчитать подходящий VPC на основе информации, уже имеющейся в конфигурации.

Например, пользователи AWS часто определяют отображение таким образом, что каждому региону и региональной зоне доступности присваивается номер в центральной таблице (например, значение карты непосредственно в конфигурации или внешняя система, доступ к которой осуществляется через источник данных), а затем адрес для VPC или подсети может быть обнаружен путем обращения к этой таблице.

Если ваша система имеет более необычную характеристику регулярного создания и разрушения сетей, не имеющих прямого отношения к регионам AWS и зонам доступности, я бы рекомендовал использовать некоторое внешнее программное обеспечение за пределами Terraform для управления назначением подсетей, а затем передавать решение, принятое этим программным обеспечением в Terraform в качестве входной переменной . Таким образом, решение может быть записано в этой внешней системе (например, в базе данных) и повторно вызвано позже, если необходимо применить изменения.

Пользователи с необычными вариантами использования также иногда находят, что лучше разложить основную часть своей конфигурации в модуль многократного использования, а затем динамически генерировать (используя инструмент предварительной обработки) минимальный корневой модуль, который вызывает этот модуль с использованием некоторых данных. или решения, принятые за пределами Terraform. Такой вид использования не входит в основные варианты использования Terraform, но его можно заставить работать. Для очень динамических сред Terraform может оказаться неподходящим инструментом для работы.