Azure App Service 向けの Linux Python アプリを構成する

この記事では、 Azure App Service で Python アプリを実行する方法、既存のアプリを Azure に移行する方法、必要に応じて App Service の動作をカスタマイズする方法について説明します。 Python アプリは、必要なすべての pip モジュールと共にデプロイする必要があります。

App Service デプロイ エンジンは、pip install -r requirements.txtをデプロイするとき、またはビルド自動化が有効になっているzip パッケージをデプロイするときに、仮想環境を自動的にアクティブ化し、実行します。

このガイドでは、App Service の組み込み Linux コンテナーを使用する Python 開発者のために、主要な概念と手順を示します。 Azure App Service を使用したことがない場合は、まず 、Python のクイックスタート と、PostgreSQL を使用した Flask、 Django、または FastAPI のチュートリアルに従ってください。

構成には 、Azure portal または Azure CLI のいずれかを使用できます。

• Azure portal で、「Azure portal での App Service アプリの構成」の説明に従って、アプリの [設定>構成] ページを使用します。

• Azure CLI: 2 つのオプションがあります。

  • Azure Cloud Shell でコマンドを実行します。
  • 最新バージョンの Azure CLI をインストールしてコマンドをローカルで実行し、 az login を使用して Azure にサインインします。

Python バージョンの構成

• Azure portal: Linux コンテナーの 全般設定 の構成の説明に従って、[ 構成 ] ページの [ 全般設定] タブを使用します。

• Azure CLI:

  • az webapp config show で現在の 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 を使用して、Azure App Service でサポートされているすべての Python バージョンを表示します。

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

サポートされない Python バージョンを実行するには、代わりに独自のコンテナー イメージを作成します。 詳細については、 カスタム Docker イメージの使用に関する記事を参照してください。

App Service の古いランタイムはどうなりますか?

古いランタイムは、保守組織によって非推奨になったり、重大な脆弱性が見つかったりします。 そのため、ポータルの作成ページと構成ページから削除されます。 古いランタイムがポータルから非表示になっている場合、そのランタイムをまだ使用しているアプリは引き続き実行されます。

ポータルに表示されなくなった古いランタイム バージョンのアプリを作成する場合は、Azure CLI、ARM テンプレート、または Bicep を使用します。 これらのデプロイの代替手段を使用すると、ポータルで削除されたが、引き続きサポートされている非推奨のランタイムを作成できます。

ランタイムが App Service プラットフォームから完全に削除された場合、Azure サブスクリプション所有者は削除前に電子メール通知を受け取ります。

ビルドの自動化のカスタマイズ

Oryx と呼ばれる App Service のビルド システムでは、アプリの設定 SCM_DO_BUILD_DURING_DEPLOYMENT が 1 に設定されていると、アプリをデプロイする際に次のステップが実行されます。

1. この手順を PRE_BUILD_COMMAND 設定で指定した場合は、カスタムのビルド前スクリプトを実行します。 このスクリプトはそれ自体で、他の Python スクリプトや Node.js スクリプト、pip コマンド、npm コマンド、さらに、yarn など Node ベースのツール (例: yarn install、yarn build) を実行できます。

2. pip install -r requirements.txt を実行します。 requirements.txt ファイルは、プロジェクトのルート フォルダーに存在する必要があります。 そうでないと、ビルド プロセスでエラーがレポートされます: "Could not find setup.py or requirements.txt; Not running pip install." (setup.py または requirements.txt が見つかりませんでした; pip install が実行されていません。)

3. リポジトリ の ルート (Django アプリを示す) に manage.py が見つかった場合は、 collectstatic manage.py 実行します。 ただし、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 アプリを検出してビルドする方法」を参照してください。

pyproject.toml から requirements.txt を生成する

現時点では、App Service は pyproject.toml を直接サポートしていません。 詩や紫外線などのツールを使用している場合は、プロジェクトのルートに配置する前に互換性のある requirements.txt を生成することをお勧めします。

詩の使用

エクスポート プラグインで詩を使用する:

poetry export -f requirements.txt --output requirements.txt --without-hashes

uv の使用

uv の使用:

uv export --format requirements-txt --no-hashes --output-file requirements.txt

既存のアプリケーションを Azure に移行する

既存の Web アプリケーションは、次のように Azure に再デプロイできます。

1. ソース リポジトリ: GitHub などの適切なリポジトリにソース コードを保持します。これにより、このプロセスの後半で継続的デプロイを設定できます。

   • 必要なパッケージを自動的にインストールするには、requirements.txtファイルが App Service のリポジトリのルートにある必要があります。

2. データベース: アプリがデータベースに依存している場合は、Azure にも必要なリソースを作成します。

3. App Service リソース: アプリケーションをホストするリソース グループ、App Service プラン、App Service Web アプリを作成します。 この処理を簡単に行うには、Azure CLI コマンド az webapp up を実行します。 または、PostgreSQL チュートリアルで Flask、 Django、または FastAPI に示されているように、リソースを作成してデプロイすることもできます。 リソース グループ、App Service プラン、Web アプリの名前を、対象のアプリケーションにより適した名前に置き換えます。

4. 環境変数: アプリケーションに環境変数が必要な場合は、同等の App Service アプリケーション設定を作成します。 これらの App Service 設定は、 Access 環境変数の説明に従って、環境変数としてコードに表示されます。

   • たとえば、データベース接続は、多くの場合、「 チュートリアル: PostgreSQL を使用して Django Web アプリをデプロイする - 接続設定を確認する」に示すように、このような設定を使用して管理されます。
   • 一般的 な Django アプリの特定の設定については、Django アプリの運用 設定を参照してください。

5. アプリの起動: この記事の後半の「 コンテナーの起動プロセス 」セクションを確認して、App Service がアプリの実行を試みる方法を理解します。 App Service では、既定で Gunicorn Web サーバーが使用されます。これは、アプリ オブジェクトまたは wsgi.py フォルダーを検索できる必要があります。 必要に応じて、 スタートアップ コマンドをカスタマイズできます。

6. 継続的デプロイ: GitHub Actions、Bitbucket、または Azure Repos からの継続的デプロイを、Azure App Service への継続的デプロイに関する記事で説明されているように設定します。 または、 Azure App Service へのローカル Git デプロイに関する記事の説明に従って、ローカル Git からの継続的デプロイを設定します。

7. カスタム アクション: Django データベースの移行など、アプリをホストする App Service コンテナー内でアクションを実行するには、 SSH 経由でコンテナーに接続します。 Django データベースの移行の実行例については、「 チュートリアル: PostgreSQL を使用して Django Web アプリをデプロイする - データベース スキーマを生成する」を参照してください。

   • 継続的配置を使用する場合は、「ビルド自動化のカスタマイズ」で前述したように、ビルド後のコマンドを使用してこれらのアクション を実行できます。

これらの手順を完了すると、変更をソース リポジトリにコミットし、それらの更新を App Service に自動的にデプロイできるようになります。

Django アプリの運用設定

Azure App Service などの運用環境の場合、Django アプリは Django の デプロイ チェックリストに従う必要があります。

次の表では、Azure に関連する運用設定について説明しています。 これらの設定は、アプリの setting.py ファイルで定義されます。

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 を実行し、静的ファイルを含んだ build/static フォルダーが yarn によって生成される場合、次のようにしてそのフォルダーを追加します。

   FRONTEND_DIR = "path-to-frontend-folder" 
   STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]    
   

   ここでは、FRONTEND_DIR を使用して、yarn などのビルド ツールが実行される場所のパスを構築しています。 ここでも、必要に応じて環境変数とアプリ設定を使用できます。

3. whitenoise をrequirements.txtファイルに追加します。 WhiteNoise (whitenoise.evans.io) は Python パッケージであり、運用 Django アプリが独自の静的ファイルを提供しやすくします。 具体的に言うと、Django の STATIC_ROOT 変数で指定されたフォルダーに見つかったファイルを WhiteNoise が応答として返します。

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 の構成設定を指定できます。

  • 偶発的または意図的な DDOS 攻撃から Web アプリを保護するために、「Gunicorn のデプロイ」で説明されているように、 Gunicorn は Nginx リバース プロキシの背後で実行されます。

• 既定では、基本のコンテナー イメージには Flask Web フレームワークのみが含まれています。ただし、コンテナーは、WSGI に準拠していて Python 3.6 以上と互換性のある他のフレームワーク (Django など) をサポートしています。

• Django などの他のパッケージをインストールするには、直接の依存関係を指定する requirements.txt ファイルをプロジェクトのルートに作成します。 そうすることで、App Service によって、それらの依存関係がプロジェクトのデプロイ時に自動的にインストールされます。

  依存関係をインストールするには、requirements.txtファイルがプロジェクト ルートに存在する必要があります。 それ以外の場合、ビルド プロセスによってエラー "setup.py または requirements.txt が見つかりませんでした。pip install が実行されていません。" が報告されます。このエラーが発生した場合は、要件ファイルの場所を確認してください。

• App Service では、Web アプリの URL (WEBSITE_HOSTNAME など) を使用して、msdocs-hello-world.azurewebsites.net という名前の環境変数が自動的に定義されます。 また、アプリの名前 (WEBSITE_SITE_NAME など) を使用して msdocs-hello-world も定義されます。

• Node ベースのビルド ツール (yarn など) を実行できるよう、コンテナーには npm と Node.js がインストールされます。

コンテナーのスタートアップ プロセス

App Service on Linux コンテナーでは、起動中に次の手順が実行されます。

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 フォルダーにある既定の読み取り専用アプリが実行され、次の図に示されます。

コードをデプロイしても既定のアプリが表示される場合は、「 トラブルシューティング - アプリが表示されない」を参照してください。

スタートアップ コマンドのカスタマイズ

スタートアップ コマンド ファイルでカスタム スタートアップ コマンドまたは複数のコマンドを指定して、コンテナーのスタートアップ動作をコントロールできます。 スタートアップ コマンド ファイルでは、startup.sh、startup.cmd、startup.txt など、任意の名前を使用できます。

どのコマンドでも、プロジェクトのルート フォルダーへの相対パスを使用する必要があります。

スタートアップ コマンドまたはコマンド ファイルを指定するには:

• Azure portal: アプリの [構成] ページを選択し、[ 全般設定] を選択します。 [ スタートアップ コマンド ] フィールドに、スタートアップ コマンドのフルテキストまたはスタートアップ コマンド ファイルの名前を入力します。 次に、[ 保存] を選択して変更を適用します。 「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 portal のアプリの [問題の診断と解決] ページも確認します。

スタートアップ コマンドの例

• 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 containing wsgi.py.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
  

  詳細については、「 グニコーンの実行」を参照してください。 自動スケーリング ルールを使って Web アプリをスケールアップまたはスケールダウンする場合は、スタートアップ コマンドで NUM_CORES 環境変数を使って、Gunicorn ワーカーの数を動的に設定する必要もあります (例: --workers $((($NUM_CORES*2)+1)))。 Gunicorn ワーカーの推奨数の設定の詳細については、 グニコーンに関する FAQ を参照してください。

• 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 ログ ストリームに表示されます。

  詳細については、「 グニコーンのログ記録」を参照してください。

• カスタム Flask メイン モジュール: 既定では、App Service は Flask アプリのメイン モジュールが application.py または app.py であると想定しています。 メイン モジュールに別の名前を使用する場合は、スタートアップ コマンドをカスタマイズする必要があります。 たとえば、メイン モジュールが hello.py されている Flask アプリがあり、そのファイル内の 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 以外のサーバーを使用する: aiohttp などの別の Web サーバーを使用するには、スタートアップ コマンドまたはスタートアップ コマンド ファイルで適切なコマンドを使用します。

  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 終了 はネットワーク ロード バランサーで行われるため、すべての 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 を使用して、 X-Forwarded-Proto ヘッダーを使用するように Django に指示できます。

診断ログにアクセスする

コンテナー内から生成されたコンソール ログにアクセスできます。

コンテナーのログを有効にするには、次のコマンドを実行します。

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 秒後にもう一度確認してください。

ログ ストリーミングをいつでも停止するには、Ctrl+ キーを押します。

Azure portal からログにアクセスするには、アプリの左側のメニューで [ 監視>ログ ストリーム ] を選択します。

デプロイ ログにアクセスする

コードをデプロイすると、「ビルド自動化のカスタマイズ」セクションで前述したビルド プロセスが App Service によって実行 されます。 ビルドはそれ独自のコンテナー内で実行されるため、ビルド ログは、アプリの診断ログとは別に格納されます。

デプロイ ログにアクセスするには、次の手順を使用します。

1. Web アプリの Azure portal で、左側のメニューで [デプロイ>デプロイ センター ] を選択します。
2. [ ログ ] タブで、最新の コミットのコミット ID を 選択します。
3. 表示された [ログの詳細 ] ページで、[実行中の oryx build...] の横に表示される [ ログの表示 ] リンクを選択します。

ビルドの問題 ( requirements.txt の間違った依存関係など)、ビルド前またはビルド後のスクリプトのエラーがこれらのログに表示されます。 要件ファイルの名前が requirements.txt されていない場合、またはプロジェクトのルート フォルダーに表示されない場合も、エラーが表示されます。

ブラウザーで SSH セッションを開く

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。

az webapp ssh コマンドを使用します。

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。

ローカル コンピューターからリモート SSH セッションを開くには、「 リモート シェルから SSH セッションを開く」を参照してください。

SSH セッションへの接続に成功すると、ウィンドウ下部に "SSH CONNECTION ESTABLISHED (SSH 接続が確立されました)" というメッセージが表示されます。 "SSH_CONNECTION_CLOSED" などのエラーや、コンテナーが再起動されているというメッセージが表示される場合は、エラーが原因でアプリ コンテナーが起動できなくなっている可能性があります。 考えられる問題を調査する手順については、「 トラブルシューティング 」を参照してください。

URL の書き換え

Python アプリケーションを Azure App Service for Linux にデプロイする場合は、アプリケーション内で URL の書き換え処理を行う必要がある場合があります。 これは、外部の Web サーバーの構成に依存せずに、特定の URL パターンが正しいエンドポイントにリダイレクトされるようにするために特に便利です。 Flask アプリケーションでは、 URL プロセッサ とカスタム ミドルウェアを使用してこれを実現できます。 Django アプリケーションでは、堅牢な URL ディスパッチャー を使用して、URL 書き換えを効率的に管理できます。

トラブルシューティング

一般に、トラブルシューティングにおける最初の手順は、App Service 診断を使用することです。

1. Web アプリの Azure portal で、左側のメニューから [問題の診断と解決 ] を選択します。
2. [ 可用性とパフォーマンス] を選択します。
3. 最も一般的な問題が表示される アプリケーション ログ、 コンテナー クラッシュ、 コンテナーの問題 のオプションの情報を確認します。

次に、 デプロイ ログ と アプリ ログ の両方でエラー メッセージがないか調べます。 アプリのデプロイや起動を妨げる特定の問題が、これらのログによって明らかになることが少なくありません。 たとえば、 requirements.txt ファイルのファイル名が間違っているか、プロジェクトのルート フォルダーに存在しない場合、ビルドが失敗する可能性があります。

具体的な問題のガイダンスについては、次のセクションを参照してください。

• アプリが表示されない - 既定のアプリが表示される
• アプリが表示されない - "サービスが利用できません" というメッセージ
• setup.py または requirements.txtが見つかりませんでした
• スタートアップ時の ModuleNotFoundError
• データベースがロックされている
• 入力時にパスワードが SSH セッションに表示されない
• SSH セッションのコマンドが途切れているように見える
• Django アプリに静的アセットが表示されない
• 致命的な SSL 接続が必要

アプリが表示されない

• 自分のアプリ コードをデプロイした後に既定のアプリが表示される。 既定のアプリが表示されるのは、アプリ コードを App Service にデプロイしていないか、App Service がアプリ コードを見つけて既定のアプリを実行できなかったためです。

  • App Service を再起動し、15 から 20 秒待って、アプリをもう一度確認します。

  • SSH を使用して App Service コンテナーに直接接続し、ファイルが site/wwwroot の下に存在することを確認します。 ファイルが存在しない場合は、次の手順を実行します。

    1. SCM_DO_BUILD_DURING_DEPLOYMENT という名前のアプリ設定を作成し、その値を 1 とします。コードを再デプロイして、数分待ってから、再度アプリにアクセスを試みます。 アプリ設定の作成の詳細については、 Azure portal での App Service アプリの構成に関するページを参照してください。
    2. デプロイ プロセスを確認し、 デプロイ ログを確認し、エラーを修正して、アプリを再デプロイします。

  • ファイルが存在する場合は、お客様固有のスタートアップ ファイルを App Service が識別できていません。 App Service が Django または Flask に期待するようにアプリが構造化されていることを確認するか、 カスタム スタートアップ コマンドを使用します。

• ブラウザーに "サービスが利用できません" というメッセージが表示されます。 App Service からの応答を待機しているブラウザーがタイムアウトしました。これは、App Service が Gunicorn サーバーを起動したが、アプリ自体が起動しなかったことを示します。 この状況は、Gunicorn の引数が正しくないか、アプリのコードにエラーがあることを示しています。

  • ブラウザーを最新の情報に更新します (特に、お客様が App Service プランの最も低い価格レベルを使用している場合)。 たとえば、Free レベルを使用しているときは、アプリの起動にかかる時間が長くなることがあります。その場合、ブラウザーを最新の情報に更新すると、応答が速くなります。

  • App Service が Django または Flask に期待するようにアプリが構造化されていることを確認するか、 カスタム スタートアップ コマンドを使用します。

  • エラー メッセージがないか 、アプリ ログ ストリーム を調べます。 このログには、アプリ コードのエラーがすべて表示されます。

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 が 1 つ以上のモジュールを見つけられませんでした。 このエラーは、コードを使用して仮想環境をデプロイする場合によく発生します。 仮想環境は移植可能ではないため、アプリケーション コードを使用して仮想環境をデプロイしないでください。 代わりに、Oryx を使用して仮想環境を作成し、アプリ設定 SCM_DO_BUILD_DURING_DEPLOYMENT を作成し、それを 1 に設定して、Web アプリにパッケージをインストールします。 このように設定すると、App Service にデプロイするたびに、Oryx によってパッケージが強制的にインストールされます。 詳細については、 仮想環境の移植性に関するこの記事を参照してください。

データベースがロックされている

Django アプリを使用してデータベースの移行を実行しようとすると、次のように表示される場合があります。"sqlite3. OperationalError: database is locked." (sqlite3. OperationalError: データベースロックされています。)このエラーは、お使いのアプリケーションで、Azure Database for PostgreSQL などのクラウド データベースを使用せず、SQLite データベース (既定で Django が構成されています) を使用していることを示しています。

アプリの settings.py ファイルのDATABASES変数を調べて、アプリが SQLite ではなくクラウド データベースを使用していることを確認します。

「チュートリアル: PostgreSQL を使用して Django Web アプリをデプロイする」のサンプルでこのエラーが発生した場合は、「接続設定の確認」の手順が完了していることを確認してください。

その他の問題

• 入力すると、パスワードは SSH セッションに表示されません。セキュリティ上の理由から、SSH セッションでは入力時にパスワードが非表示になります。 ただし、文字は記録中なので、通常どおりパスワードを入力し、完了したら Enter キーを押します。

• SSH セッションのコマンドは途切れているように見えます。エディターはワード ラッピング コマンドではない可能性がありますが、正しく実行する必要があります。

• 静的アセットが Django アプリに表示されない: WhiteNoise モジュールが有効になっていることを確認してください。

• "致命的な SSL 接続が必要です" というメッセージが表示されます。アプリ内からリソース (データベースなど) にアクセスするために使用するユーザー名とパスワードを確認します。

関連するコンテンツ

• チュートリアル: PostgreSQL を使用した Flask アプリ
• チュートリアル: PostgreSQL を使用した Django アプリ
• チュートリアル: PostgreSQL を使用した FastAPI アプリ
• チュートリアル: プライベート コンテナー リポジトリからデプロイする
• App Service on Linux の FAQ
• 環境変数とアプリ設定のリファレンス