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

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

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

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

構成には 、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 を使用して、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 ファイルは、プロジェクトのルート フォルダーに存在する必要があります。 ない場合、ビルド プロセスによってエラー "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 に設定します。

• ビルド前コマンドを実行するには、コマンド (echo Pre-build command など)、または自分のプロジェクトのルートからスクリプト ファイルへの相対パス (scripts/prebuild.sh) が含まれるように PRE_BUILD_COMMAND の設定を行います。 すべてのコマンドでは、プロジェクトのルート フォルダーを基準とした相対パスを使用する必要があります。

• ビルド後コマンドを実行するには、コマンド (echo Post-build command など)、または自分のプロジェクトのルートからスクリプト ファイルへの相対パス (scripts/postbuild.sh) が含まれるように POST_BUILD_COMMAND の設定を行います。 すべてのコマンドでは、プロジェクトのルート フォルダーを基準とした相対パスを使用する必要があります。

ビルドの自動化をカスタマイズするその他の設定については、「Oryx の構成」を参照してください。

ビルド ログとデプロイ ログへのアクセスの詳細については、「デプロイ ログへのアクセス」を参照してください。

App Service が Linux で Python アプリを実行およびビルドする方法の詳細については、「 Oryx が Python アプリを検出してビルドする方法」を参照してください。

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

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

詩の使用

エクスポート プラグインで Poetry を使用して requirements.txt を生成します。

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

uv の使用

uv を使用して requirements.txt を生成します。

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

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

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

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

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

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

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

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

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

5. アプリの起動。 App Service がアプリの実行をどのように試行するかについては、この記事で後述する「コンテナーのスタートアップ プロセス」セクションをご覧ください。 App Service では、既定で Gunicorn Web サーバーが使用されます。 Gunicorn がアプリ オブジェクトまたは wsgi.py フォルダーを見つけられる必要があります。 必要に応じて、 スタートアップ コマンドをカスタマイズできます。

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

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

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

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

Django アプリの運用設定

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 の collectstatic プロセスで検出されるように、そのフォルダーを Django の STATICFILES_DIRS 変数に追加してください。 たとえば、フロントエンド フォルダーで yarn build を実行し、Yarn が静的ファイルを含む build/static フォルダーを生成する場合は、次に示すようにそのフォルダーを含めます。

   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 アプリが独自の静的ファイルを提供しやすくします。 WhiteNoise は、Django STATIC_ROOT 変数で指定されたフォルダーにあるファイルを提供します。

4. settings.py ファイルに WhiteNoise の次の行を追加します。

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. WhiteNoise を含むように MIDDLEWARE と INSTALLED_APPS のリストを変更します。

   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 コンテナー内で実行されます。 イメージの構成は、バージョン固有のディレクトリにあります。

このコンテナーには次の特性があります。

• アプリは、追加の引数 --bind=0.0.0.0 --timeout 600 を使用して Gunicorn WSGI HTTP サーバーによって実行されます。

  • スタートアップ コマンドをカスタマイズすることで、Gunicorn の構成設定を指定できます。

  • 偶発的または意図的な DDOS 攻撃から Web アプリを保護するために、「Deploying Gunicorn」 (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 により、WEBSITE_HOSTNAME という環境変数が自動的に定義されます。これには、Web アプリの URL (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。 スタートアップ コマンドまたはファイルを設定するには、--startup-file パラメーターを指定して az webapp config set コマンドを使用します。

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

  詳細については、「 グニコーンの実行」を参照してください。 自動スケール ルールを使用して Web アプリをスケールアップまたはスケールダウンしている場合は、スタートアップ コマンドで NUM_CORES 環境変数を使用して、Gunicorn worker の数も動的に設定する必要があります。 たとえば、「 --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 のビルドを実行しています..." の横に表示される [ログの表示] リンクを選択します。

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

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

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

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

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

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

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

URL の書き換え

Python アプリケーションを 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 がアプリ コードを見つけられず、代わりに既定のアプリを実行したためです。

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

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

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

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

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

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

  • Django または Flask に関して App Service で想定されているとおりにアプリが構造化されていることを確認します。または、カスタム スタートアップ コマンドを使用します。

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

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

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

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

アプリの 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
• 環境変数とアプリ設定のリファレンス