本文介绍 Azure 应用服务如何运行 Python 应用,如何将现有应用迁移到 Azure 以及如何按需自定义应用服务的行为。 必须连同所有必需的 pip 模块一起部署 Python 应用。
应用服务部署引擎会自动激活虚拟环境,并在部署 pip install -r requirements.txt
或部署启用了生成自动化的zip 包时运行。
注意
应用服务当前在项目的根目录中需要 requirements.txt
,即使你有一个 pyproject.toml
。 有关推荐的方法,请参阅 从 pyproject.toml 生成 requirements.txt 。
本文为在应用服务中使用内置 Linux 容器的 Python 开发人员提供了关键概念和说明。 如果从未使用过应用服务,请先完成 Python 快速入门 和 Flask、 Django 或 FastAPI 和 PostgreSQL 教程。
可使用 Azure 门户 或 Azure CLI 进行配置:
Azure 门户。 在应用的左窗格中,选择 “设置>环境变量 ”或 “设置>配置”,如 在 Azure 门户中配置应用服务应用中所述。
Azure CLI。 你有两个选项。
注意
Linux 是用于在应用服务中运行 Python 应用的唯一操作系统选项。 Windows 上的 Python 不再受支持。 但是,你可以生成自己的自定义 Windows 容器映像,并在应用服务中运行该映像。 有关详细信息,请参阅 使用自定义 Docker 映像。
配置 Python 版本
Azure 门户:使用“配置”页上的“常规设置”选项卡,如配置 Linux 容器的常规设置中所述。
Azure CLI:
使用 az webapp config 显示当前 Python 版本:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
替换
<resource-group-name>
并<app-name>
替换为适合 Web 应用的名称。使用 az webapp config set 设置 Python 版本:
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"
使用 az webapp list-runtimes 显示应用服务中支持的所有 Python 版本:
az webapp list-runtimes --os linux | grep PYTHON
应用服务中的过时运行时将如何处理?
维护组织弃用过时的运行时,或者其存在重大安全漏洞。 因此,将从门户中的创建和配置页面中删除它们。 当门户中隐藏了过时的运行时后,任何仍使用该运行时的应用程序都会继续运行。
如要创建一个运行时版本过时但尚未在门户中显示的应用程序,可以使用 Azure CLI、ARM 模板或者 Bicep 来实现。 通过这些部署替代方法,可以创建已在门户中移除的但仍受支持的弃用运行时。
如果从应用服务平台完全删除运行时,Azure 订阅所有者会在删除之前收到电子邮件通知。
自定义生成自动化
注意
使用生成自动化部署 Python 应用程序时,内容将部署到和提供,/tmp/<uid>
而不是在以下。/home/site/wwwroot
可以使用环境变量访问此内容目录 APP_PATH
。 应使用/home
”将运行时创建的任何其他文件写入到某个位置,以便保留。 有关此行为的详细信息,请参阅 Python 生成更改。
应用服务生成系统(称为 Oryx)在部署应用时执行以下步骤,如果应用设置 SCM_DO_BUILD_DURING_DEPLOYMENT
设置为 1
:
如果该步骤由
PRE_BUILD_COMMAND
设置指定,请运行自定义预生成脚本。 (脚本本身可以运行其他 Python 和 Node.js 脚本、pip 和 npm 命令,以及基于 Node 的工具,例如yarn install
Yarn 和yarn build
.)运行
pip install -r requirements.txt
。 requirements.txt 文件必须位于项目的根文件夹中。 如果没有,生成过程将报告错误“找不到 setup.py 或 requirements.txt;未运行 pip 安装。”如果在存储库的根目录中找到 manage.py (指示 Django 应用),请运行
manage.py collectstatic
。 但如果DISABLE_COLLECTSTATIC
设置为true
,则跳过此步骤。如果设置中
POST_BUILD_COMMAND
指定了该步骤,请运行自定义生成后脚本。 (同样,该脚本也可运行其他 Python 和 Node.js 脚本、pip 和 npm 命令,以及基于节点的工具。)
默认情况下,PRE_BUILD_COMMAND
、POST_BUILD_COMMAND
和 DISABLE_COLLECTSTATIC
设置为空。
若要在生成 Django 应用时禁用运行
collectstatic
,请将DISABLE_COLLECTSTATIC
该设置设置为true
。若要运行预生成命令,请将
PRE_BUILD_COMMAND
设置设置为包含命令(例如echo Pre-build command
)或相对于项目根目录的脚本文件的路径(例如scripts/prebuild.sh
)。 所有命令都必须使用相对于项目根文件夹的路径。若要运行生成后命令,请将
POST_BUILD_COMMAND
设置设置为包含命令(例如echo Post-build command
)或相对于项目根目录的脚本文件的路径(例如scripts/postbuild.sh
)。 所有命令都必须使用相对于项目根文件夹的路径。
有关自定义生成自动化的其他设置的信息,请参阅 Oryx 配置。
有关访问生成和部署日志的信息,请参阅 Access 部署日志。
若要详细了解应用服务如何在 Linux 中运行和生成 Python 应用,请参阅 Oryx 如何检测和生成 Python 应用。
注意
PRE_BUILD_SCRIPT_PATH
和 POST_BUILD_SCRIPT_PATH
设置与 PRE_BUILD_COMMAND
和 POST_BUILD_COMMAND
相同,并且支持用于旧用途。
如果名为 SCM_DO_BUILD_DURING_DEPLOYMENT
的设置包含 true
或 1
,则会在部署期间触发 Oryx 生成。 使用 git、Azure CLI 命令 true
和 Visual Studio Code 部署时,该设置为 az webapp up
。
注意
始终在所有预生成和生成后脚本中使用相对路径,因为运行 Oryx 的生成容器不同于运行应用的运行时容器。 决不要依赖于应用项目文件夹在容器中的确切位置(例如,其位于 site/wwwroot 下)。
根据 pyproject.toml 生成 requirements.txt
目前,应用服务不支持直接支持 pyproject.toml
。 如果使用诗歌或 uv 等工具,建议的方法是在项目的根目录中部署之前生成兼容的 requirements.txt 文件:
使用诗歌
使用诗歌和导出插件生成 requirements.txt:
poetry export -f requirements.txt --output requirements.txt --without-hashes
使用紫外线
使用 uv 生成 requirements.txt:
uv export --format requirements-txt --no-hashes --output-file requirements.txt
将现有应用程序迁移到 Azure
可以按如下所示将现有 Web 应用程序重新部署到 Azure:
源存储库。 在合适的存储库(如 GitHub)中维护源代码,以便稍后在此过程中设置持续部署。
- 如果希望应用服务自动安装必要的包, 则requirements.txt 文件必须位于存储库的根目录中。
数据库。 如果应用依赖于数据库,则还会在 Azure 上创建必要的资源。
应用服务资源。 创建资源组、应用服务计划和应用服务 Web 应用来托管应用程序。 可以通过运行 Azure CLI 命令
az webapp up
轻松创建这些资源。 或者,可以使用 PostgreSQL 教程在 Flask、 Django 或 FastAPI 中创建和部署资源。 将资源组、应用服务计划和 Web 应用的名称替换为适合应用程序的名称。环境变量。 如果应用程序需要任何环境变量,请创建等效 的应用服务应用程序设置。 这些应用服务设置在代码中显示为环境变量,如访问环境变量中所述。
- 例如,数据库连接通常通过此类设置进行管理,如 教程:使用 PostgreSQL 部署 Django Web 应用 - 验证连接设置。
- 有关典型 Django 应用的具体设置,请参阅 Django 应用的生产设置。
应用启动。 有关应用服务如何尝试运行应用的信息,请查看本文后面的 容器启动过程 部分。 应用服务默认使用 Gunicorn Web 服务器。 Gunicorn 必须能够找到应用对象或 wsgi.py 文件夹。 如果需要,可以自定义启动命令。
持续部署。 按照 “持续部署到 Azure 应用服务”一文中所述,从 GitHub Actions、Bitbucket 或 Azure Repos 设置持续部署。 或者根据 本地 Git 部署到 Azure 应用服务一文中所述,从本地 Git 设置持续部署。
自定义作。 若要在托管应用的应用服务容器(例如 Django 数据库迁移)中执行作,可以使用 SSH 连接到容器。 有关运行 Django 数据库迁移的示例,请参阅 教程:使用 PostgreSQL 部署 Django Web 应用。
- 使用持续部署时,可以使用生成后命令执行这些作,如前面在 “自定义生成自动化 ”部分中所述。
完成这些步骤后,你应能够将更改提交到源存储库,并将这些更新自动部署到应用服务。
Django 应用的生产设置
对于应用服务等生产环境,Django 应用应遵循 Django 部署清单中的指南。
下表描述了与 Azure 相关的生产设置。 这些设置在应用的 setting.py 文件中定义。
Django 设置 | Azure 说明 |
---|---|
SECRET_KEY |
将值存储在应用服务设置中,如 Access 应用设置中所述的环境变量。 你也可以在 Azure 密钥保管库中将该值存储为“机密”。 |
DEBUG |
使用值DEBUG (0 )在应用服务上创建设置false ,然后将该值加载为环境变量。 在开发环境中,创建一个 DEBUG 具有值 1 (true )的环境变量。 |
ALLOWED_HOSTS |
在生产环境中,Django 要求在“settings.py”的 ALLOWED_HOSTS 数组中包含应用的 URL。 可以使用代码 os.environ['WEBSITE_HOSTNAME'] 在运行时检索此 URL。 应用服务会自动将 WEBSITE_HOSTNAME 环境变量设置为应用的 URL。 |
DATABASES |
在应用服务中为数据库连接定义设置,并将这些设置加载为环境变量以填充 DATABASES 字典。 或者,可以将值(尤其是用户名和密码)存储为 Key Vault 机密。 |
提供 Django 应用的静态文件
如果 Django Web 应用包含静态前端文件,请先按照 Django 文档中有关管理静态文件的说明进行操作。
然后,对应用服务进行以下修改:
请考虑使用环境变量(用于本地开发)和应用设置(部署到云时)来动态设置 Django
STATIC_URL
和STATIC_ROOT
变量。 例如:STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/") STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")
可根据需要更改本地环境和云环境的
DJANGO_STATIC_URL
和DJANGO_STATIC_ROOT
。 例如,如果静态文件的生成过程将它们放置在名为django-static
的文件夹中,则可以将其DJANGO_STATIC_URL
设置为/django-static/
避免使用默认值。如果你有一个预生成脚本,且它在其他文件夹中生成静态文件,请将该文件夹添加到 Django 变量
STATICFILES_DIRS
中,以便 Django 的collectstatic
进程查找它们。 例如,如果在前端文件夹中运行yarn build
,Yarn 将build/static
生成包含静态文件的文件夹,请包含该文件夹,如下所示:FRONTEND_DIR = "path-to-frontend-folder" STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]
在此代码中,
FRONTEND_DIR
用于生成运行 Yarn 等生成工具的路径。 如果需要,可以再次使用环境变量和应用设置。将
whitenoise
添加到 requirements.txt 文件。 WhiteNoise (whitenoise.evans.io) 是一种 Python 包,可使生产 Django 应用轻松地为自己的静态文件提供服务。 WhiteNoise 为 DjangoSTATIC_ROOT
变量指定的文件夹中找到的文件提供服务。在 settings.py 文件中,为 WhiteNoise 添加以下行:
STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
MIDDLEWARE
修改列表INSTALLED_APPS
以包括 WhiteNoise:MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', # Add WhiteNoise middleware after the security middleware. 'whitenoise.middleware.WhiteNoiseMiddleware', # Other values follow. ] INSTALLED_APPS = [ "whitenoise.runserver_nostatic", # Other values follow. ]
提供 Flask 应用的静态文件
如果 Flask Web 应用包含静态前端文件,请先按照在 Flask 文档中 管理静态文件 的说明进行作。 有关如何在 Flask 应用程序中提供静态文件的示例,请参阅 GitHub 上的示例 Flask 应用程序。
若要直接从应用程序中的路由提供静态文件,可以使用 send_from_directory
方法:
from flask import send_from_directory
@app.route('/reports/<path:path>')
def send_report(path):
return send_from_directory('reports', path)
容器特征
部署到应用服务时,Python 应用在应用服务 Python GitHub 存储库中定义的 Linux Docker 容器内运行。 可以在特定于版本的目录中找到映像配置。
此容器具有以下特征:
应用由 Gunicorn WSGI HTTP 服务器 使用额外参数
--bind=0.0.0.0 --timeout 600
运行。可以通过自定义启动命令为 Gunicorn 提供配置设置。
为了保护 Web 应用免受意外或故意的 DDOS 攻击,Gunicorn 在 Nginx 反向代理后面运行,如 部署 Gunicorn 中所述。
默认情况下,基本容器映像仅包含 Flask Web 框架,但容器支持 WSGI 兼容且与 Python 3.6 及更高版本兼容的其他框架,例如 Django。
若要安装其他包(例如 Django),请在项目的根目录中创建 requirements.txt 文件,该文件指定直接依赖项。 然后,部署项目时,应用服务会自动安装这些依赖项。
requirements.txt 文件必须位于项目根目录中,否则不会安装依赖项。 如果此文件不在根目录中,生成过程将报告错误“找不到 setup.py 或 requirements.txt;未运行 pip 安装。”如果遇到此错误,请检查要求文件的位置。
应用服务会自动定义一个名为包含 Web 应用的 URL 的环境变量
WEBSITE_HOSTNAME
,例如msdocs-hello-world.chinacloudsites.cn
。 它还定义WEBSITE_SITE_NAME
,其中包含应用的名称,例如msdocs-hello-world
。npm 和 Node.js 安装在容器中,以便可以运行基于节点的生成工具,例如 Yarn。
容器启动过程
在启动期间,Linux 上的应用服务容器将运行以下步骤:
- 使用自定义启动命令(如果已提供)。
- 检查 Django 应用是否存在,如果检测到 Gunicorn,请启动 Gunicorn。
- 检查 是否存在 Flask 应用,如果检测到 Gunicorn,请启动 Gunicorn。
- 如果未找到其他任何应用,则启动容器中内置的默认应用。
以下部分详细介绍了每个选项。
Django 应用
对于 Django 应用,应用服务会在应用代码中查找名为 wsgi.py 的文件,然后使用以下命令运行 Gunicorn:
# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi
如果想要对启动命令进行更具体的控制,请使用自定义启动命令,将 <module>
替换为包含 wsgi.py 的文件夹的名称,如果该模块不在项目根目录中,则添加一个 参数。 例如,如果 wsgi.py 位于项目根文件夹中的 knboard/backend/config 下,请使用参数 。
若要启用生产日志记录,请添加 --access-logfile
和 --error-logfile
参数,如 自定义启动命令的示例所示。
Flask 应用
对于 Flask,应用服务将查找名为 application.py 或 app.py 的文件并启动 Gunicorn,如下所示:
# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app
# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app
如果主应用模块包含在不同的文件中,则对应用对象使用不同的名称。 如果要向 Gunicorn 提供其他参数,请使用自定义启动命令。
默认行为
如果应用服务找不到自定义命令、Django 应用或 Flask 应用,它将运行默认只读应用,该应用位于 opt/defaultsite 文件夹中,如下图所示。
如果部署代码后仍看到默认应用,请参阅故障排除 - 应用未显示。
自定义启动命令
可以通过在启动命令文件中提供自定义启动命令或多个命令来控制容器的启动行为。 启动命令文件可以使用你选择的任何名称,如 startup.sh、 startup.cmd或 startup.txt。
所有命令都必须使用相对于项目根文件夹的路径。
指定启动命令或命令文件:
Azure 门户。 在应用页面左窗格中的 “设置” 下,选择“ 配置”,然后选择“ 常规设置”。 在 “启动命令 ”框中,输入启动命令的全文或启动命令文件的名称。 然后,选择“保存”,应用所做的更改。 请参阅针对 Linux 容器的配置常规设置。
Azure CLI。 使用带参数的 az webapp config set 命令
--startup-file
来设置启动命令或文件:az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"
将
<custom-command>
替换为启动命令的全文或启动命令文件的名称。
应用服务会忽略处理自定义启动命令或文件时发生的任何错误,然后通过查找 Django 和 Flask 应用继续其启动过程。 如果未看到预期的行为,请验证启动命令或文件是否为无错误,以及应用代码是否已将启动命令文件部署到应用服务。 还可检查诊断日志以获取更多信息。 还可以在 Azure 门户上检查应用的“诊断并解决问题”页。
示例启动命令
添加了 Gunicorn 参数:以下示例将 参数添加到用于启动 Django 应用的 Gunicorn 命令行:
--workers=4
# <module-path> is the relative path to the folder that contains the module # that contains wsgi.py. <module> is the name of the folder that contains wsgi.py. gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
有关详细信息,请参阅“运行 Gunicorn”。 如果使用自动缩放规则来纵向扩展和缩减 Web 应用,则还应使用
NUM_CORES
启动命令中的环境变量动态设置 Gunicorn 辅助角色数。 例如,--workers $((($NUM_CORES*2)+1))
。 有关设置建议的 Gunicorn 工作线程数量的详细信息,请参阅 Gunicorn 常见问题解答为 Django 启动生产日志记录: 将
--access-logfile '-'
和--error-logfile '-'
参数添加到命令行:# '-' for the log files means stdout for --access-logfile and stderr for --error-logfile. gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'
这些日志将显示在应用服务日志流中。
有关详细信息,请参阅 Gunicorn 日志记录。
自定义 Flask 主模块:默认情况下,应用服务假定 Flask 应用的主模块是 application.py 或 app.py。 如果主模块使用不同的名称,则必须自定义启动命令。 例如,如果你有一个 Flask 应用,其主模块 是 hello.py ,而该文件中的 Flask 应用对象名为 myapp,则此命令如下:
gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp
如果主模块位于子文件夹中(如 网站),请使用
--chdir
参数指定该文件夹:gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp
使用非 Gunicorn 服务器:若要使用其他 web 服务器(如 aiohttp),请使用适当的命令作为启动命令或在启动命令文件中使用:
python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func
作为环境变量访问应用设置
应用设置是专门为应用存储在云中的值,如 “配置应用设置”中所述。 这些设置可作为环境变量提供给应用代码,并通过标准 os.environ 模式进行访问。
例如,如果创建调用 DATABASE_SERVER
的应用设置,以下代码将检索该设置的值:
db_server = os.environ['DATABASE_SERVER']
检测 HTTPS 会话
在应用服务中,TLS/SSL 终止在网络负载均衡器上发生,因此,所有 HTTPS 请求将以未加密的 HTTP 请求形式访问你的应用。 如果应用逻辑需要检查用户请求是否已加密,可以检查 X-Forwarded-Proto
标头。
if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used.
使用常用 Web 框架可以访问 X-Forwarded-*
标准应用模式中的信息。 例如,在 Django 中,可以使用 SECURE_PROXY_SSL_HEADER 将 Django 配置为使用 X-Forwarded-Proto
标头。
访问诊断日志
可以访问在容器中生成的控制台日志。
首先,请运行以下命令,以便启用容器日志记录功能:
az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem
将 <app-name>
和 <resource-group-name>
替换为适合 Web 应用的名称。
启用容器日志记录功能以后,请运行以下命令来查看日志流:
az webapp log tail --name <app-name> --resource-group <resource-group-name>
如果没有立即看到控制台日志,请在 30 秒后重新查看。
若要随时停止日志流式处理,可键入 CtrlC。
也可通过浏览器在 https://<app-name>.scm.chinacloudsites.cn/api/logs/docker
中检查日志文件。
若要访问 Azure 门户中的日志,请在应用的左窗格中选择“ 监视>日志流 ”。
访问部署日志
部署代码时,应用服务将在“ 自定义生成自动化 ”部分中执行前面所述的生成过程。 由于生成过程在自己的容器中运行,因此,生成日志与应用的诊断日志分开存储。
通过以下步骤访问部署日志:
- 在 Web 应用的 Azure 门户页上,选择左窗格中的 部署>部署中心 。
- 在“日志”选项卡上,选择最新提交的“提交 ID”。
- 在显示的 “日志详细信息 ”页上,选择“显示日志 ”链接 ,该链接显示在 正在运行的 oryx 生成旁边。
生成问题(如 requirements.txt 中的不正确依赖项和预生成或生成后脚本中的错误)将显示在这些日志中。 如果 requirements 文件没有命名为 requirements.txt 或者没有出现在项目的根文件夹中,也会出现错误。
在浏览器中打开 SSH 会话
若要通过容器打开直接的 SSH 会话,应用应该处于正在运行状态。
将以下 URL 粘贴到浏览器中,将 <app-name>
替换为应用名称:
https://<app-name>.scm.chinacloudsites.cn/webssh/host
如果尚未进行身份验证,则需通过要连接的 Azure 订阅进行身份验证。 完成身份验证以后,可以看到一个浏览器内 shell,可以在其中的容器中运行命令。
注意
在 /home 目录之外进行的任何更改均存储在容器本身中,在应用重启后不保留。
若要从本地计算机打开远程 SSH 会话,请参阅从远程 shell 打开 SSH 会话。
成功连接到 SSH 会话后,应该会在窗口底部显示“已建立 SSH 连接”消息。 如果看到“SSH_CONNECTION_CLOSED”之类的错误或指出容器正在重启的消息,则错误可能会阻止应用容器启动。 有关调查可能的问题的信息,请参阅 故障排除 。
URL 重写
在适用于 Linux 的应用服务上部署 Python 应用程序时,可能需要在应用程序中处理 URL 重写。 此方法特别适用于确保将特定 URL 模式重定向到正确的终结点,而无需依赖外部 Web 服务器配置。 对于 Flask 应用程序,可以使用 URL 处理器 和自定义中间件来实现此目的。 在 Django 应用程序中, URL 调度程序 可实现对 URL 重写的有效管理。
应用未显示
部署自己的应用代码后看到默认应用。 显示默认应用是因为你尚未将应用代码部署到应用服务,或者因为应用服务找不到应用代码并改为运行默认应用。
浏览器中会显示消息“服务不可用”。 浏览器超时,等待来自应用服务的响应。 这表示应用服务已启动 Gunicorn 服务器,但应用本身未启动。 此条件可能指示 Gunicorn 参数不正确,或者应用代码中存在错误。
找不到 setup.py 或 requirements.txt
日志流显示“找不到 setup.py 或 requirements.txt;未运行 pip 安装。” Oryx 生成过程找不到 requirements.txt 文件。
- 通过 SSH 连接到 Web 应用的容器,并验证 requirements.txt 的命名是否正确,以及是否就在 site/wwwroot 下。 如果该文件不存在,请使该文件存在于存储库中,并包含在部署中。 如果它存在于单独的文件夹中,请将其移到根文件夹下。
应用启动时出现 ModuleNotFoundError
如果看到类似 ModuleNotFoundError: No module named 'example'
错误,Python 在应用程序启动时找不到一个或多个模块。 使用代码来部署虚拟环境时最常发生此错误。 虚拟环境不是可移植的,因此不应使用应用程序代码来部署虚拟环境。 而应利用 Oryx 来创建虚拟环境,然后创建应用设置 SCM_DO_BUILD_DURING_DEPLOYMENT
并将其设置为 1
,通过这种方法在 Web 应用上安装包。 此设置强制 Oryx 在部署到应用服务时安装包。 有关详细信息,请参阅这篇有关虚拟环境可移植性的文章。
数据库已锁定
尝试使用 Django 应用运行数据库迁移时,可能会看到“sqlite3. OperationalError:数据库已锁定。”错误指示应用程序使用的是默认配置的 SQLite 数据库,而不是使用 Azure Database for PostgreSQL 等云数据库。
检查应用的 DATABASES
文件中的 变量,以确保应用使用的是云数据库,而不是 SQLite。
如果在使用教程:使用 PostgreSQL 部署 Django Web 应用中的示例时遇到此错误,请检查是否已完成验证连接设置中的步骤。
其他问题
在 SSH 会话中键入密码时,密码不显示:出于安全考虑,SSH 会话会在你键入密码时隐藏密码。 但是,正在记录这些字符,因此请像往常一样键入密码,并在完成后选择 Enter 。
SSH 会话中的命令似乎已中断:编辑器可能不是换行命令,但它们仍应正常运行。
静态资产不会出现在 Django 应用中:确保已启用 WhiteNoise 模块。
你将看到消息“需要致命 SSL 连接”:检查用于从应用内访问资源(如数据库)的任何用户名和密码。