python - Azure Web应用程序部署到tmp文件夹而不是wwwroot

Question

我已经在 Azure 应用服务上部署了 Django Python Web 应用数百次。

最近，我对 html 文件做了一个小更改并推送它，但部署情况有所不同。

Oryx 没有将应用部署到 home/site/wwwroot/ 中，而是将其部署到 tmp 文件夹中。 (见截图)

我很困惑为什么会发生这种情况。我没有更改任何设置或配置，我的网络应用程序最终位于 tmp 文件夹中。

有人知道这里发生了什么以及如何解决这个问题吗？

Answer 1

我发现问题出在哪里了。 Azure 应用服务上的 Python 构建过程发生了变化。详情可查看here .

我引用上面的链接。

Change

Python build and runtime workflow is changing for the apps built onApp Service.

Current build process

The app builds are carried out in a build container/agent by a BuildSystem called Oryx. This container produces artifacts which are storedon an NFS volume and later run by a Runtime container defined by theuser(eg: Python 3.8).

Oryx running in the Build Agent installs the dependencies listed inrequirements.txt into a virtual environment named antenv. This buildis carried out in a local build directory. This virtual environmentproduced by the above build is compressed and extracted by the runtimeat the root of the container to enable the users to have an optimalbuild and startup time.

This caused a problem where the Virtual Environment could not resolvecertain app dependencies. The reason for this is that during thecreation of the Virtual Environment pip hardcodes certain paths fordependencies. Since, the builds are carried out in an Build Containerand Run on a Runtime container at a different path, this causes amismatch 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 atemporary build directory as described above. But now the whole appoutput(including the Virtual Environment) is compressed into a tarballand stored at /home/site/wwwroot with a manifest fileoryx-manifest.toml. This manifest file describes how the build wascarried out in the build container. The runtime container on startupreads this manifest and recreates a local copy of the folder structureon every instance. This change also ensures that the runtime duringthe app startup will already have the virtual environment activatedand users can run commands like migrate without the need to activatethe environment.

As a part of this change, the app would no longer run from/home/site/wwwroot but would have a dynamic runtime directory. Thispath can be retrieved by using the variable $APP_PATH.

如果此更改破坏了您的应用，您唯一的选择就是更改文件路径。您无法阻止 Azure 应用服务从 tmp 运行您的 Django 应用。

编辑:我就此向 Azure 团队提出了一个问题，他们正在努力回滚更改。更多详情可查看here

编辑: Latest update (20201229)

We are in the process of reverting to the old deployment behavioracross all regions. The new behavior would be an opt-in after thisfix, we would send out notifications and give ample time to makechanges 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 behaviorremains the same even when we change default behavior after thenotification.

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 stillexperiencing the problem and we can investigate further