How to handle igoringa block which is a dynamic block in terraform but other process adds it outside terraform

Terraform
1

Hi all,

We have created some prod vmss with the following configuration which dynamically adds AD domain join extension which is inline with resource ad we made it a dynamic block because some of other VMSS using this module do not have the need for domain joining. Now we are enabling monitoring for these scale sets using Data Collection Rules and it adds azure monitor extension on the VMSS and also there are other extensions that might get added outside of terraform

In this scenario how can ignore the other extensions being represented as extension blocks in the plan but not ignore this domain join extension block.

resource “azurerm_windows_virtual_machine_scale_set” “vmss” {
name = var.name
location = var.location
resource_group_name = var.resource_group_name
admin_password = random_password.vmss_password.result
admin_username = var.admin_username
instances = var.instances
sku = var.sku
computer_name_prefix = var.computer_name_prefix
network_interface {
name = “nic-${var.name}”
primary = true
ip_configuration {
name = “internal”
primary = true
subnet_id = var.subnet_id
load_balancer_backend_address_pool_ids = var.load_balancer_backend_address_pool_ids
application_gateway_backend_address_pool_ids = var.application_gateway_backend_address_pool_ids
}
}
os_disk {
storage_account_type = “Standard_LRS”
caching = “ReadWrite”
disk_encryption_set_id = azurerm_disk_encryption_set.vmss.id
}
source_image_id = var.source_image_id != “” ? var.source_image_id : null
dynamic “source_image_reference” {
for_each = var.source_image_id != “” ? : var.source_image_reference
content {
publisher = source_image_reference.value.publisher
offer = source_image_reference.value.offer
sku = source_image_reference.value.sku
version = source_image_reference.value.version
}
}
dynamic “identity” {
for_each = var.identity != “” ? [var.identity] :
content {
type = var.identity
identity_ids = lower(var.identity) == “systemassigned” ? null : var.identity_ids
}
}

Adding inline extensions because we dont have to do manual upgrades on the instances.

The resource azurerm_virtual_machine_scale_set_extension creates the extension after the vmss is provisioned. And hence we would have to manually upgrade the instances for the script to run

dynamic “extension” {
for_each = var.enable_ad_domain_join_ou_path != null ? [var.enable_ad_domain_join_ou_path] :
content {
name = “{var.name}-addomainjoin" publisher = "Microsoft.Compute" type = "JsonADDomainExtension" type_handler_version = "1.3" settings = <<SETTINGS { "Name": "************", "OUPath": "{var.enable_ad_domain_join_ou_path}”,
“User”: “{data.azurerm_key_vault_secret.ad_join_user[0].value}@*************", "Restart": "true", "Options": "3" } SETTINGS protected_settings = <<PROTECTED_SETTINGS { "Password": "{data.azurerm_key_vault_secret.ad_join_password[0].value}”
}
PROTECTED_SETTINGS

}

}
zones = var.zones
platform_fault_domain_count = var.platform_fault_domain_count
single_placement_group = var.single_placement_group
overprovision = var.overprovision
tags = local.all_tags
lifecycle {
ignore_changes = [
tags,
]
}
}

We realize there is another resource with extension block and the reason we chose this inline block is we did not have to upgarde the instances and if use the extension resource we have to upgrade the instances. Ther might be a workaround for that but how can we safely tackle this situation as we have prod scalesets

Thanks and Regards
Divya

2

Hi Community

Bumping this up to see if anybody has any solution to this

3

@konasani.divya in your lifecycle, ignore the extension. On the first deployment, extensions would be deployed, it will ignore manually created extensions thereafter.

lifecycle {
  ignore_changes = [
    tags,
    extension
  ]
}
4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.