Azure-docs: 不应使用 WEBSITE_CONTENTSHARE 来支持

创建于 2019-08-04  ·  70评论  ·  资料来源: MicrosoftDocs/azure-docs

你好呀,
我提出了支持案例 119071321000245,支持工程师建议在 ARM 部署中根本不应该设置 WEBSITE_CONTENTSHARE,因为它应该由函数运行时管理。 不设置它似乎可以避免在重新部署期间可能发生意外交换的问题。 (详情见案例信息)

如果这是官方指南,我们是否应该在此页面上添加注释以让人们知道?

另外,在导出 AppService 模板时是否应该排除 WEBSITE_CONTENTSHARE? (通过门户或 PowerShell)


文件详情

请勿编辑此部分。

Pri1 assigned-to-author azure-functionsvc product-issue triaged

最有用的评论

@paulbatum

  • 在通过 ARM 初始创建资源时,应设置 WEBSITE_CONTENTSHARE。 但是,初始创建后,应从 ARM 模板中省略此设置(因为如果包含它,ARM 模板的进一步执行可能会导致意外的内容交换)

您确实意识到这种破坏 ARM 模板的目的,对吗?

这种行为正在得到修复,但可能需要 1-2 个月的时间才能消除。 因此,与此同时,我上面分享的指南(您最初设置它然后从 ARM 模板中删除它)是适用的。

这里最终的预期配置是什么?
一旦所有这些实际部署完毕,我们能否在Azure/app-service-announcements 上发布具有正确配置和官方时间表

所有70条评论

@danielstocker 非常感谢您引起我们的注意。 我已将此分配给服务负责人以进行进一步调查,并会在我们更加清晰时进行更新。

@Mike-Ubezzi-MSFT @mike-urnun-msft

感谢您查看这个。

你需要更多信息来推进这个吗?

@danielstocker你能提供更多关于导致这一发现的原始问题的背景吗? 我不确定正确理解不正确设置它的含义(您提到的unintentional swap

@ggirard07

没问题。 让我总结一下。
这最初出现是因为我们的文档指出 WEBSITE_CONTENTSHARE 是必需的。 (请参阅此处:https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

如果我们从 Marketplace 导出一个 Functions 模板(最后一页上的导出模板),我们会得到 WEBSITE_CONTENTSHARE 作为标准的应用程序设置。 如果我们使用它,那么可能会发生以下情况。

image

1)我们部署一个ARM模板,得到一个有两个槽的空函数
2)我们部署到暂存槽
3)我们交换以使内容在生产中可用
4) 意外交换,因为重新部署了 ARM 模板并重新应用了应用程序设置(这甚至发生在增量 ARM 部署期间,因为 appsettings 资源总是覆盖并重置 WEBSITE_CONTENTSHARE 设置)
5) 部署例程现在将新代码部署到暂存槽,我们的生产槽是空的,而不是包含以前的版本。 我们的生产函数“无意”下降

在这种特殊情况下,客户随后指向这篇文章https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

这表明该设置应设置为插槽设置以修复该行为。 虽然这确实修复了我的测试中的行为,但似乎是错误的,因为它不应该起作用。

下面是我的测试中发生的事情的表格。 (将其设为插槽设置后)
image

我(和客户)的看法是插槽根本不应该交换,但正如文章中所述,它仍然有效。

我也在内部提出了这个问题,人们在更改应用程序设置时发现了不一致的行为。 (因此为什么在我的测试网格中突出显示了这一点)对于测试它的同事,更新应用程序设置,使插槽设置重新应用,从而再次导致意外交换。

这最后(对冗长的回复感到抱歉)让我提出支持案例,结果是“根本不设置设置”。
我的个人测试表明这确实解决了问题,但文档中没有任何指导来确认这一点,因此我提出了这个项目。

希望这可以帮助。
如果有任何不清楚的地方,请告诉我。

@danielstocker绝对是一个重要的信息,特别是要了解插槽和交换如何用于 Functions 与带有 webjobs 的传统 webapp。
尽管“WEBSITE_CONTENTSHARE”在这里起着关键作用,但插槽文档中也没有对此进行解释。 在第 4 步中只有

@ggirard07 ,感谢您阅读我的谩骂。 那么从这里前进的道路是什么? :)

@ggirard07 @ggailey777 @mike-urnun-msft

是否需要更多信息来围绕此行为创建一些文档清晰度? 我正在与一位正在考虑停止使用函数槽的客户合作,因为他们不确定有关此场景的官方指南。

谢谢你的帮助

@danielstocker只是为了让我清楚您认为将解决与此相关的文档问题的内容:

  • 此处删除WEBSITE_CONTENTSHARE部署设置。
  • 在参考文章中添加一个注释, WEBSITE_CONTENTSHARE应该只由运行时设置。

你认为这就足够了吗?

抄送 @mattchenderson

嗨@ggailey777
是的,我认为这是一个很好的解决方案

使用 ARM 部署功能应用程序时, WEBSITE_CONTENTSHARE不是必需的应用程序设置之一吗?

使用 ARM 部署功能应用程序时, WEBSITE_CONTENTSHARE不是必需的应用程序设置之一吗?

如果它没有被应用,那么运行时会为你生成一个,我想。

我部署了一个带有消费计划的 ARM 和一个带有名为appsettings的部分

  • FUNCTIONS_EXTENSION_VERSION : "~2",
  • FUNCTIONS_WORKER_RUNTIME : "dotnet",
  • WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : [存储连接
  • WEBSITE_NODE_DEFAULT_VERSION:6.5.0

部署返回以下错误:

      "ErrorEntity": {
        "ExtendedCode": "01010",
        "MessageTemplate": "Required parameter {0} is missing.",
        "Parameters": [
          "WEBSITE_CONTENTSHARE"
        ],
        "Code": "BadRequest",
        "Message": "Required parameter WEBSITE_CONTENTSHARE is missing."

在我_也_删除参数 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 后,部署没有任何错误。 因此,这两个设置之间似乎存在某种必需的关系。
虽然成功,但这种部署让我徘徊是否以及在何处物理部署功能(包)(如果这种情况首先有效)。

我们一直在看到@tjgalama所描述的确切行为,并且还想知道与函数包共享的文件存储在哪里。

我们的函数应用程序还包括一个计时器触发的函数,因此我们按照建议指定AzureWebJobsStorage设置:我们会猜测/希望运行时会使用相同的连接字符串(现在是隐式的) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ,但事实并非如此:在我们在此处指定的存储帐户中,我们确实看到了azure-webjobs-hostsazure-webjobs-secrets blob 容器,但不存在文件共享。

我已经在 Kudu 中检查了线索,看起来文件系统中需要存在的所有文件(无论在哪里,在app-name.scm.azurewebsites.net/api/vfs/ ),但没有引用任何设置( WEBSITE_CONTENTSHAREWEBSITE_CONTENTAZUREFILECONNECTIONSTRING )将在环境选项卡( appname.scm.azurewebsites.net/Env.cshtml )中看到。

也许值得一提的是,我们的应用程序设置了WEBSITE_ENABLE_SYNC_UPDATE_SITE=TrueWEBSITE_RUN_FROM_PACKAGE=1
这些应用程序似乎可以工作,但我们真的希望在这一点上有一些明确的说明,因为我们正在将核心业务服务移植到 Azure Functions 并希望在推出生产之前弄清楚这一点。

根据一些建议,我们将WEBSITE_CONTENTSHARE设置为插槽设置,以确保我们的生产插槽和暂存插槽之间的值不同。 今天,我们使用的 ARM 模板开始以'WEBSITE_CONTENTSHARE' cannot be a slot setting.失败(即使我确认它目前确实在门户中设置为插槽设置)。 这种行为有什么改变吗?

在过去的几天里,我们注意到了同样的问题,需要有关如何继续的指导。 我们也一直遵循将 WEBSITE_CONTENTSHARE 设置为插槽设置的方法来解决无意的交换问题,但现在由于此错误而无法部署。 我曾尝试追溯删除此设置和 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 设置,以转向似乎不使用任何一个的推荐方法,但这些部署也会失败。

根据一些建议,我们将WEBSITE_CONTENTSHARE设置为插槽设置,以确保我们的生产插槽和暂存插槽之间的值不同。 今天,我们使用的 ARM 模板开始以'WEBSITE_CONTENTSHARE' cannot be a slot setting.失败(即使我确认它目前确实在门户中设置为插槽设置)。 这种行为有什么改变吗?

删除它并让运行时选择一个名称。 这就是我的做法。

@jeffhollan你能给我们一些澄清吗

这表示 WEBSITE_CONTENTSHARE 和 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 是 _required_: https ://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create -a-function-app

这里的评论者认为他们_不需要_; ARM 认为它们是必需的? Azure 支持认为 WEBSITE_CONTENTSHARE 打破了插槽方案。

我们最终检查了 Azure 函数主机的代码,看起来从包运行时,没有使用WEBSITE_CONTENTAZUREFILECONNECTIONSTRING设置。
我们通过从我们的 ARM 模板中删除WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGWEBSITE_CONTENTSHARE并获得了良好的结果来验证它:我们的函数应用程序根本没有这两个设置(甚至没有由运行时分配),它们不要在任何存储帐户中使用文件共享(至少我们可以看到)。

所以要记住的一件事是 webapp/function app 的文件系统看起来像这样:

|-data
|-LogFiles
|-site
  |-deployments
  |-tools
  |-wwwroot

当您使用 run from package 时,它​​只会替换此树中的 wwwroot 文件夹。 其他一切都由主文件系统提供。 如果您在没有 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 的情况下制作消费或弹性高级功能应用程序,则主文件系统在创建功能应用程序的规模单元之外不可用。这不是支持/推荐的配置。 这意味着您的函数应用程序可能无法扩展到超出其创建的缩放单位的限制,或者如果确实如此,您将无法相信 wwwroot 之外的文件系统状态保持一致。

我从拥有 WEBSITE_CONTENTSHARE 如何与插槽交互的开发人员那里看到的最新指导如下:

  • WEBSITE_CONTENTSHARE 不应是插槽设置。 阻止此操作的 API 更改在撰写本文时正在推出。
  • 在通过 ARM 初始创建资源时,应设置 WEBSITE_CONTENTSHARE。 但是,初始创建后,应从 ARM 模板中省略此设置(因为如果包含它,ARM 模板的进一步执行可能会导致意外的内容交换)

根据我上面的评论......我还发现系统当前在生成 WEBSITE_CONTENTSHARE 方面存在一些不一致的行为,因此您甚至不需要最初指定它。 你们中的一些人一直说你不需要指定它,而另一些人则收到一个错误,说它是必需的。 据我所知,这种行为适用于消费(即用于消费的 ARM 模板最初不需要此设置),但对于弹性溢价则不然。 这种行为正在得到修复,但可能需要 1-2 个月的时间才能消除。 因此,与此同时,我上面分享的指南(您最初设置它然后从 ARM 模板中删除它)是适用的。

@paulbatum

  • 在通过 ARM 初始创建资源时,应设置 WEBSITE_CONTENTSHARE。 但是,初始创建后,应从 ARM 模板中省略此设置(因为如果包含它,ARM 模板的进一步执行可能会导致意外的内容交换)

您确实意识到这种破坏 ARM 模板的目的,对吗?

这种行为正在得到修复,但可能需要 1-2 个月的时间才能消除。 因此,与此同时,我上面分享的指南(您最初设置它然后从 ARM 模板中删除它)是适用的。

这里最终的预期配置是什么?
一旦所有这些实际部署完毕,我们能否在Azure/app-service-announcements 上发布具有正确配置和官方时间表

你好,不知道有没有这方面的进展。 我仍在努力使用带有 WEBSITE_CONTENTSHARE 标志的 ARM 模板。 @paulbatum如何从 ARM 模板中省略配置? 我必须完全禁用该步骤才能使其正常工作。

@gustavobmichel对不起,我不明白你的问题。 ARM 模板是 JSON,您可以根据需要对其进行编辑。 它作为 appsettings 部分的一部分出现,例如:

          "appSettings": [
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';EndpointSuffix=', environment().suffixes.storage, ';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },

@paulbatum ,谢谢你回来找我。 我以为你提到了以编程方式省略 JSON 模板中的设置,所以这就是我的问题。

正如其他人所说,我也认为这两个设置是必需的,所以我从我的 ARM 模板中删除了这两个。

为了以零停机时间测试此功能,我创建了一个简单的测试,使用裸露的 mininum 基础设施来测试它。 我从我的资源组中删除了所有资源,并运行 ARM 模板作为发布管道的一部分来创建没有 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING、WEBSITE_CONTENTSHARE 和 WEBSITE_RUN_FROM_PACKAGE 的资源。

我进行了几次测试,使用消耗计划仍然可以正常工作。 本周我将使用高级级别进行一些测试。

我还根据此链接将此配置 WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG 添加到 1: https: //docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

我附上了我的测试 ARM 模板以供参考。
azuredeploy.txt

@paulbatum ,谢谢你回来找我。 我以为你提到了以编程方式省略 JSON 模板中的设置,所以这就是我的问题。

正如其他人所说,我也认为这两个设置是必需的,所以我从我的 ARM 模板中删除了这两个。

为了以零停机时间测试此功能,我创建了一个简单的测试,使用裸露的 mininum 基础设施来测试它。 我从我的资源组中删除了所有资源,并运行 ARM 模板作为发布管道的一部分来创建没有 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING、WEBSITE_CONTENTSHARE 和 WEBSITE_RUN_FROM_PACKAGE 的资源。

我进行了几次测试,使用消耗计划仍然可以正常工作。 本周我将使用高级级别进行一些测试。

我还根据此链接将此配置 WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG 添加到 1: https: //docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot -swaps

我附上了我的测试 ARM 模板以供参考。
azuredeploy.txt

如果不考虑 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING,您的函数如何知道从哪里获取应用程序代码?

如果有帮助,我们已经决定:

  • 将 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 设置为我们希望运行代码的存储帐户
  • 在 arm 模板中根本不指定 WEBSITE_CONTENTSHARE(允许它为两个插槽自动生成)
  • WEBSITE_RUN_FROM_PACKAGE = 1

我围绕这些进行了大量测试,这似乎是避免触发意外交换并知道代码所在位置等的最佳配置。 也不需要在 ARM 模板之外管理这些设置,这是我不喜欢的(感觉在那时使用 ARM 模板没有太多意义)的想法。

部署似乎也可以在根本不指定 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 值的情况下工作,但如前所述,我们无法找出代码所在的位置,并且处理我的票证的 MS 支持人员似乎暗示这是一个错误,不应该被允许由平台。

如果有帮助,我们已经决定:

  • 将 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 设置为我们希望运行代码的存储帐户
  • 在 arm 模板中根本不指定 WEBSITE_CONTENTSHARE(允许它为两个插槽自动生成)
  • WEBSITE_RUN_FROM_PACKAGE = 1

我围绕这些进行了大量测试,这似乎是避免触发意外交换并知道代码所在位置等的最佳配置。 也不需要在 ARM 模板之外管理这些设置,这是我不喜欢的(感觉在那时使用 ARM 模板没有太多意义)的想法。

部署似乎也可以在根本不指定 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 值的情况下工作,但如前所述,我们无法找出代码所在的位置,并且处理我的票证的 MS 支持人员似乎暗示这是一个错误,不应该被允许由平台。

这也正是我所发现的。 谢谢确认。

添加 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_RUN_FROM_PACKAGE 后,我的函数在访问存储时出现问题。 你们有没有将这两个配置添加到 functionapp 和 slot 中?

确切的错误是:无法访问 Azure Functions 运行时。

那是在我进行第一次部署然后尝试部署新版本之后。

我也添加了我的 yml 文件。
yml 文件.txt
部署.txt

我还更新了我的 ARM 模板。

添加 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_RUN_FROM_PACKAGE 后,我的函数在访问存储时出现问题。 你们有没有将这两个配置添加到 functionapp 和 slot 中?

确切的错误是:无法访问 Azure Functions 运行时。

那是在我进行第一次部署然后尝试部署新版本之后。

我也添加了我的 yml 文件。
yml 文件.txt
部署.txt

我还更新了我的 ARM 模板。

我两个都有。 实际上,我的制作槽中没有任何东西,并且从登台中交换了所有东西。 我在定义 WEBSITE_CONTENTSHARE 或不指向正确的存储帐户时看到了这一点,其中代码驻留在 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING。 你不需要用 WEBSITE_CONTENTSHARE 指向任何地方。 我实际上认为我看到了您提到的错误,因为将 WEBSITE_CONTENTSHARE 添加到环境变量中。 确保你没有定义它。

@mslot ,我认为问题出在我的部署上。 我将它设置为 zipDeploy,因为我在这个线程https://stackoverflow.com/a/56205917上阅读了关于在 Azure DevOps 上设置它的内容。 在我将其更改为标准部署后,一切似乎都在运行。 谢谢你的帮助。

这种行为正在得到修复,但可能需要 1-2 个月的时间才能消除。

关于这个问题的任何更新? 消费和溢价行为现在是否一致? 我们可以在初始 ARM 部署和后续部署中省略 WEBSITE_CONTENTSHARE 吗? 这如何影响暂存槽? 任何更新的文档链接或指导?

我们基本上采用了与@thomaswilkin@mslot相同的方法,但只是通过实验和反复试验。 由于未设置 WEBSITE_CONTENTSHARE,因此甚至不确定运行时如何知道在哪里可以找到我们的文件。

你好。 不知道你们怎么做,但似乎我无法部署
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 没有 WEBSITE_CONTENTSHARE。 即使通过门户,它在尝试设置配置时也给了我一个错误;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.

在函数应用程序的概览页面上,我还看到以下警告消息: Storage is not configured, Function scaling will be limited. Click to learn more.我正在使用高级计划。 关于我们应该如何配置我们的功能应用程序的任何更新或官方指南?

对于高级计划(不是 100% 确定消费计划),以下是有效/无效的矩阵:

  • 如果您部署新资源:

    • 如果您不提供任何设置,则部署会成功,但您最终会收到Storage is not configured, Function scaling will be limited消息

    • 如果你只提供WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ,它会失败Required parameter WEBSITE_CONTENTSHARE is missing

    • 如果你提供这两个值,它就可以工作

  • 如果您部署到现有资源

    • 如果您不提供任何设置,则部署成功,但最终会收到Storage is not configured, Function scaling will be limited消息

    • 如果您只提供WEBSITE_CONTENTAZUREFILECONNECTIONSTRING ,即使应该需要WEBSITE_CONTENTSHARE ,它也会成功(并且之后似乎可以正常工作)

    • 如果您提供两个值,则它“有效”,因为 ARM 部分不会失败,但会导致多次重启问题,并且上面的 MS 指南是不要在更新上设置 WEBSITE_CONTENTSHARE

因此,目前似乎没有一种方法可以让单个 ARM 模板同时适用于这两种情况。

我还看到此警告消息: Storage is not configured, Function scaling will be limited. Click to learn more 。 没有网站 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 或 WEBSITE_CONTENTSHARE。 正如 Korkiak 提到的,任何更新或官方指南?

我们最近开始在 4 周前部署的现有 Azure Functions 的 Azure 门户中看到消息“未配置存储,函数缩放将受到限制。单击以了解更多信息”。 我们从未使用过 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 或 WEBSITE_CONTENTSHARE 并且到目前为止一直运行良好。

@paulbatum似乎这个问题在过去几天里变得越来越活跃,因为“未配置存储,功能缩放将受到限制”消息开始出现在门户中。 关于配置所有这些的正确方法的任何新指南?

我刚刚遇到了“WEBSITE_CONTENTSHARE”不能是上面提到的插槽设置错误,当使用以前运行良好的模板在几个月内第一次部署新的功能应用程序时。
该模板将“WEBSITE_CONTENTSHARE”作为插槽设置,并根据以下文章在功能应用程序和部署插槽 appsettings 中定义,也已在上面提到:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
阅读此线程将其作为插槽设置删除并尝试了设置“WEBSITE_CONTENTSHARE”的各种组合,但我没有得到与其他人相同的行为。 我可以部署而没有错误,如下所示:

  • 为 Function App 和 Deployment Slot 指定“WEBSITE_CONTENTSHARE”
  • 仅为函数应用指定“WEBSITE_CONTENTSHARE”

如果我根本没有在模板中指定 'WEBSITE_CONTENTSHARE',我会收到“缺少 WEBSITE_CONTENTSHARE 所需参数”错误。

所以请我们更新一下实际设置应该是什么,因为我无法使用当前的行为部署到生产环境中。

大家好,抱歉给大家带来的困惑。 我们试图通过让 Azure 门户告诉您何时可能会遇到与您的配置有关的扩展问题来保持聪明,但我们弄错了逻辑,因此现在人们可能会错误地看到警告。 我们正在努力修复,但与此同时,以下是验证您是否可能遇到应用扩展问题的方法:

如果您以弹性溢价或消费运行,那么您必须满足以下条件之一:

  1. 您必须定义 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE

或者

  1. 如果您使用从 zip/package 运行,那么您必须将“WEBSITE_USE_ZIP”、“WEBSITE_RUN_FROM_ZIP”或“WEBSITE_RUN_FROM_PACKAGE”设置为除空、0 或 1 以外的其他值

我们应该在下周的某个时候解决这个问题。

谢谢@ehamai - 当您说“设置为空、0 或 1 以外的其他值时的#2” - 对吗? 0 和 1 不是对立的吗? (我们有我们设置为1,我们认为这意味着是/真(包从运行)如下记载:https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from -部署包)

嗨,埃利奥特,非常感谢您非常迅速的回复。

所以只是为了澄清:
从 ARM 模板部署到消费计划并使用部署槽但没有 zip/package 时

  • 我应该在 Production 和 Staging 插槽上同时定义 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE。

  • 我不应该将 WEBSITE_CONTENTSHARE 定义为任一插槽上的部署插槽设置。

此致

欧文

来源:埃利奥特浜井[email protected]
发送时间:2020 年 6 月 22 日 17:31
至:MicrosoftDocs/azure-docs [email protected]
抄送:Owain Winterbone(ITCS - 工作人员) [email protected] ; 手册[email protected]
主题:回复:[MicrosoftDocs/azure-docs] 不应使用 WEBSITE_CONTENTSHARE 来支持 (#36458)

警告:此电子邮件来自 UEA 系统之外。 不要点击链接或附件,除非您期望发件人提供它们并且知道内容是安全的。

大家好,抱歉给大家带来的困惑。 我们试图通过让 Azure 门户告诉您何时可能会遇到与您的配置有关的扩展问题来保持聪明,但我们弄错了逻辑,因此现在人们可能会错误地看到警告。 我们正在努力修复,但与此同时,以下是验证您是否可能遇到应用扩展问题的方法:

如果您以弹性溢价或消费运行,那么您必须满足以下条件之一:

  1. 您必须定义 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE

或者

  1. 如果您使用从 zip/package 运行,那么您必须将“WEBSITE_USE_ZIP”、“WEBSITE_RUN_FROM_ZIP”或“WEBSITE_RUN_FROM_PACKAGE”设置为除空、0 或 1 以外的其他值


您收到此消息是因为您订阅了此线程。
直接回复本邮件,在GitHub上查看https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647631943&data = 02%7C01%7Co.winterbone%40uea.ac.uk%7Cecd3322262374fb9ffb608d816c9ad12%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284402737046987&SDATA = woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA%3D&保留= 0 ,或退订https://eur01.safelinks.protection.outlook.com/?url= HTTPS%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-AUTH%2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ&数据= 02%7C01%7Co.winterbone%40uea.ac.uk%7Cecd3322262374fb9ffb608d816c9ad12%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284402737056941&SDATA = StHshC6EtV6A%2BLi3g7x0xfNx56POAYnwjMWihEf%2BCYM%3D&保留= 0 .

@briandunnington - 是的,很抱歉,这令人困惑。

  • 0 表示禁用
  • 1 表示从本地 zip 运行,但要使其正常工作,您还需要由第一条语句定义 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE。

@OwainWin - 对不起,我对你的问题感到困惑。 您询问是否应该和不应该包含 WEBSITE_CONTENTSHARE。

我相信您应该在生产和登台插槽上都定义了 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE。

谢谢@ehamai - 所以回到这个线程的原始问题:在适用于初始和后续部署的 ARM 模板中设置 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE 的指导是什么? 对于高级计划(不是 100% 确定消费计划,但相信它是相同的),这是有效/无效的矩阵:

  • 如果您部署新资源:

    • 如果您不提供任何设置,则部署成功,但最终未配置存储,功能扩展将受到限制消息

    • 如果您只提供 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING,则它会因缺少必需参数 WEBSITE_CONTENTSHARE 而失败

    • 如果你提供这两个值,它就可以工作

  • 如果您部署到现有资源

    • 如果您不提供任何设置,则部署成功,但最终未配置存储,功能扩展将受到限制消息

    • 如果您只提供 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING,即使应该需要 WEBSITE_CONTENTSHARE,它也会成功(并且之后似乎工作正常)

    • 如果您提供两个值,则它“有效”,因为 ARM 部分不会失败,但会导致多次重启问题,并且上面的 MS 指南是不要在更新上设置 WEBSITE_CONTENTSHARE

因此,目前似乎没有一种方法可以让单个 ARM 模板同时适用于这两种情况。

嗨艾略特

对于第二点,我想说的是 WEBSITE_CONTENTSHARE 应定义为应用程序设置,但不应将其设为部署槽设置。
所以它不应该有如下勾号:

[cid:[email protected]]

来源:埃利奥特浜井[email protected]
发送时间:2020 年 6 月 22 日 18:38
至:MicrosoftDocs/azure-docs [email protected]
抄送:Owain Winterbone(ITCS - 工作人员) [email protected] ; 提及[email protected]
主题:回复:[MicrosoftDocs/azure-docs] 不应使用 WEBSITE_CONTENTSHARE 来支持 (#36458)

警告:此电子邮件来自 UEA 系统之外。 不要点击链接或附件,除非您期望发件人提供它们并且知道内容是安全的。

@OwainWin https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0 %7C0%7C637284442665654874&sdata=x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw%3D&reserved=0 - 对不起,我对你的问题感到困惑。 您询问是否应该和不应该包含 WEBSITE_CONTENTSHARE。

我相信您应该在生产和登台插槽上都定义了 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE。


你收到这个是因为你被提到了。
直接回复本邮件,在GitHub上查看https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647674267&data = 02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665664832&SDATA = ctK99d4qO2YuIN%2F07lwuHC0wNut%2Fx8LjgLd7v55rTAM%3D&保留= 0 ,或退订https://eur01.safelinks.protection.outlook.com /?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PEPPJE7NN6RO5D4SSLRX6JGNANCNFSM4IJGDPBQ&data=02%7C01%7Co.winterbone%40uea.ac.uk%7Cafedec71775f4f42d84108d816d2f967%7Cc65f8795ba3d43518a070865e5d8f090%7C0%7C0%7C637284442665664832&sdata=wXaMW%2Fx% 2B5RXDtrfiQgHeZYtpc%2BhLyI9w6f9ut9NTFjM%3D&reserved=0

@paulbatum

  • 在通过 ARM 初始创建资源时,应设置 WEBSITE_CONTENTSHARE。 但是,初始创建后,应从 ARM 模板中省略此设置(因为如果包含它,ARM 模板的进一步执行可能会导致意外的内容交换)

您确实意识到这种破坏 ARM 模板的目的,对吗?

这种行为正在得到修复,但可能需要 1-2 个月的时间才能消除。 因此,与此同时,我上面分享的指南(您最初设置它然后从 ARM 模板中删除它)是适用的。

这里最终的预期配置是什么?
一旦所有这些实际部署完毕,我们能否在Azure/app-service-announcements 上发布具有正确配置和官方时间表

这对我们来说是一个很大的障碍。 我们需要能够使用相同的 ARM 模板部署到我们将用于部署到现有资源组的新资源组。 我们专门在完整模式下运行我们的 ARM 模板,以帮助提供更多上下文。

现在,我们的 ARM 模板看起来像这样:

{
  "apiVersion": "2016-08-01",
  "type": "Microsoft.Web/sites",
  "name": "[variables('functionAppName')]",
  "location": "[variables('defaultLocation')]",
  "kind": "functionapp",
  "properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  },
  "resources": [
    {
      "name": "slotconfignames",
      "type": "config",
      "apiVersion": "2016-08-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "appSettingNames": [
          "SomeSlotSpecificSetting"
        ]
      }
    },
    {
      "name": "staging",
      "type": "slots",
      "apiVersion": "2016-08-01",
      "location": "[variables('defaultLocation')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "AzureWebJobsStorage",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "AzureWebJobsDashboard",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "SomeSetting__Foo",
              "value": "[parameters('someSettings').foo]"
            },
            {
              "name": "SomeSetting__Bar",
              "value": "[parameters('someSettings').bar]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "dotnet"
            },
            {
              "name": "SomeSlotSpecificSetting",
              "value": "abc 123"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            }
          ]
        }
      }
    }
  ],
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName'))]",
    "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  ]
}

请注意以下细节:我们指定我们的配置 _on staging slot_,而不是生产 slot。 这允许我们首先将新设置(以及对现有设置的更新)部署到暂存槽。 因此,我们的 DevOps 管道执行以下操作:

  • 步骤 1) 将 ARM 模板部署到资源组
  • 步骤 2) 将函数应用程序部署到暂存槽
  • 步骤 3) 对暂存槽运行一些冒烟测试
  • 步骤 4) 交换暂存槽和生产槽

但问题在于,因为WEBSITE_CONTENTSHARE是在 ARM 模板中设置的,所以生产槽和暂存槽会在第 2 步之后(甚至发生交换之前)立即采用新版本的应用程序。 我相信这就是人们在说“意外交换操作”时所谈论的内容。

我们_不_希望在我们的 ARM 模板中设置生产槽设置,并且我们_不_希望由于我们的 ARM 模板运行而删除任何生产槽设置。 在 Complete 模式下部署 ARM 模板的工作方式是,如果我们为生产槽指定任何设置,那么所有未明确指定的设置都会自动删除。

我希望这一切都有意义。 我们目前正在尝试从我们的 ARM 模板中删除WEBSITE_CONTENTSHARE ,希望运行时能够在所有场景中生成该值并且不再导致“意外交换”。

大家好,我是部署槽的主要开发人员,我将解决您关于设置 WEBSITE_CONTENTSHARE 和 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 的问题:

以下是官方指导:

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:这应该始终设置,因为它告诉应用服务您正在使用 azure 文件进行内容存储。

WEBSITE_CONTENTSHARE:

  • 现在可以从用于消费 sku 函数的 ARM 模板中完全省略这一点,这将自动生成字段并避免意外交换。 这意味着您可以使用相同的模板进行创建和更新。
  • 不幸的是,我们发现 Elastic Premium 滑雪板忽略了 WEBSITE_CONTENTSHARE 的这种自动生成,因此在创建期间必须包含它并在更新期间忽略它的问题仍然存在。 对此的修复目前正在推出,并且已经覆盖了我们一半的车队。 它应该在接下来的 2 周内完全推出,之后对于 skus 和 WEBSITE_CONTENTSHARE 的指导将相同,可以完全省略。

希望能解决您的一些疑虑!

@shubDhond 非常感谢。 我们可以获得文档的官方更新吗?

@shubDhond用于 Windows 消费计划,如果我只提供 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 我通过 arm 模板部署收到一个错误,说缺少 WEBSITE_CONTENTSHARE。
我不需要使用插槽。 如果省略两个部署,但我收到警告“未配置存储。功能调用将受到限制”。

我正在使用 .net core windows 消费计划的这两个参数对消费计划的指导是什么?

同上! 我也收到这个错误。 这个什么时候能修好?

我在消费和弹性计划方面也有同样的问题,这给我们带来了很多自动化部署问题。

我在Microsoft.Web/sites属性(siteConfig、appSettings)中直接部署设置时省略了WEBSITE_CONTENTSHARE for Premium 取得了一些成功,但在使用Microsoft.Web/sites/config将设置指定为单独的资源时则不然"type": "config"

@shubDhond这个问题肯定没有解决。 在 Windows 消费计划中,如果您部署的模板只有 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 而没有 WEBSITE_CONTENTSHARE,您将收到错误“缺少 WEBSITE_CONTENTSHARE”。

尝试在 Azure DevOps 中使用应用服务部署任务并仅设置 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 也会产生 HTTP 400 错误。

消费计划中 Azure Function 应用的自动化目前已完全中断。

@clawrenceks有同样的问题

我们也遇到了与@clawrenceks 相同的问题。
我们也不能通过 Azure 门户在没有WEBSITE_CONTENTSHARE情况下仅设置WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 。 我们也将WEBSITE_RUN_FROM_PACKAGE设置为 1。
image

我也不确定当您将 ARM 模板部署模式设置为Complete时这将如何工作? 它不会删除生成的应用程序设置WEBSITE_CONTENTSHARE吗?

像大多数人一样,我们也迷路了。

现在,我的 ARM 模板已成功将我的函数应用部署到 Windows 消费计划中。 部署后,将不再显示消息Storage is not configured, Function scaling will be limited. Click to learn more 。 插槽交换也按预期工作。

我在这个过程中的主要发现是:

如果您目前有一个没有WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGWEBSITE_CONTENTSHARE应用程序设置的 Azure Function 应用程序,我相信解决此问题的唯一方法是重新部署您的应用程序,确保WEBSITE_CONTENTAZUREFILECONNECTIONSTRING设置作为应用服务创建的一部分。

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING作为资源创建的一部分是关键。 使用 ARM 时,我的发现是它必须在主应用程序服务部署期间作为应用程序设置进行部署,资源类型为Microsoft.Web/sites 。 在您的 ARM 模板中使用单独的资源类型Microsoft.Web/sites/config来部署应用程序设置将不起作用。

我的 ARM 模板中没有包含WEBSITE_CONTENTSHARE设置。 这是在部署我的 ARM 模板时由运行时创建的。 这表明部署运行良好。 使用此处描述的方法,我能够部署初始资源,然后多次重新部署模板,而不会收到与WEBSITE_CONTENTSHARE设置相关的错误。

对我来说,一个单独的关键要求是生产站点应用程序设置应该只在初始资源创建期间部署。 我想让新的(未来的)应用程序设置进入生产站点的唯一方法是通过插槽交换。 为了实现这一点,我在我的 ARM 模板中添加了一些逻辑来处理以下内容。

1) ARM 模板中的应用设置只会在初始站点创建期间部署到生产站点,它们不会作为未来部署的一部分添加到生产站点。

2) ARM 模板中的应用程序设置始终应用于暂存槽。 然后使用交换槽将它们交换到生产中。

为了实现上述目的,我的 ARM 模板中生产站点的 appSettings 是有条件的。 如果资源不存在,我会在模板中部署全套应用设置(以确保正确创建应用服务)。 如果资源已经创建,我会为应用程序设置传递一个空值。 部署后,它会保留生产站点已经存在的应用程序设置。

我也完全糊涂了。 如果消耗计划需要 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING,但它不能配置为坚持插槽,我应该如何在暂存和生产插槽之间切换,我希望每个插槽都在不同的存储帐户上运行? 这在 Web 应用程序中一直是可能的,并且似乎是一个非常常见的用例。 据我所知,在修复此问题之前,交换功能应用程序插槽已完全损坏/无法使用。 很希望有人告诉我为什么/我错了! 我知道原始问题引用了 ARM 模板,但这似乎是一个更广泛的问题。

Elastic Premium 计划也有同样的问题。 使用相同的 WEBSITE_CONTENTSHARE 部署到阶段槽相同的 ARM 模板使生产槽指向与阶段槽相同的二进制文件。
没有 WEBSITE_CONTENTSHARE 根本无法部署,因为我收到2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest'错误

我很迷惑。 正确的做法是什么?

如果您以弹性溢价或消费运行,那么您必须满足以下条件之一:

您必须定义 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE

或者

如果您使用从 zip/package 运行,那么您必须将“WEBSITE_USE_ZIP”、“WEBSITE_RUN_FROM_ZIP”或“WEBSITE_RUN_FROM_PACKAGE”设置为除空、0 或 1 以外的其他值

正如@ehamai所说?

或者

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:这应该始终设置,因为它告诉应用服务您正在使用 azure 文件进行内容存储。

WEBSITE_CONTENTSHARE:

现在可以从用于消费 sku 函数的 ARM 模板中完全省略这一点,这将自动生成字段并避免意外交换。 这意味着您可以使用相同的模板进行创建和更新。

不幸的是,我们发现 Elastic Premium 滑雪板忽略了 WEBSITE_CONTENTSHARE 的这种自动生成,因此在创建期间必须包含它并在更新期间忽略它的问题仍然存在。 对此的修复目前正在推出,并且已经覆盖了我们一半的车队。 它应该在接下来的 2 周内完全推出,之后对于 skus 和 WEBSITE_CONTENTSHARE 的指导将相同,可以完全省略。

希望能解决您的一些疑虑!

正如@shubDhond所说?

如果我在消费计划上有一个 azure 函数而在任一插槽上都没有 WEBSITE_CONTENTSHARE(实际上生产插槽根本没有应用程序设置),我会收到一个错误,我:

  1. 将 ARM 部署到暂存槽
  2. 交换
  3. 重新部署到暂存槽

然后它告诉我我需要 WEBSITE_CONTENTSHARE。 就好像它无法为旧的生产槽生成份额。 我没有尝试删除 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING,因为这个线程说不要这样做, @ehamai除外,它告诉我,如果我执行“WEBSITE_RUN_FROM_PACKAGE”,我可以做到。

有趣的是,我有一个使用此设置运行的函数,但运行时间为 ~2 而不是 ~3,并且它正在运行。 ~3 和部署槽有问题吗?
这是非常令人困惑的。

不管这种自发的插槽交换是非常可怕的,无论如何,因为我们需要创建这两个WEBSITE_变量,我们也按照此处的定义自己填充 ARM 后者。 门户上的 webapp 配置诊断工具不再显示错误。

重新分配:@mattchenderson

这事有进一步更新吗?

Microsoft 支持人员也建议我们必须设置“WEBSITE_CONTENTSHARE”属性。 当无法将其设置为插槽设置时,这对于我们的构建管道和 ARM 模板来说是非常有问题的。 请指教!

我也同意。 是时候解释一下如何在此处使用插槽了!

我也同意,这个线程是在 15 个月前开始的,仍然没有稳定的解决方案。
在使用受信任的解决方案正确解决这个问题之前,我们不能使用插槽,插槽是一个很棒的功能,但它们需要可靠。

大家好,

非常抱歉这里的响应延迟,该线程没有得到应有的监控。

为了解决混淆, @clawrenceks上面描述的行为

API 当前的工作方式是在站点创建时(“Microsoft.Web/sites”资源),如果您提供 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 而不是 WEBSITE_CONTENTSHARE,则会为您生成内容共享。 但是,在更新现有的“Microsoft.Web/sites”资源或“Microsoft.Web/sites/config”资源时,API 会查看应用程序的 WEBSITE_CONTENTSHARE 值是否已经存在,如果不存在,它会引发错误。

我认为这是为了防止客户在切换到 azure 文件时无意中擦除他们的内容,如果他们提供 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 并且我们为他们生成一个新的 WEBSITE_CONTENTSHARE(基本上是擦除他们的内容,因为这个共享是新的)。 这在网站创建过程中要安全得多,因为该网站无论如何都会从一个干净的石板开始,我们不会冒险擦除您的内容。

我完全可以理解你们都希望使用 azure 文件的困惑。 我将不得不考虑如何最好地解决这个问题,同时仍然保持我们的更新操作不会擦除您的内容。 至于现在所有没有配置 azure 文件并希望进行切换的人的指南,您需要为初始切换提供 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE,然后指南将与从您的文件中省略 WEBSITE_CONTENTSHARE 相同之后的模板。

如果对您希望如何处理更新案例有任何建议,也将不胜感激!

@shubDhond所以我们需要在第一次部署到生产槽时部署 connectionstring 和 contentshare appsettings,而不是之后的部署。 有没有办法自动执行此操作? 像检测资源是否已通过 ARM 部署? 或者我们是否需要手动将此信息传递到 ARM(通过参数 fx 来判断这是否是第一次部署?

@mslot不幸的是,我认为无法在模板中判断资源是否已经存在,但这应该是可能的(https://docs.microsoft.com/en-us/azure/azure-resource- manager/templates/template-tutorial-use-conditions) 与传递给模板的参数相结合,告诉它该站点是否已配置为 Azure 文件。 这可以通过获取站点并查看应用设置是否具有 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE 来确定。

@mslot不幸的是,我认为无法在模板中判断资源是否已经存在,但这应该是可能的(https://docs.microsoft.com/en-us/azure/azure-resource- manager/templates/template-tutorial-use-conditions) 与传递给模板的参数相结合,告诉它该站点是否已配置为 Azure 文件。 这可以通过获取站点并查看应用设置是否具有 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 和 WEBSITE_CONTENTSHARE 来确定。

我真的希望这能尽快得到解决。 它在我的工作流程中使插槽的使用变得无用。 它需要完全自动化。 这个解决方案在我看来是一种黑客解决方法,当它适用于 webapps 时引入是没有意义的,因为它在一些应该起作用的东西上有很大分歧,为其他人引入“黑魔法”进入项目。

我真的希望这个问题得到解决,这样我们就可以开始使用它了。我认为它阻止了很多人使用这个功能。

@mslot我完全理解你对此的痛苦,很抱歉我们没能早点发现这个问题。 我将在下周与最初实施此行为的开发人员交谈,看看我们是否可以找到解决此问题的安全方法,从而避免客户无意中转而使用空的 azure 文件共享作为其内容的可能性。 一旦我们有了建议的解决方案,我会在这里更新。

@shubDhond我不太了解 Azure 文件的“部分”。 我使用 Azure DevOps 部署我的 Azure Function 项目,首先创建一个部署槽,部署到这个,然后交换。 我正在使用“RunFromPackage”部署方法,这在使用经典 StorageAccount 时似乎不起作用。 我没有使用 Azure 文件,而且我似乎遇到了与两个插槽的 WEBSITES_CONTENTSHARE 设置相关的相同问题。

@cannehag你能为此开一个新问题吗? RunFromPackage 应用程序设置被标记为粘性时可能会发生一些奇怪的行为,导致与此处描述的症状类似。 我会建议一个新问题,所以我们不会在这里添加混淆,因为这些问题可能是无关的。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

jharbieh picture jharbieh  ·  3评论

JeffLoo-ong picture JeffLoo-ong  ·  3评论

monteledwards picture monteledwards  ·  3评论

paulmarshall picture paulmarshall  ·  3评论

mrdfuse picture mrdfuse  ·  3评论