Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web app service resource keeps detecting but not applying changes to 'docker_registry_url' attribute #22548

Closed
1 task done
eehret opened this issue Jul 16, 2023 · 3 comments · Fixed by #23303
Closed
1 task done

Comments

@eehret
Copy link

eehret commented Jul 16, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.5.3

AzureRM Provider Version

3.65.0

Affected Resource(s)/Data Source(s)

azurerm_linux_web_app and possibly azurerm_windows_web_app

Terraform Configuration Files

Sorry, I don't have a full config that I can share. But this is how the relevant sections of the resource appear:

resource "azurerm_linux_web_app" "app_service" {
  count               = (var.app_service_os == "linux" ? 1 : 0)
  location            = var.location
  name                = local.app_service_name
  resource_group_name = data.azurerm_resource_group.rg.name
  service_plan_id     = var.app_service_plan_id

  site_config {
    always_on = var.always_on

    application_stack {
      docker_image_name   = "${local.container_image_name}:${local.container_image_version}"
      docker_registry_url = local.container_registry_url
    }

    container_registry_use_managed_identity = local.site_config["container_registry_use_managed_identity"]
    ftps_state                              = local.site_config["ftps_state"]
    http2_enabled                           = local.site_config["http2_enabled"]
    minimum_tls_version                     = local.site_config["minimum_tls_version"]
    vnet_route_all_enabled                  = local.site_config["vnet_route_all_enabled"]
  }

  app_settings                  = local.common_app_settings
  client_affinity_enabled       = var.client_affinity_enabled
  https_only                    = true
  public_network_access_enabled = false

  identity {
    type = "SystemAssigned"
  }

  virtual_network_subnet_id = var.outbound_subnet_id
  tags                      = local.app_service_tags

  # Mounts each specified File Share from the provided storage account to the specified path.
  dynamic "storage_account" {
    for_each = local.mounts
    content {
      name         = "${storage_account.value["fileshareName"]}-${var.instance}-Connection"
      type         = "AzureFiles"
      account_name = var.storage_account.name
      access_key   = var.storage_account.primary_access_key
      share_name   = storage_account.value["fileshareName"]
      mount_path   = storage_account.value["path"]
    }
  }

  lifecycle {
    ignore_changes = [
      site_config[0].application_stack[0].docker_image_name, # We expect this to change when teams push their real containers, so ignore those changes
      site_config[0].application_stack[0].docker_image,      # Similar as above, but this property is deprecated.  Will be removed entirely in future.
      site_config[0].application_stack[0].docker_image_tag,  # Similar as above, but this property is deprecated.  Will be removed entirely in future.
      app_settings,
      sticky_settings,
      tags["hidden-link: /app-insights-instrumentation-key"],
      tags["hidden-link: /app-insights-resource-id"]
    ]
  }
}

Debug Output/Panic Output

n/a

Expected Behaviour

Terraform should apply the docker_registry_url as configured in the site_config block and not keep reporting the same change on subsequent apply.

Actual Behaviour

For an existing resource that was created with an earlier version of the provider:

the docker_registry_url keeps getting reported as a change on subsequent apply and never seems to actually apply the value.

I'm not sure if this is happening because of what I'm doing in the ignore_changes block. That is there because this is a module for an infrastructure creation pipeline where I'm setting an initial sample container workload. Then a developer running their own separate app deployment pipeline will go and deploy some other application container later, and I don't my own infrastructure pipeline to care about that change when it happens later.

Note that this doesn't seem reproducible when doing the original creation and subsequent applies with azurerm 3.65.0.
Only seems to be an issue when the state came from an earlier version of the provider.

UPDATE: Confirmed that this seems to be somehow caused by the ignore_changes. It appears that strange things happen when changes to some of the related properties are being ignored, then it does not apply the change to docker_registry_url

Steps to Reproduce

terraform apply (multiple times)

Important Factoids

No response

References

No response

@eehret eehret changed the title Web app service resource keeps detecting but not writing changes to 'docker_registry_url' attribute Web app service resource keeps detecting but not applying changes to 'docker_registry_url' attribute Jul 16, 2023
@xiaxyi
Copy link
Contributor

xiaxyi commented Jul 17, 2023

Thanks @eehret for raising this issue, after created the web app with docker registry url set in site_config, have you checked the app_setting block to see if the docker registry URL is saved in it? If not, the fix is included in the pr:#22484, you can track it for a status.

@Fred-MabS
Copy link

Fred-MabS commented Sep 15, 2023

Hi,
I think I have a quite similar problem.
I recently upgraded my code to use the latest version of the provider (3.73.0). Before this I was using v3.38

I use my own private Azure container registry (I think it is worth to mention because I can not reproduce the problem with the dockerhub).

I have applied several times the following configuration:

  site_config {
    application_stack {
      # docker_image_name   = "nginx:latest"
      # docker_registry_url = "https://index.docker.io"
      docker_image_name   = "${var.image}:${var.tag}"
      docker_registry_url = "https://${var.acr_name}.azurecr.io"
    }
  }

I have checked the content of the tfstate file, this is not correctly updated :

                "application_stack": [
                  {
                    "docker_image": "",
                    "docker_image_name": "MYREGISTRY.azurecr.io/MYIMAGE:latest",
                    "docker_image_tag": "",
                    "docker_registry_password": "",
                    "docker_registry_url": "https://index.docker.io",
                    "docker_registry_username": "",
                    ...
                  }
                ],

If I switch the comments and use nginx from the dockerhub, the tfstate file is correctly updated, and any additionnal tf plan or tf apply tells there is nothing to change.

Post note: if I update the registry, image and tag parameters in the Azure Portal, I now have a correct situation.

Post post note: after an additional test, I noticed that after having my webapp correctly using my private acr/image:tag, if I switch back to nginx it won't update correctly. It seems to me azure does not take the parameters we send.

Best regards,
Fred

Copy link

github-actions bot commented May 6, 2024

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.