設定適用於 Azure App Service 的 Linux Python 應用程式

  • 發行項

本文說明 Azure App Service 如何執行 Python 應用程式、您如何將現有的應用程式遷移至 Azure，以及如何在需要時自訂 App Service 的行為。 您必須使用所有必要的 pip 模組來部署 Python 應用程式。

當您部署 Git 存放庫，或已啟用組建自動化的 Zip 套件時，App Service 部署引擎會自動啟動虛擬環境，並為您執行 pip install -r requirements.txt。

本指南為在 App Service 中使用內建 Linux 容器的 Python 開發人員提供了重要概念和指示。 如果您從未使用過 Azure App Service，請先遵循 Python 快速入門和 Python with PostgreSQL 教學課程。

您可以使用 Azure 入口網站或 Azure CLI 進行設定：

注意

Linux 是在 App Service 中執行 Python 應用程式的唯一作業系統選項。 Windows 上的 Python 已不再受到支援。 不過，您可以建置自己的自訂 Windows 容器映像，並在 App Service 中執行該映像。 如需詳細資訊，請參閱使用自訂 Docker 映像。

設定 Python 版本

  • Azure 入口網站：使用 [組態] 頁面上的 [一般設定] 索引標籤，如針對 Linux 容器設定一般設定所述。

  • Azure CLI：

    • 使用 az webapp config show 顯示目前的 Python 版本：

      az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

      以適合您 Web 應用程式的名稱取代 <resource-group-name> 和 <app-name>。

    • 使用 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顯示 Azure App Service 中支援的所有 Python 版本：

      az webapp list-runtimes --os linux | grep PYTHON

您可以改為建置您自己的容器映像，以執行不支援的 Python 版本。 如需詳細資訊，請參閱使用自訂 Docker 映像。

自訂組建自動化

當您部署應用程式時，如果應用程式設定 SCM_DO_BUILD_DURING_DEPLOYMENT 設定為 1，App Service 的組建系統 (稱為 Oryx) 會執行下列步驟：

  1. 如果自訂建置前指令碼由 PRE_BUILD_COMMAND 設定指定，請加以執行。 (指令碼本身可以執行其他 Python 和 Node.js 指令碼、pip 和 npm 命令，以及 yarn 之類的 Node 型工具，例如 yarn install 和 yarn build。)

  2. 執行 pip install -r requirements.txt。 requirements.txt 檔案必須存在於專案的根資料夾中。 否則，組建流程會回報錯誤：「找不到 setup.py 或 requirements.txt；未執行 pip install。」

  3. 如果在存放庫的根目錄中找到 manage.py(表示 Django 應用程式)，請執行 manage.py collectstatic。 不過，如果 DISABLE_COLLECTSTATIC 設定為 true，則會略過此步驟。

  4. 如果自訂建置後指令碼由 POST_BUILD_COMMAND 設定指定，請加以執行。 (同樣地，指令碼可以執行其他 Python 和 Node.js 指令碼、pip 和 npm 命令，以及 Node 型工具。)

根據預設，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 設定。

若要存取組建和部署記錄，請參閱存取部署記錄。

若要深入了解 App Service 如何在 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 命令 az webapp up和 Visual Studio Code 進行部署時，此設定為 true。

注意

在所有的建置前和建置後指令碼中一律使用相對路徑，因為 Oryx 執行所在的建置容器與執行應用程式執行所在的執行階段容器不同。 絕對不要依賴應用程式專案資料夾在容器中的確切位置 (例如，其會放在 site/wwwroot 之下)。

將現有的應用程式遷移至 Azure

現有的 Web 應用程式可以重新部署至 Azure，如下所示：

  1. 來源存放庫：在適合的存放庫 (例如 GitHub) 中維護原始程式碼，這可讓您稍後在此程序中設定持續部署。

    • 您的 requirements.txt 檔案必須位於存放庫的根目錄，App Service 才能自動安裝必要的套件。

  2. 資料庫：如果應用程式相依於資料庫，則也請在 Azure 上建立必要的資源。

  3. 應用程式服務資源：建立資源群組、App Service 方案和 App Service Web 應用程式，以裝載應用程式。 您可以執行 Azure CLI 命令 az webapp up 來輕鬆執行。 或者，您可以建立和部署資源，如教學課程：使用 PostgreSQL 部署 Python (Django 或 Flask) Web 應用程式所示。 請取代資源群組、App Service 方案和 Web 應用程式的名稱，使其更適合您的應用程式。

  4. 環境變數：如果應用程式需要任何環境變數，請建立對等的 App Service 應用程式設定。 這些 App Service 設定會以環境變數的形式顯示在您的程式碼中，如存取環境變數所說明。

  5. 應用程式啟動：檢閱本文稍後的容器啟動程序一節，以了解 App Service 如何嘗試執行應用程式。 App Service 依預設會使用 Gunicorn Web 伺服器，而此伺服器必須能夠找到您的應用程式物件或 wsgi.py 資料夾。 如有需要，您可以自訂啟動命令。

  6. 持續部署：如持續部署至 Azure App Service 一文所述，從 GitHub Actions、Bitbucket 或 Azure Repos 設定持續部署。 或者，如將本機 Git 部署至 Azure App Service 一文所述，從本機 Git 設定持續部署。

  7. 自訂動作：若要在裝載應用程式的 App Service 容器中執行動作 (例如 Django 資料庫移轉)，您可以透過 SSH 連線至容器。 如需執行 Django 資料庫移轉的範例，請參閱教學課程：使用 PostgreSQL 部署 Django Web 應用程式 - 產生資料庫結構描述。

    • 使用持續部署時，您可以使用建置後命令來執行這些動作，如先前的自訂組建自動化所說明。

完成這些步驟之後，您就應該能夠將變更認可至來源存放庫，並將這些更新自動部署至 App Service。

Django 應用程式的生產環境設定

對於 Azure App Service 之類的生產環境，Django 應用程式應遵循 Django 的部署檢查清單 (djangoproject.com)。

下表描述與 Azure 相關的生產環境設定。 這些設定會定義於應用程式的 setting.py 檔案中。

Django 設定 Azure 的指示
SECRET_KEY 如以環境變數的形式存取應用程式設定所述，將值儲存在 App Service 設定中。 您也可以在 Azure Key Vault 中將值儲存為「秘密」。
DEBUG 請在值為 0 (false) 的 App Service 上建立 DEBUG 設定，然後將此值載入為環境變數。 在您的開發環境中，使用值 1 (true) 建立 DEBUG 環境變數。
ALLOWED_HOSTS 在生產環境中，Django 會要求您在 settings.py 的 ALLOWED_HOSTS 陣列中包含應用程式的 URL。 您可以在執行階段使用程式碼 os.environ['WEBSITE_HOSTNAME']擷取此 URL。 App Service 會自動將 WEBSITE_HOSTNAME 環境變數設定為應用程式的 URL。
DATABASES 在資料庫連線的 App Service 中定義設定，並將其載入為環境變數以填入 DATABASES 字典中。 或者，您可以將值 (尤其是使用者名稱和密碼) 儲存為 Azure Key Vault 秘密。

提供 Django 應用程式的靜態檔案

如果您的 Django Web 應用程式包含靜態前端檔案，請先遵循 Django 文件中有關管理靜態檔案的指示。

針對 App Service，接著進行下列修改：

  1. 考慮使用環境變數 (若為本機開發) 和應用程式設定 (部署至雲端時)，以動態設定 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/，以避免使用預設。

  2. 如果您有預先組建的指令碼在另一個資料夾中產生靜態檔案，請將該資料夾納入 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 之類的組建工具。 同樣地，您可以視需要使用環境變數和應用程式設定。

  3. 在 requirements.txt 檔案中新增 whitenoise。 Whitenoise (whitenoise.evans.io) 是 Python 套件，可讓生產 Django 應用程式輕鬆提供其自己的靜態檔案。 Whitenoise 明確提供在 Django STATIC_ROOT 變數所指定的資料夾中找到的檔案。

  4. 在 settings.py 檔案中，為 Whitenoise 新增下列這一行：

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. 此外，將 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)

容器的特性

若部署至 App Service，Python 應用程式會在 App Service Python GitHub 存放庫中定義的 Linux Docker 容器內執行。 您可以在屬於特定版本的目錄內找到映像設定。

此容器具有下列特性︰

  • 應用程式在執行時所使用的是 Gunicorn WSGI HTTP 伺服器，並且使用額外引數 --bind=0.0.0.0 --timeout 600。

    • 您可以自訂啟動命令，以便提供 Gunicorn 的組態設定。

    • 為了保護您的 Web 應用程式免於遭受意外或刻意的 DDOS 攻擊，Gunicorn 會在 Nginx 反向 Proxy 後面執行，如部署 Gunicorn (docs.gunicorn.org) 所述。

  • 根據預設，基底容器映像只包含 Flask Web 架構，但容器也可支援其他符合 WSGI 標準且相容於 Python 3.6+ 的架構，例如 Django。

  • 若要安裝其他套件 (例如 Django)，請在專案的根目錄中建立 requirements.txt 檔案，而此檔案指定您的直接相依性。 然後 App Service 會在您部署專案時自動安裝這些相依性。

    requirements.txt 檔案「必須」位於專案根目錄中，才能安裝相依性。 否則，組建流程會回報錯誤：「找不到 setup.py 或 requirements.txt；未執行 pip install。」如果您遇到此錯誤，請檢查 requirements 檔案的位置。

  • App Service 會使用 Web 應用程式的 URL (例如 msdocs-hello-world.azurewebsites.net)，自動定義名為 WEBSITE_HOSTNAME 的環境變數。 其也會使用您的應用程式名稱 (例如 msdocs-hello-world) 來定義 WEBSITE_SITE_NAME。

  • npm 和 Node.js 安裝在容器中，因此您可以執行 Node 型組建工具，例如 yarn。

容器的啟動程序

在啟動期間，Linux 容器上的 App Service 會執行下列步驟：

  1. 使用自訂的啟動命令 (如果有提供的話)。
  2. 檢查 Django 應用程式是否存在，如果偵測到，則為其啟動 Gunicorn。
  3. 檢查 Flask 應用程式是否存在，如果偵測到，則為其啟動 Gunicorn。
  4. 如果找不到其他應用程式，則請啟動容器內建的預設應用程式。

下列各節提供每個選項的額外詳細資料。

Django 應用程式

針對 Django 應用程式，App Service 會尋找應用程式的程式碼內名為 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 的資料夾名稱，然後新增 --chdir 引數 (若該模組不在專案根目錄中)。 例如，如果您的 wsgi.py 位於專案根目錄的 knboard/backend/config 之下，請使用引數 --chdir knboard/backend config.wsgi。

若要啟用生產環境記錄功能，請新增 --access-logfile 和 --error-logfile 參數，如自訂啟動命令的範例所示。

Flask 應用程式

針對 Flask，App Service 會尋找名為 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 提供其他引數，則請使用自訂啟動命令。

預設行為

如果 App Service 找不到自訂命令、Django 應用程式或 Flask 應用程式，則會執行位於 opt/defaultsite 資料夾中的預設唯讀應用程式，如下圖所示。

如果您已部署程式碼，但仍看到預設應用程式，請參閱疑難排解 - 應用程式未顯示。

Screenshot of the default App Service on Linux web page.

同樣地，如果您預期會看到已部署的應用程式，而不是預設應用程式，請參閱疑難排解 - 應用程式未顯示。

自訂啟動命令

您可以在啟動命令檔案中提供自訂啟動命令或多個命令，以控制容器的啟動行為。 啟動命令檔案可以使用您選擇的任何名稱，例如 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>替換為您啟動命令的全文或啟動命令檔案的名稱。

App Service 會忽略在處理自訂啟動命令或檔案時所發生的任何錯誤，然後藉由尋找 Django 和 Flask 應用程式來繼續其啟動程序。 如果您看不到預期的行為，請檢查啟動命令或檔案是否沒有錯誤，以及是否已將啟動命令檔案部署至 App Service 與應用程式程式碼。 您也可以查看診斷記錄以取得詳細資訊。 另外，在 Azure 入口網站上查看應用程式的 [診斷並解決問題] 頁面。

範例啟動命令

  • 新增的 Gunicorn 引數：下列範例會將 --workers=4 新增至 Gunicorn 命令列，以便啟動 Django 應用程式：

    # <module-path> is the relative path to the folder that contains the module
# that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    如需詳細資訊，請參閱執行 Gunicorn (docs.gunicorn.org)。 如果您使用自動調整規則隨之增加和減少 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 '-'

    這些記錄會出現在 App Service 記錄資料流中。

    如需詳細資訊，請參閱 Gunicorn 記錄 (docs.gunicorn.org)。

  • 自訂 Flask 主要模組：根據預設，App Service 假設 Flask 應用程式的主要模組為 application.py 或 app.py。 如果您的主要模組使用不同的名稱，您就必須自訂啟動命令。 例如，如果您擁有的 Flask 應用程式，而其主要模組是 hello.py，且該檔案中的 Flask 應用程式物件名為 myapp，則命令如下所示：

    gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp

    如果您的主要模組位於子資料夾中 (例如 website)，請使用 --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 工作階段

在 App Service 中，TLS/SSL 終止 (wikipedia.org) 發生在網路負載平衡器上，因此，所有 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

以適合您 Web 應用程式的名稱取代 <app-name> 和 <resource-group-name>。

開啟容器記錄後，請執行下列命令來查看記錄資料流：

az webapp log tail --name <app-name> --resource-group <resource-group-name>

如果您沒有立即看到主控台記錄，請在 30 秒後再查看。

若要隨時停止記錄資料流，請輸入 Ctrl+C。

您也可以在瀏覽器中的 https://<app-name>.scm.azurewebsites.net/api/logs/docker 檢查記錄檔。

若要透過 Azure 入口網站存取記錄，請在應用程式的左側功能表上選取 [監視]>[記錄資料流]。

存取部署記錄

當您部署程式碼時，App Service 會執行先前在自訂組建自動化一節中說明的建置程序。 由於組建會在本身的容器中執行，因此，組建記錄會與應用程式的診斷記錄分開儲存。

使用下列步驟存取部署記錄：

  1. 在 Web 應用程式的 Azure 入口網站上，選取左側功能表上的 [部署]> [部署中心]。
  2. 在 [記錄] 索引標籤上，選取最新認可的 [認可識別碼]。
  3. 在出現的 [記錄詳細資料] 頁面上，選取出現在 [正在執行 oryx 組建...] 旁的 [顯示記錄...] 連結。

建置問題 (例如 requirements.txt 中的相依性不正確) 和前置前或建置後指令碼中的錯誤會出現在這些記錄中。 如果您的需求檔案未確切命名為 requirements.txt，或未出現在專案的根資料夾中，則也會出現錯誤。

在瀏覽器中開啟 SSH 工作階段

若要透過容器直接開啟 SSH 工作階段，您的應用程式應在執行中。

在瀏覽器中貼入下列 URL，並以您的應用程式名稱取代 <app-name>：

https://<app-name>.scm.azurewebsites.net/webssh/host

如果您尚未經過驗證，必須向您的 Azure 訂用帳戶進行驗證才能連線。 驗證之後，您會看到瀏覽器中的殼層，您可以在其中執行您容器內的命令。

SSH connection

注意

您在 /home 目錄以外進行的任何變更都會儲存在容器中，在應用程式重新啟動之後便不會保存。

若要從本機電腦開啟遠端 SSH 工作階段，請參閱從遠端殼層開啟 SSH 工作階段。

當您成功連線至 SSH 工作階段時，您應該會在視窗底部看到「已建立 SSH 連線」訊息。 如果您看到 "SSH_CONNECTION_CLOSED" 之類的錯誤，或容器正在重新開機的訊息，表示可能有錯誤導致應用程式容器無法啟動。 如需調查可能問題的步驟，請參閱疑難排解。

疑難排解

一般而言，疑難排解的第一個步驟是使用 App Service 診斷：

  1. 在 Web 應用程式的 Azure 入口網站上，從左側功能表中選取 [診斷並解決問題]。
  2. 選取 [可用性和效能]。
  3. 檢查 [應用程式記錄]、[容器損毀] 和 [容器問題] 選項中的資訊，大部分的常見問題都會顯示於這些位置。

接著，請檢查部署記錄和應用程式記錄中是否有任何錯誤訊息。 這些記錄通常會識別可能阻礙應用程式部署或應用程式啟動的特定問題。 例如，如果您的 requirements.txt 檔案具有錯誤的檔案名稱或不存在於專案根資料夾中，建置可能會失敗。

下列各節提供特定問題的指導。

應用程式未出現

  • 您在部署自己的應用程式程式碼之後，卻看到預設應用程式。 之所以出現預設應用程式，是因為您未將應用程式程式碼部署至 App Service，或 App Service 找不到應用程式程式碼，而改為執行預設應用程式。

    • 重新啟動 App Service，等候 15 到 20 秒，然後再檢查一次應用程式。

    • 使用 SSH 直接連線至 App Service 容器，並確認您的檔案存在於 site/wwwroot 底下。 如果您的檔案不存在，請使用下列步驟：

      1. 建立名為 SCM_DO_BUILD_DURING_DEPLOYMENT、值為 1 的應用程式設定，然後重新部署您的程式碼，並在幾分鐘後再次嘗試存取應用程式。 如需建立應用程式設定的詳細資訊，請參閱在 Azure 入口網站中設定 App Service 應用程式。
      2. 檢閱您的部署程序，查看部署記錄並更正任何錯誤，然後重新部署應用程式。

    • 如果檔案存在，App Service 卻無法識別特定的啟動檔案。 請檢查應用程式的結構是否符合 App Service 對 Django 或 Flask 的預期，或者，您也可以使用自訂啟動命令。

  • 您在瀏覽器中看到「服務無法使用」訊息。瀏覽器在等候 App Service 的回應逾時時，這表示 App Service 已啟動 Gunicorn 伺服器，但應用程式本身並未啟動。 這種情況可能表示 Gunicorn 引數不正確，或應用程式程式碼有錯誤。

    • 重新整理瀏覽器，如果您使用 App Service 方案中的最低定價層，更應該如此。 舉例來說，如果您使用免費層，應用程式可能需要更久的時間才能啟動，在您重新整理瀏覽器後，應用程式便會有回應。

    • 請檢查應用程式的結構是否符合 App Service 對 Django 或 Flask 的預期，或者，您也可以使用自訂啟動命令。

    • 檢查應用程式記錄資料流中是否有任何錯誤訊息。 記錄會顯示應用程式程式碼中的任何錯誤。

找不到 setup.py 或 requirements.txt

  • 記錄資料流會顯示「找不到 setup.py 或 requirements.txt；未執行 pip install。」：Oryx 建置程序找不到 requirements.txt 檔案。

    • 透過 SSH 連線至 Web 應用程式的容器，並確認 requirements.txt 已正確命名，且存在於 site/wwwroot 下。 如果不存在，請將該檔案放在您的存放庫中，並包含在您的部署中。 如果其存在於不同資料夾中，請將其移至根目錄。

應用程式啟動時發生 ModuleNotFoundError

如果您看到類似 ModuleNotFoundError: No module named 'example' 的錯誤，則這表示應用程式啟動時，Python 找不到一或多個模組。 此錯誤在您將虛擬環境連同程式碼一起部署時最常發生。 虛擬環境無法移植，因此虛擬環境不應該連同應用程式程式碼一起部署。 相反地，請建立應用程式設定 SCM_DO_BUILD_DURING_DEPLOYMENT 並設定為 1，讓 Oryx 建立虛擬環境並在 Web 應用程式上安裝您的封裝。 此設定會強制 Oryx 在您每次部署至 App Service 時安裝您的套件。 如需詳細資訊，請參閱虛擬環境可攜性一文。

資料庫已鎖定

嘗試使用 Django 應用程式執行資料庫移轉時，您可能會看到「sqlite3. OperationalError：資料庫已鎖定。」此錯誤表示應用程式使用預設已設定 Django 的 SQLite 資料庫，而不是使用雲端資料庫，例如適用於 Azure 的 PostgreSQL。

在應用程式的 settings.py 檔案中檢查 DATABASES 變數，確定您的應用程式使用雲端資料庫，而不是 SQLite。

如果您在教學課程：部署具有 PostgreSQL 的 Django Web 應用程式中執行範例時遇到此錯誤，則請檢查您是否已完成驗證連線設定中的步驟。

其他問題

  • 密碼在輸入時不會出現在 SSH 工作階段中：基於安全考量，當您輸入密碼時，SSH 工作階段會隱藏您的密碼。 但字元會記錄下來，因此，請如常輸入您的密碼，然後在完成時按 Enter 鍵。

  • SSH 工作階段中的命令似乎遭到中斷：編輯器可能不會將命令自動換行，但應該仍會正常執行。

  • 靜態資產不會出現在 Django 應用程式中：請確定您已啟用 whitenoise 模組

  • 您會看到「需要嚴重 SSL 連線」訊息：請檢查用來從應用程式存取資源 (例如資料庫) 時所用的任何使用者名稱和密碼。

更多資源