无法使用 CLI 将 Azure Functions 发布到 Linux
Unable to publish Azure Function to Linux using CLI
我目前正在 BitBucket 中创建一个构建管道,以摆脱我们当前的 'Right Click -> Publish' 策略。我已经迁移了一些托管在 Windows 上的功能,没问题。我们在 Linux 应用程序服务计划中有一个功能,不幸的是在发布后无法从包中 运行。
# Publish to a folder
dotnet publish "azure/$FUNCTION_NAME/$FUNCTION_NAME.csproj" -c Release -o publish/$FUNCTION_NAME
# Create a zip file
md artifacts
powershell Compress-Archive publish/$FUNCTION_NAME/** artifacts/$FUNCTION_NAME.zip
# Deploy the zip file to Azure
az functionapp deploy -g $AZURE_RESOURCE_GROUP -n $AZURE_RESOURCE_NAME --src-path artifacts/$FUNCTION_NAME.zip
这与 Azure Functions 文档页面上列出的步骤几乎完全相同。发布到 Linux 时, 没有错误 ,它只是什么都不做。在 Azure 门户中,应用程序中的所有功能仍然列出并且 host.json 和 function.json 文件似乎可以识别,但我不能再 test/run 函数。每个对 HTTP 端点的请求 returns 一个 404 状态。
我试图查看日志,没有 UI 我有点迷茫,但我确实找到了这些消息:
/home/LogFiles/kudu/deployment/5fd0c28b328b-ec52daf9-7903-466a-bfe1-5c1c658ab72b.txt
::::::::::::::
5fd0c28b328b-ec52daf9-7903-466a-bfe1-5c1c658ab72b.txt
::::::::::::::
2022-05-02T01:41:14 Fetching changes.
2022-05-02T01:41:30 Updating submodules.
2022-05-02T01:41:31 Preparing deployment for commit id '35555aaa-2'.
2022-05-02T01:41:32 Skipping build. Project type: Run-From-Zip
2022-05-02T01:41:32 Skipping post build. Project type: Run-From-Zip
2022-05-02T01:41:32 Requesting site restart
2022-05-02T01:41:33 Requesting site restart. Attempt #1
2022-05-02T01:41:33 Successfully requested a restart. Attempt #1
2022-05-02T01:41:34 Updating /home/data/SitePackages/packagename.txt with deployment 20220502014112.zip
2022-05-02T01:41:35 Deployment successful.
2022-05-02T01:41:38 An unknown error has occurred. Check the diagnostic log for details.
2022-05-02T02-02-31Z-ff1a2fe5e9.log
2022-05-02T02:02:31.309 [Warning] No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
从 Visual Studio 中重新发布解决了问题,所以这绝对是我发布方式的问题。 Visual Studio 中的发布配置文件有一个 <IsLinux>true</IsLinux>
属性,我怀疑这也是我需要以某种方式为 Azure CLI 指定的内容。
我推断一定有两种可能性:
- 我使用的上传zip文件的方法与Visual Studio
使用的方法不同
- 我创建的 zip 文件与 Visual Studio
生成的不一样
我查看了 MSBuild tasks in the SDK 以了解当您单击“发布”时 Visual Studio 做了什么。由此,我发现压缩文件是由 obj/Release/net6.0/PubTmp
文件夹中的 Visual Studio 生成的。它在部署时将 zip 文件发布到 https://{FUNCTION}.scm.azurewebsites.net/api/zipdeploy
。我用 PostMan 手动测试了这个,得到了以下结果:
Deployment method
Source
Result
POST /api/zipdeploy
obj/Release/net6.0/PubTmp
Succeeded
POST /api/zipdeploy
dotnet publish
+ powershell Compress-Archive
Failed
az functionapp deploy
obj/Release/net6.0/PubTmp
Succeeded
az functionapp deploy
dotnet publish
+ powershell Compress-Archive
Failed
table 显示部署仅在我使用从命令行生成的 zip 时失败。我用 WinMerge 来比较两者,但它说它们是相同的,所以我不知道发生了什么。显然,这两个 zip 文件之间肯定有 一些 差异,否则它们都可以正常部署。
我决定尝试将此作为错误报告,因此我尝试在一个新的空项目中重现该问题,但立即遇到了多个其他不相关的问题:
- 在 Azure 门户中,当我创建一个新的函数应用程序时,它不会让我 re-use 现有的 Linux 应用程序服务计划。我必须通过 Visual Studio 而不是
创建它
- 发布新项目后,唯一的功能是项目模板中的默认 HTTP 触发器,部署失败
- 连续发布失败,因为部署仍处于锁定状态
- 在 Kudu 中浏览文件的端点抛出异常,堆栈跟踪提到尝试使用 Windows 路径
我花了很多时间对此进行调查,得出的结论是目前还不值得尝试在 Linux 上托管。真令人失望,我希望他们能解决这些问题。
我目前正在 BitBucket 中创建一个构建管道,以摆脱我们当前的 'Right Click -> Publish' 策略。我已经迁移了一些托管在 Windows 上的功能,没问题。我们在 Linux 应用程序服务计划中有一个功能,不幸的是在发布后无法从包中 运行。
# Publish to a folder
dotnet publish "azure/$FUNCTION_NAME/$FUNCTION_NAME.csproj" -c Release -o publish/$FUNCTION_NAME
# Create a zip file
md artifacts
powershell Compress-Archive publish/$FUNCTION_NAME/** artifacts/$FUNCTION_NAME.zip
# Deploy the zip file to Azure
az functionapp deploy -g $AZURE_RESOURCE_GROUP -n $AZURE_RESOURCE_NAME --src-path artifacts/$FUNCTION_NAME.zip
这与 Azure Functions 文档页面上列出的步骤几乎完全相同。发布到 Linux 时, 没有错误 ,它只是什么都不做。在 Azure 门户中,应用程序中的所有功能仍然列出并且 host.json 和 function.json 文件似乎可以识别,但我不能再 test/run 函数。每个对 HTTP 端点的请求 returns 一个 404 状态。
我试图查看日志,没有 UI 我有点迷茫,但我确实找到了这些消息:
/home/LogFiles/kudu/deployment/5fd0c28b328b-ec52daf9-7903-466a-bfe1-5c1c658ab72b.txt
::::::::::::::
5fd0c28b328b-ec52daf9-7903-466a-bfe1-5c1c658ab72b.txt
::::::::::::::
2022-05-02T01:41:14 Fetching changes.
2022-05-02T01:41:30 Updating submodules.
2022-05-02T01:41:31 Preparing deployment for commit id '35555aaa-2'.
2022-05-02T01:41:32 Skipping build. Project type: Run-From-Zip
2022-05-02T01:41:32 Skipping post build. Project type: Run-From-Zip
2022-05-02T01:41:32 Requesting site restart
2022-05-02T01:41:33 Requesting site restart. Attempt #1
2022-05-02T01:41:33 Successfully requested a restart. Attempt #1
2022-05-02T01:41:34 Updating /home/data/SitePackages/packagename.txt with deployment 20220502014112.zip
2022-05-02T01:41:35 Deployment successful.
2022-05-02T01:41:38 An unknown error has occurred. Check the diagnostic log for details.
2022-05-02T02-02-31Z-ff1a2fe5e9.log
2022-05-02T02:02:31.309 [Warning] No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
从 Visual Studio 中重新发布解决了问题,所以这绝对是我发布方式的问题。 Visual Studio 中的发布配置文件有一个 <IsLinux>true</IsLinux>
属性,我怀疑这也是我需要以某种方式为 Azure CLI 指定的内容。
我推断一定有两种可能性:
- 我使用的上传zip文件的方法与Visual Studio 使用的方法不同
- 我创建的 zip 文件与 Visual Studio 生成的不一样
我查看了 MSBuild tasks in the SDK 以了解当您单击“发布”时 Visual Studio 做了什么。由此,我发现压缩文件是由 obj/Release/net6.0/PubTmp
文件夹中的 Visual Studio 生成的。它在部署时将 zip 文件发布到 https://{FUNCTION}.scm.azurewebsites.net/api/zipdeploy
。我用 PostMan 手动测试了这个,得到了以下结果:
Deployment method | Source | Result |
---|---|---|
POST /api/zipdeploy |
obj/Release/net6.0/PubTmp |
Succeeded |
POST /api/zipdeploy |
dotnet publish + powershell Compress-Archive |
Failed |
az functionapp deploy |
obj/Release/net6.0/PubTmp |
Succeeded |
az functionapp deploy |
dotnet publish + powershell Compress-Archive |
Failed |
table 显示部署仅在我使用从命令行生成的 zip 时失败。我用 WinMerge 来比较两者,但它说它们是相同的,所以我不知道发生了什么。显然,这两个 zip 文件之间肯定有 一些 差异,否则它们都可以正常部署。
我决定尝试将此作为错误报告,因此我尝试在一个新的空项目中重现该问题,但立即遇到了多个其他不相关的问题:
- 在 Azure 门户中,当我创建一个新的函数应用程序时,它不会让我 re-use 现有的 Linux 应用程序服务计划。我必须通过 Visual Studio 而不是 创建它
- 发布新项目后,唯一的功能是项目模板中的默认 HTTP 触发器,部署失败
- 连续发布失败,因为部署仍处于锁定状态
- 在 Kudu 中浏览文件的端点抛出异常,堆栈跟踪提到尝试使用 Windows 路径
我花了很多时间对此进行调查,得出的结论是目前还不值得尝试在 Linux 上托管。真令人失望,我希望他们能解决这些问题。