Переменная Terraform для назначения с помощью функции - PullRequest
0 голосов
/ 17 февраля 2020
variable "cidr" {
  type = map(string)
  default = {
      development = "x.1.0.0/16"
      qa = "x.1.0.0/16"
      default = "x.1.0.0/16"
  }
} 
variable "network_address_space" {
  default = lookup(var.cidr, var.environment_name,"default")
}

Получаю сообщение об ошибке «Ошибка: вызовы функций не разрешены»

variable "subnet_address_space": cidr_subnet2_address_space = cidrsubnet(var.network_address_space,8,1)

Ответы [ 2 ]

1 голос
/ 18 февраля 2020

Как указано в Интерполировать переменные внутри .tfvars для определения другой переменной персоналом Hashicorp, она предназначена для констант по дизайну.

Входные переменные - это передаваемые постоянные значения в модуль root, и поэтому они не могут содержать интерполяции или другие выражения, которые не приводят к постоянному значению.

Мы не можем использовать переменные в бэкэнде, как в Использование переменных в бэкэнде terraform блок конфигурации .

Это то, к чему мы, пользователи Terraform, споткнулись в какой-то момент, я полагаю.

0 голосов
/ 18 февраля 2020

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

Механизм default позволяет нам подставлять значение, когда вызывающая сторона не указывает его, но поскольку переменные предназначены для получения данных в модуль извне, не имеет смысла устанавливать значение по умолчанию на что-то из внутри этого модуля: это может привести к тому, что результат будет потенциально тем, что вызывающий модуль никогда не сможет указать, потому что у него нет доступа к необходимым данным.

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

var "environment_name" {
  type = string
}

var "environment_default_cidr_blocks" {
  type = map(string)
  default = {
      development = "10.1.0.0/16"
      qa          = "10.2.0.0/16"
  }
}

var "override_network_range" {
  type    = string
  default = null   # If not set by caller, will be null
}

locals {
  subnet_cidr_block = (
    var.override_network_range != null ?
    var.override_network_range :
    var.environment_default_cidr_blocks[var.environment_name]
  )
}

В другом месте в модуле вы можете использовать local.subnet_cidr_block для ссылки на окончательный выбор блока CIDR, независимо от того, был ли он установлен явно вызывающим абонентом или путем поиска в таблице значений по умолчанию.

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

output "subnet_cidr_block" {
  value = local.subnet_cidr_block
}
...