部署到 tmp 文件夹而不是 wwwroot 的 Azure Web 应用程序
Azure web app deployed to tmp folder instead of wwwroot
我已经在 Azure App Service 上部署我的 Django Python Web 应用程序数百次了。
最近，我对 html 文件做了一个小改动并推送了它，但部署方式有所不同。
Oryx 没有将应用程序部署在 home/site/wwwroot/ 中，而是将其部署到 tmp 文件夹中。 （见截图）
我很困惑为什么会这样。我没有更改任何设置或配置，我的网络应用程序最终位于 tmp 文件夹中。
有人知道这里发生了什么以及如何解决这个问题吗？
建议SCM_DO_BUILD_DURING_DEPLOYMENT= FALSE.
更详细的可以参考这个post(Azure App Service Getting error while deploying REACT JS application).
我仔细看了他的post，没有找到这个问题的原因。有兴趣的可以提个支持票。
我发现了问题所在。 Azure 应用服务的 Python 构建过程发生了变化。详情可见here.
我引用上面的link。
Change
Python build and runtime workflow is changing for the apps built on
App Service.
Current build process
The app builds are carried out in a build container/agent by a Build
System called Oryx. This container produces artifacts which are stored
on an NFS volume and later run by a Runtime container defined by the
user(eg: Python 3.8).
Oryx running in the Build Agent installs the dependencies listed in
requirements.txt into a virtual environment named antenv. This build
is carried out in a local build directory. This virtual environment
produced by the above build is compressed and extracted by the runtime
at the root of the container to enable the users to have an optimal
build and startup time.
This caused a problem where the Virtual Environment could not resolve
certain app dependencies. The reason for this is that during the
creation of the Virtual Environment pip hardcodes certain paths for
dependencies. Since, the builds are carried out in an Build Container
and Run on a Runtime container at a different path, this causes a
mismatch between the directory structure for the virtual environment.
Change/New Build+Runtime Process
The build workflow remains the same with respect to the use of a
temporary build directory as described above. But now the whole app
output(including the Virtual Environment) is compressed into a tarball
and stored at /home/site/wwwroot with a manifest file
oryx-manifest.toml. This manifest file describes how the build was
carried out in the build container. The runtime container on startup
reads this manifest and recreates a local copy of the folder structure
on every instance. This change also ensures that the runtime during
the app startup will already have the virtual environment activated
and users can run commands like migrate without the need to activate
the environment.
As a part of this change, the app would no longer run from
/home/site/wwwroot but would have a dynamic runtime directory. This
path can be retrieved by using the variable $APP_PATH.
如果此更改破坏了您的应用程序，您唯一的选择是更改文件路径。您无法从 tmp.
的 运行 停止 Azure App Service 您的 Django 应用程序
编辑：
我就此向 Azure 团队提出了一个问题，他们正在努力回滚更改。可以找到更多详细信息here
编辑：
Latest update (20201229)
We are in the process of reverting to the old deployment behavior
across all regions. The new behavior would be an opt-in after this
fix, we would send out notifications and give ample time to make
changes when we change the default behavior.
You could pin to the old version by adding an app setting:
KUDU_BUILD_VERSION=0.0.1 -> This would ensure the build behavior
remains the same even when we change default behavior after the
notification.
To try the new version, you can add the app setting:
KUDU_BUILD_VERSION=1.0.0.
Please share your app names directly or indirectly if you are still
experiencing the problem and we can investigate further
这个 post 对我来说是一个节省。谢谢你。微软在更新人们这一变化方面做得很差。在我 运行 进入之前，它真的让我们很痛苦，并且是一场徒劳的追逐。读完这篇文章后，我花了很短的时间就把事情放在一起，我将分享一些经验教训作为感谢，希望其他人不会经历这种痛苦。
- 此更改发生在 2021 年 3 月 1 日，但在您在该日期 post 进行部署之前，不会有任何问题。在那之前一切都会继续正常工作。那时你会看到莫名其妙的事情发生，因为 MS 正在使用 TAR 文件策略和可视化事物等。但是，这些过程不会改变你当前的设置，也不会删除任何东西。都在制造混乱！因此，例如，如果您从 bash 或 ftp 查看 wwwroot，则无论您重新部署多少次，都不会 change/update 文件。因此，如果您在计划部署之前了解了这个相当激进的变化，请清理一下；然后转向 CI/CD 模型并利用 GitHub 是我的建议，事先删除所有内容 - 一种“重新开始”的方法。这样做，你就可以开始了。否则，如果您已经部署，您将追逐幽灵。我是后一种情况，这意味着在经历了很多头痛之后从头开始重做。
- 如果你有任何在你 Git 回购之外的参考资源，$APP_PATH 是关键，虽然现在这都是虚拟的，但使用“/home”作为用户友好指向您的应用程序路径的方式是关键的花絮。 $APP_PATH 对 Bash 和 FTP 工作很有用。 “/home”用于代码。另请注意，只有保存在 /home 下的内容才会保留。就我而言，我将我的文件夹从 wwwroot 移动到 /home/ 并稍微更改了代码（只需要添加“/home/”。使用 app 变量可能是更好的编码实践:)
- 设置 CI/CD 后，效果非常好，太棒了。更改代码，获取已更改内容的电子邮件，然后在 GitHub 上监控 build/deploy 进程。如果它变成“红色”，修复它；检查它;观望。
#3 的最后一点。我知道你可以用一个变量来解决这个问题。我的建议是不要那样做。 MS 进行此更改的原因比他们传达它的能力要好得多。这是个好主意，而且效果很好。我使用的是一个相当复杂的 ML 模型，其性能提高了大约 10-15%。也许这是运气，但它让我相信这种变化。
只希望 MS 学会了如何让我们下次更好地了解情况:)
HTH.
我已经在 Azure App Service 上部署我的 Django Python Web 应用程序数百次了。
最近，我对 html 文件做了一个小改动并推送了它，但部署方式有所不同。
Oryx 没有将应用程序部署在 home/site/wwwroot/ 中，而是将其部署到 tmp 文件夹中。 （见截图）
我很困惑为什么会这样。我没有更改任何设置或配置，我的网络应用程序最终位于 tmp 文件夹中。
有人知道这里发生了什么以及如何解决这个问题吗？
建议SCM_DO_BUILD_DURING_DEPLOYMENT= FALSE.
更详细的可以参考这个post(Azure App Service Getting error while deploying REACT JS application).
我仔细看了他的post，没有找到这个问题的原因。有兴趣的可以提个支持票。
我发现了问题所在。 Azure 应用服务的 Python 构建过程发生了变化。详情可见here.
我引用上面的link。
Change
Python build and runtime workflow is changing for the apps built on App Service.
Current build process
The app builds are carried out in a build container/agent by a Build System called Oryx. This container produces artifacts which are stored on an NFS volume and later run by a Runtime container defined by the user(eg: Python 3.8).
Oryx running in the Build Agent installs the dependencies listed in requirements.txt into a virtual environment named antenv. This build is carried out in a local build directory. This virtual environment produced by the above build is compressed and extracted by the runtime at the root of the container to enable the users to have an optimal build and startup time.
This caused a problem where the Virtual Environment could not resolve certain app dependencies. The reason for this is that during the creation of the Virtual Environment pip hardcodes certain paths for dependencies. Since, the builds are carried out in an Build Container and Run on a Runtime container at a different path, this causes a mismatch between the directory structure for the virtual environment.
Change/New Build+Runtime Process
The build workflow remains the same with respect to the use of a temporary build directory as described above. But now the whole app output(including the Virtual Environment) is compressed into a tarball and stored at /home/site/wwwroot with a manifest file oryx-manifest.toml. This manifest file describes how the build was carried out in the build container. The runtime container on startup reads this manifest and recreates a local copy of the folder structure on every instance. This change also ensures that the runtime during the app startup will already have the virtual environment activated and users can run commands like migrate without the need to activate the environment.
As a part of this change, the app would no longer run from /home/site/wwwroot but would have a dynamic runtime directory. This path can be retrieved by using the variable $APP_PATH.
如果此更改破坏了您的应用程序，您唯一的选择是更改文件路径。您无法从 tmp.
编辑： 我就此向 Azure 团队提出了一个问题，他们正在努力回滚更改。可以找到更多详细信息here
编辑： Latest update (20201229)
We are in the process of reverting to the old deployment behavior across all regions. The new behavior would be an opt-in after this fix, we would send out notifications and give ample time to make changes when we change the default behavior.
You could pin to the old version by adding an app setting: KUDU_BUILD_VERSION=0.0.1 -> This would ensure the build behavior remains the same even when we change default behavior after the notification.
To try the new version, you can add the app setting: KUDU_BUILD_VERSION=1.0.0.
Please share your app names directly or indirectly if you are still experiencing the problem and we can investigate further
这个 post 对我来说是一个节省。谢谢你。微软在更新人们这一变化方面做得很差。在我 运行 进入之前，它真的让我们很痛苦，并且是一场徒劳的追逐。读完这篇文章后，我花了很短的时间就把事情放在一起，我将分享一些经验教训作为感谢，希望其他人不会经历这种痛苦。
- 此更改发生在 2021 年 3 月 1 日，但在您在该日期 post 进行部署之前，不会有任何问题。在那之前一切都会继续正常工作。那时你会看到莫名其妙的事情发生，因为 MS 正在使用 TAR 文件策略和可视化事物等。但是，这些过程不会改变你当前的设置，也不会删除任何东西。都在制造混乱！因此，例如，如果您从 bash 或 ftp 查看 wwwroot，则无论您重新部署多少次，都不会 change/update 文件。因此，如果您在计划部署之前了解了这个相当激进的变化，请清理一下；然后转向 CI/CD 模型并利用 GitHub 是我的建议，事先删除所有内容 - 一种“重新开始”的方法。这样做，你就可以开始了。否则，如果您已经部署，您将追逐幽灵。我是后一种情况，这意味着在经历了很多头痛之后从头开始重做。
- 如果你有任何在你 Git 回购之外的参考资源，$APP_PATH 是关键，虽然现在这都是虚拟的，但使用“/home”作为用户友好指向您的应用程序路径的方式是关键的花絮。 $APP_PATH 对 Bash 和 FTP 工作很有用。 “/home”用于代码。另请注意，只有保存在 /home 下的内容才会保留。就我而言，我将我的文件夹从 wwwroot 移动到 /home/ 并稍微更改了代码（只需要添加“/home/”。使用 app 变量可能是更好的编码实践:)
- 设置 CI/CD 后，效果非常好，太棒了。更改代码，获取已更改内容的电子邮件，然后在 GitHub 上监控 build/deploy 进程。如果它变成“红色”，修复它；检查它;观望。
#3 的最后一点。我知道你可以用一个变量来解决这个问题。我的建议是不要那样做。 MS 进行此更改的原因比他们传达它的能力要好得多。这是个好主意，而且效果很好。我使用的是一个相当复杂的 ML 模型，其性能提高了大约 10-15%。也许这是运气，但它让我相信这种变化。
只希望 MS 学会了如何让我们下次更好地了解情况:)
HTH.