c# - 基于容器的函数应用程序在被 CORSSettingsChanged 和 AppSettingsChange 回收后丢失了自定义应用程序设置

Question

我们团队设置了一个ansible-playbook来部署Azure Function作为引用:Linux-container-from-ACR-with-private-endpoint 。我们使用用户分配的身份从 ACR 中提取函数应用程序镜像。我们使用 Ansible 自动化该任务，如下所示:

- name: Force Login using identity
  command: az login --identity

- name: Get function app identity's clientId
  command: az identity show --resource-group "{{ functionapp_resource_group }}" --name "{{ functionapp_user_identity }}" --query clientId --output tsv
  register: identity

- name: Config properties
  command:
    az resource update --resource-group "{{ functionapp_resource_group }}" --name "{{ functionapp_name }}/config/web"
    --set "{{ item }}" --resource-type "Microsoft.Web/sites/config"
  with_items:
    - "properties.acrUserManagedIdentityID={{ identityId.stdout }}"
    - "properties.acrUseManagedIdentityCreds=true"

- name: Config app settings
  command:
    az function app config appsettings set --name "{{ functionapp_name }}"
    --resource-group "{{ functionapp_resource_group }}" --settings "{{ item }}"
  with_items:
    - "WEBSITES_ENABLE_APP_SERVICE_STORAGE=false"
    - "SubscriptionExpiredSchedule=* 30 * * * *"
    - "KEY=VALUE..."

- name: Deploy the function app
  command:
    az function app config container set --name "{{ functionapp_name }}"
    --resource-group "{{ functionapp_resource_group }}"
    --docker-custom-image-name "{{ docker_registry_host }}/{{ image_name }}:{{ image_tag }}"
    --docker-registry-server-URL "{{ docker_registry_host }}"

刚部署时一切看起来都很好。正确找到2个定时器触发的函数。从我的应用设置中成功检测到 crontab 字符串 "* 30 * * * *":

但过了一会儿，Application Insight 的日志不断显示 找到 1 个函数 和 加载 0 个函数:

2023-01-13T10:15:47.434 [Information] 1 functions found
2023-01-13T10:15:47.434 [Information] 0 functions loaded
2023-01-13T10:15:48.352 [Information] Host Status: {
  "id": "<<function app name>>",
  "state": "Running",
  "version": "4.14.0.0",
  "versionDetails": "4.14.0+fc14864b4fc2a095f8cd92c7f0ca338dbeabd430",
  "platformVersion": "99.0.10.762",
  "instanceId": "b42e8886acdb8a5a6fd64d57ead538cc2765d75cbbc61a37cab2678ae174bea0",
  "computerName": "lw1sdlwk000014",
  "processUptime": 1677391,
  "functionAppContentEditingState": "Unknown",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "3.17.0"
  }
}

函数应用程序已关闭。返回配置，我的所有自定义应用程序设置都丢失了:

虽然第一次用 CI 工具一直失败，但是当我第二次手动触发 CI 工具时，它工作正常，并且没有再次失败。这太奇怪了。我是否错误地设置了任何配置，导致函数应用程序关闭并且首次部署时应用程序设置丢失？

--- 更新 ---

我发现函数应用因由于 CORSSettingsChanged 和 CORSSettingsChanged = Microsoft.Web.Hosting.CorsSettings 的回收容器而被重新部署。部署后，我所有的自定义配置都丢失了。此外，我发现由于 AppSettingsChange 和 isMainSite = True 而回收容器也会导致我的自定义配置丢失。这是日志:

2023-01-17T02:29:27.044Z INFO - Pull Image successful, Time taken: 1 Minutes and 7 Seconds
2023-01-17T02:29:27.485Z INFO - Starting container for site
2023-01-17T02:29:27.485Z INFO - docker run -d --expose=80 --name <<functionapp name>>_0_4b241f6f -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=<<functionapp name>> -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=<<functionapp name>>.azurewebsites.net -e WEBSITE_INSTANCE_ID=5b6600aecfae7b5eb1290df18fcc42fb8bc88d7b721b9274087658bfa90a5d85 -e WEBSITE_USE_DIAGNOSTIC_SERVER=False <<my acr>>.azurecr.io/<<name>>:<<tag>>

2023-01-17T02:29:27.485Z INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2023-01-17T02:29:29.726Z INFO - Initiating warmup request to container <<functionapp name>>_0_4b241f6f_msiProxy for site <<functionapp name>>
2023-01-17T02:29:29.874Z INFO - Container <<functionapp name>>_0_4b241f6f_msiProxy for site <<functionapp name>> initialized successfully and is ready to serve requests.
2023-01-17T02:29:29.874Z INFO - Initiating warmup request to container <<functionapp name>>_0_4b241f6f for site <<functionapp name>>
2023-01-17T02:29:39.659Z INFO - Container <<functionapp name>>_0_4b241f6f for site <<functionapp name>> initialized successfully and is ready to serve requests.
2023-01-17T02:37:22.159Z INFO - Recycling container because of CORSSettingsChanged and CORSSettingsChanged = Microsoft.Web.Hosting.CorsSettings
2023-01-17T02:37:28.816Z INFO - Pulling image: <<my acr>>.azurecr.io/<<name>>:<<tag>>
2023-01-17T02:37:29.124Z INFO - <<tag>> Pulling from <<name>>
2023-01-17T02:37:29.126Z INFO - Digest: sha256:49a690b289cd8a80d7104891a3ae5db38b8d6529f73b9b536c147d81a94a499e
2023-01-17T02:37:29.126Z INFO - Status: Image is up to date for <<my acr>>.azurecr.io/<<name>>:<<tag>>
2023-01-17T02:37:29.129Z INFO - Pull Image successful, Time taken: 0 Minutes and 0 Seconds
2023-01-17T02:37:29.188Z INFO - Starting container for site
2023-01-17T02:37:29.189Z INFO - docker run -d --expose=80 --name <<functionapp name>>_1_bf06fa66 -e WEBSITE_SITE_NAME=<<functionapp name>> -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=<<functionapp name>>.azurewebsites.net -e WEBSITE_INSTANCE_ID=5b6600aecfae7b5eb1290df18fcc42fb8bc88d7b721b9274087658bfa90a5d85 -e WEBSITE_USE_DIAGNOSTIC_SERVER=False <<my acr>>.azurecr.io/<<name>>:<<tag>>

2023-01-17T02:37:29.189Z INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2023-01-17T02:37:31.739Z INFO - Initiating warmup request to container <<functionapp name>>_1_bf06fa66_msiProxy for site <<functionapp name>>
2023-01-17T02:37:31.819Z INFO - Container <<functionapp name>>_1_bf06fa66_msiProxy for site <<functionapp name>> initialized successfully and is ready to serve requests.
2023-01-17T02:37:31.820Z INFO - Initiating warmup request to container <<functionapp name>>_1_bf06fa66 for site <<functionapp name>>
2023-01-17T02:37:40.895Z INFO - Container <<functionapp name>>_1_bf06fa66 for site <<functionapp name>> initialized successfully and is ready to serve requests.

--- 更新 ---

我发现不仅容器部署有这个问题，而且我切换到zip部署后仍然出现这个问题。因此，这可能与过时的 Terraform 版本 (v1.0.4) 有关，而不是与 Azure 上的 Docker 代理有关。另外，我的函数应用程序使用依赖注入(inject)，但我认为它不太可能与之有任何关系。这是 Terrafrom 脚本:

resource "azurerm_app_service_plan" "B1" {
  name                = "plan-B1"
  resource_group_name = azurerm_resource_group.mygroup.name
  location            = azurerm_resource_group.mygroup.location
  kind                = "Linux"
  reserved            = true
  sku {
    tier = "Basic"
    size = "B1"
  }
}

resource "azurerm_function_app" "myapp" {
  name                = format("myapp-%s", terraform.workspace)
  resource_group_name = azurerm_resource_group.mygroup.name
  location            = azurerm_resource_group.mygroup.location
  os_type = "linux"
  version = "~4"

  storage_account_name       = azurerm_storage_account.myapp.name
  storage_account_access_key = azurerm_storage_account.myapp.primary_access_key

  app_service_plan_id = azurerm_app_service_plan.B1.id

  identity {
    type = "SystemAssigned"
  }

  app_settings = {
    APPINSIGHTS_INSTRUMENTATIONKEY = "${azurerm_application_insights.myapp.instrumentation_key}"
    FUNCTIONS_WORKER_RUNTIME = "dotnet"
  }

  site_config {
    linux_fx_version = "dotnet|6"
    always_on = true
    cors {
      allowed_origins = []
      support_credentials = false
    }
  }
}

此外，我发现有一种称为配置漂移的机制，它强制资源保持与 Terraform 中相同的状态。由于我们的应用程序设置取决于环境，因此我们使用 Ansible 来设置每个肯定会更改状态的应用程序设置。我高度猜测这是此问题的根本原因。

• 引用1:https://www.maxivanov.io/ignore-azure-functions-application-settings-change-in-terraform/
• 引用2:https://developer.hashicorp.com/terraform/tutorials/state/resource-drift

我还在 Terraform 的论坛中开了一个主题:https://discuss.hashicorp.com/t/is-appsettings-disappearance-of-azure-function-relates-to-configuration-drift

Answer 1

基于异常由于AppSettingsChange和isMainSite = True而回收容器以及在Docker Azure Function App的上下文中，我发现很少有来自用户@<的类似异常和上下文的现有已解决问题em>mpseidel 和 @Piotr 可能有助于问题调查分析。

GitHub-Azure-Functions-Host 中的第一个案例 3500类似的异常(exception)是在基于 Docker Linux 的 Node JS Azure Function App 上启动时出现的，但它在本地成功运行，并找到了解决方案，选择操作系统作为 Docker 并使其正常工作。

第二种情况在基于 Azure Linux 的 Function-Docker 部署 SO # 61567697 的上下文中具有类似的异常.

我可以看到您已经在 Azure Functions 问题的 GitHub 官方页面中提出了分类请求，如果任何社区成员面临类似问题，这里是请求 -# 2327标记为bug并等待分类。