карта terraform и переменные объекта в качестве входных

Question

Возникла проблема с вводом командной строки для любого строкового атрибута внутри переменной карты / объекта. приведенная ниже конфигурация работает с командой ниже. Но в тот момент, когда я использую любой строковый атрибут внутри объектной переменной. это не удается

terraform plan -var='storageProfile2={"storage_mb":102400,"backup_retention_days":15,"geo_redundant_backup_enabled":false}'

//main.tf
resource "azurerm_postgresql_server" "dmcdevops_postgress" {
  name                          = "pstgressdb101" 
  location                      = azurerm_resource_group.dmc_rg_creation.location
  resource_group_name           = azurerm_resource_group.dmc_rg_creation.name
  sku_name                      = "GP_Gen5_4"
  backup_retention_days         = var.storageProfile2.backup_retention_days
  storage_mb                    = var.storageProfile2.storage_mb
  geo_redundant_backup_enabled  = var.storageProfile2.geo_redundant_backup_enabled 
  administrator_login           = "sdfgsgfsg"
  administrator_login_password  = "H@Sh1CoR3!"
  version                       = "11"
  ssl_enforcement_enabled       = true

}
//variables.tf
variable "storageProfile2" {
default = {
    storage_mb                      = 102400
    backup_retention_days           = 15
    geo_redundant_backup_enabled    = false
  }

  type = object(
    {
        storage_mb                    = number
        backup_retention_days         = number
        geo_redundant_backup_enabled  = bool
   }
      )
} 

Конфигурация ниже не работает. Я просто добавилadministrator_login как строковый атрибут к объектной переменной. terraform plan and apply работает со значениями по умолчанию.

terraform plan -var='storageProfile2={"storage_mb":102400,"backup_retention_days":15,"geo_redundant_backup_enabled":false,"administrator_login":"pgadmin1223"}'

//main.tf 
resource "azurerm_postgresql_server" "dmcdevops_postgress" {
  name                          = "pstgressdb101" 
  location                      = azurerm_resource_group.dmc_rg_creation.location
  resource_group_name           = azurerm_resource_group.dmc_rg_creation.name
  sku_name                      = "GP_Gen5_4"
  backup_retention_days         = var.storageProfile2.backup_retention_days
  storage_mb                    = var.storageProfile2.storage_mb
  geo_redundant_backup_enabled  = var.storageProfile2.geo_redundant_backup_enabled 
  administrator_login           =  var.storageProfile2.administrator_login 
  administrator_login_password  = "H@Sh1CoR3!"
  version                       = "11"
  ssl_enforcement_enabled       = true

}

//varibale.tf
variable "storageProfile2" {
default = {
    storage_mb                      = 102400
    backup_retention_days           = 15
    geo_redundant_backup_enabled    = false
    administrator_login             = "pgadmin"
  }

  type = object(
    {
        storage_mb                    = number
        backup_retention_days         = number
        geo_redundant_backup_enabled  = bool
        administrator_login           = string 
   }
      )
}

Сообщение об ошибке

Answer 1

Поскольку вторая конфигурация работает со значениями по умолчанию для переменной, проблема не в конфигурации, terraform apply -varдолжно быть проблема. Это очень сложно сделать правильно, и у него есть ряд проблемных взаимодействий с правилами синтаксического анализа оболочки, которые могут вас сбить с толку.

Я считаю, что использование файлов.tfvars намного более надежно, и я больше не пытаюсь заставить -var работать для моей работы с Terraform.

terraform.tfvars:

storageProfile2 = {
  storage_mb                      = 102400
  backup_retention_days           = 15
  geo_redundant_backup_enabled    = false
  administrator_login             = "pgadmin1223"
}

Установите terraform.tfvars, как указано выше, в том же каталоге, а затем запустите terraform plan а также terraform applyбез -var. Это должно решить вашу проблему.

Оригинальный ответ

В поставщике azurerm есть несколько существенных изменений, которые должны быть обратно совместимы, но, вероятно, вызывают здесь проблему.

geo_redundant_backup является устаревшим атрибутом начиная с v2.7.0 или v2.10.0 в зависимости от того, какой ресурс базы данных вы используете. Вместо этого вы должны использовать geo_redundant_backup_enabled и указать его как логическое значение (тип bool). Я подозреваю, что обратная совместимость не совсем надежна.

Блоки storage_profile также устарели, и все их атрибуты теперь находятся на верхнем уровне соответствующего.

Примеры в документации поставщика azurerm, использующие storage_profile неверны и это:

storage_profile {
  storage_mb            = var.storageProfile2.storageMb
  backup_retention_days = var.storageProfile2.backupRetentionDays
  geo_redundant_backup  = var.storageProfile2.geoRedundantBackup
}

Следует переписать как (прямые свойства ресурса, а не внутри блока):

storage_mb                    = var.storageProfile2.storageMb
backup_retention_days         = var.storageProfile2.backupRetentionDays
geo_redundant_backup_enabled  = var.storageProfile2.geoRedundantBackup

И ваша storageProfile2 декларация переменная должна быть обновлена, чтобы установить тип geoRedundantBackup к BOOL:

variable storageProfile2 {
  default = {
    storageMb = 102400
    backupRetentionDays = 15
    geoRedundantBackup  = false
  }
  type = object({ storageMb=number, backupRetentionDays=number, geoRedundantBackup=bool })
}

Поскольку провайдер azurerm v2.7.0 был выпущен 23 апреля 2020 г., включая следующие изменения:

• azurerm_postgres_server - все свойства в storage_profileблок перенесен на верхний уровень (#6459)
• azurerm_postgres_server - следующие свойства были переименованы и изменены на логический тип: ssl_enforcement к ssl_enforcement_enabled, geo_redundant_backup к backup_geo_redundant_enabled, а также auto_grow к auto_grow_enabled(#6459)

Так как провайдер azurerm v2.10.0 был выпущен 12 мая, дополнительный storage_profile 2020 был сглажен:

• azurerm_mariadb_server - все свойства в storage_profileблок перенесен на верхний уровень (#6865)
• azurerm_mysql_server - все свойства в storage_profileблок перенесен на верхний уровень (#6833)
• azurerm_mariadb_server - следующие свойства были переименованы и изменены на логический тип: ssl_enforcement к ssl_enforcement_enabled, geo_redundant_backup к geo_redundant_backup_enabled, а также auto_grow azurerm_mysql_server - поддержка create_modeсвойство, позволяющее создавать реплики, восстановление на определенный момент времени и географическое восстановление (#6833)
• azurerm_mysql_server - следующие свойства были переименованы и изменены на логический тип: ssl_enforcement к ssl_enforcement_enabled, geo_redundant_backup к geo_redundant_backup_enabled, а также auto_grow к auto_grow_enabled (#6833)

В сторону: Стиль кода

Обычный стиль кода в Terraform:

• Использовать snake_case вместо того camelCase (не формализовано, но каждый провайдер следует этому, как и примеры)
• Цитируйте имена верхнего уровня, такие как имена ресурсов и переменных.
• Выровняйте знаки равенства в группах (без нескольких разрывов строки между ними)

variable "storage_profile_2" {
  default = {
    storage_mb                   = 102400
    backup_retention_days        = 15
    geo_redundant_backup_enabled = false
  }
  type = object(
    {
      storage_mb                   = number
      backup_retention_days        = number
      geo_redundant_backup_enabled = bool
    }
  )
}

И назначьте атрибуты следующим образом

storage_mb                   = var.storage_profile_2.storage_mb
backup_retention_days        = var.storage_profile_2.backup_retention_days
geo_redundant_backup_enabled = var.storage_profile_2.geo_redundant_backup_enabled

Чем более согласован код Terraform в глобальном масштабе, тем легче будет всем нам, практикующим, если нам когда-нибудь понадобится работать над чужим кодом.

Answer 2

Как указал Мартин. Проблема заключалась в оболочке в стиле unix на оболочке питания. После выхода из двойных кавычек это сработало. Правильный синтаксис для Power Shell:

terraform plan -var='postgress={"storage_mb":102400,"backup_retention_days":15,"geo_redundant_backup_enabled":false,"administrator_login":\"pgadmin1223\"}'

Кроме того, я согласен, что лучше использовать tfvars вместо входных параметров, особенно если у вас много входных данных для терраформ.