Я создавал ресурс реплики azurerm_postgresql_flexible_server
, но время ожидания команды Apply истекло. Однако ресурс все еще создан, и после попытки импортировать его в государственный план Terraform он пытается уничтожить и воссоздать его. Я раньше с этим не сталкивался, есть ли элегантный способ справиться с такой ситуацией? Я думаю, что основная проблема - это параметр create_mode... но это должна быть реплика, потому что я создаю реплику? Я не знаю, как обойти это требование.
Вот моя текущая конфигурация:
import {
to = azurerm_postgresql_flexible_server.main_replica[0]
id = "/subscriptions/something/.../Microsoft.DBforPostgreSQL/flexibleServers/some-resource-name"
}
resource "azurerm_postgresql_flexible_server" "main_replica" {
count = var.environment == "p" ? 1 : 0
name = "some-resource-name"
resource_group_name = var.resource_group_name
location = "centralus"
version = "12"
administrator_login = "postgres"
administrator_password = "xxxxxx"
zone = "2"
create_mode = "Replica"
source_server_id = azurerm_postgresql_flexible_server.main.id
storage_mb = var.postgresql_storage_mb
storage_tier = var.postgresql_storage_tier
sku_name = var.postgresql_sku_name
auto_grow_enabled = var.environment == "p" ? true : false
tags = merge(local.tags, { location = "centralus" })
lifecycle {
prevent_destroy = true
}
}
-/+ destroy and then create replacement
Terraform planned the following actions, but then encountered a problem:
# azurerm_postgresql_flexible_server.main_replica[0] must be replaced
# (imported from "/subscriptions/.../Microsoft.DBforPostgreSQL/flexibleServers/some-resource-name")
# Warning: this will destroy the imported resource
-/+ resource "azurerm_postgresql_flexible_server" "main_replica" {
administrator_login = "postgres"
+ administrator_password = (sensitive value)
auto_grow_enabled = true
~ backup_retention_days = 7 -> (known after apply)
+ create_mode = "Replica" # forces replacement
delegated_subnet_id = null
~ fqdn = "xxxxx.postgres.database.azure.com" -> (known after apply)
geo_redundant_backup_enabled = false
~ id = "/subscriptions/..../Microsoft.DBforPostgreSQL/flexibleServers/some-resource-name" -> (known after apply)
location = "centralus"
name = "some-resource-name"
+ private_dns_zone_id = (known after apply)
~ public_network_access_enabled = true -> (known after apply)
replication_role = null
resource_group_name = "..."
sku_name = "GP_Standard_D32ds_v4"
+ source_server_id = "/subscriptions/.../" # forces replacement
storage_mb = 2097152
storage_tier = "P40"
~ tags = {
"..." = "..."
}
version = "12"
zone = "2"
~ authentication {
+ administrator_login = (known after apply)
+ administrator_password = (known after apply)
+ auto_grow_enabled = (known after apply)
+ backup_retention_days = (known after apply)
+ create_mode = (known after apply)
+ delegated_subnet_id = (known after apply)
+ fqdn = (known after apply)
+ geo_redundant_backup_enabled = (known after apply)
+ id = (known after apply)
+ location = (known after apply)
+ name = (known after apply)
+ point_in_time_restore_time_in_utc = (known after apply)
+ private_dns_zone_id = (known after apply)
+ public_network_access_enabled = (known after apply)
+ replication_role = (known after apply)
+ resource_group_name = (known after apply)
+ sku_name = (known after apply)
+ source_server_id = (known after apply)
+ storage_mb = (known after apply)
+ storage_tier = (known after apply)
+ tags = (known after apply)
+ version = (known after apply)
+ zone = (known after apply)
} -> (known after apply)
}
Однако ресурс все еще создан, и после попытки импортировать его в государственный план Terraform он пытается уничтожить и воссоздать его. Я раньше с этим не сталкивался, есть ли элегантный способ справиться с такой ситуацией?
Чтобы справиться с этим типом сценария, в terraform есть блок под названием ignore_changes
, который используется для игнорирования изменений для заданных конкретных атрибутов.
В общем, функциональность аргумента create_mode такова:
Режим создания, который можно использовать для восстановления или репликации существующих серверов. Изменение этих значений приводит к созданию нового гибкого сервера PostgreSQL.
Я использовал блок ignore_changes
, передав create_mode
и source_server_id
, как показано ниже. Это означает, что изменения не будут применены к этим атрибутам и будут работать как обычно.
lifecycle {
prevent_destroy = true
ignore_changes = [
create_mode,
source_server_id
]
}
Полный код:
resource "azurerm_postgresql_flexible_server" "main_replica" {
name = "replicaservers"
resource_group_name = data.azurerm_resource_group.example.name
location = "centralus"
version = "12"
administrator_login = "user"
administrator_password = "xxx"
zone = "1"
create_mode = "Replica"
source_server_id = data.azurerm_postgresql_flexible_server.example.id
storage_mb = 32768
storage_tier = "P30"
sku_name = "GP_Standard_D4s_v3"
lifecycle {
prevent_destroy = true
ignore_changes = [
create_mode,
source_server_id
]
}
}
Обратитесь на Github по соответствующей проблеме.