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

[アーティクル]
08/29/2024

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

App Service の展開エンジンは、Git リポジトリやビルドオートメーションが有効な ZIP パッケージをデプロイする際に、自動的に仮想環境を起動し、pip install -r requirements.txt を実行します。

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

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

Azure portal: 「Azure portal で App Service アプリを構成する」の説明に従って、アプリの [設定]>[構成] ページを使用します。
Azure CLI: 2 つのオプションがあります。
- Azure Cloud Shell でコマンドを実行します。
- 最新バージョンの Azure CLI をインストールしてコマンドをローカルで実行してから、az login を使用して Azure にサインインします。

Note

App Service で Python アプリを実行できるオペレーティングシステムは Linux だけです。 Windows 上の Python はサポートされなくなりました。ただし、独自のカスタム Windows コンテナーイメージをビルドして、App Service でそれを実行できます。詳細については、カスタム Docker イメージの使用に関するページを参照してください。

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 イメージの使用に関するページを参照してください。

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

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

この手順を PRE_BUILD_COMMAND 設定で指定した場合は、カスタムのビルド前スクリプトを実行します。このスクリプトはそれ自体で、他の Python スクリプトや Node.js スクリプト、pip コマンド、npm コマンド、さらに、yarn など Node ベースのツール (例: yarn install、yarn build) を実行できます。
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 が実行されていません。)
(Django アプリを示す) リポジトリのルートに manage.py がある場合は、manage.py collectstatic を実行します。ただし、DISABLE_COLLECTSTATIC 設定が true の場合、この設定はスキップされます。
この手順を 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 アプリの検出とビルドに関するページを参照してください。

Note

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 になります。

Note

すべてのビルド前後のスクリプトで常に相対パスを使用してください。Oryx が動作するビルドコンテナーは、アプリが動作するランタイムコンテナーとは異なるためです。コンテナー内のアプリプロジェクトフォルダーの正確な配置場所 (たとえば、site/wwwroot といった配置場所) は指定しないようにします。

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

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

ソースリポジトリ: ソースコードを GitHub などの適切なリポジトリに保持します。これにより、このプロセスの後半で継続的なデプロイを設定することができます。
- App Service が必要なパッケージを自動的にインストールできるようにするには、requirements.txt ファイルがリポジトリのルートにある必要があります。
データベース: アプリがデータベースに依存している場合は、Azure 上にも必要なリソースを作成します。
App service リソース: 対象のアプリケーションをホストするためのリソースグループ、App Service プラン、App Service Web アプリを作成します。この処理を簡単に行うには、Azure CLI コマンド az webapp up を実行します。または、PostgreSQL を使用した Python (Django または Flask) Web アプリのデプロイのチュートリアルに関する記事で示されているように、リソースを作成してデプロイすることもできます。リソースグループ、App Service プラン、Web アプリの名前を、対象のアプリケーションにより適した名前に置き換えます。
環境変数:対象のアプリケーションが環境変数を必要とする場合は、同等の App Service アプリケーション設定を作成します。これらの App Service 設定は、環境変数へのアクセスに関するセクションで説明されているように、環境変数としてコードに示されます。
- たとえば、データベース接続は、多くの場合、このような設定によって管理されます。チュートリアル: PostgreSQL を使用した Django Web アプリのデプロイ - 接続設定の確認に関する記事を参照してください。
- 一般的な Django アプリの特定の設定については、「Django アプリの運用設定」を参照してください。
アプリのスタートアップ: この記事の後半の「コンテナーのスタートアッププロセス」セクションを確認して、App Service がアプリを実行する方法を理解します。 App Service では、既定で Gunicorn Web サーバーを使用します。このサーバーは、対象のアプリオブジェクトまたは wsgi.py フォルダーを見つけることができる必要があります。必要に応じて、スタートアップコマンドをカスタマイズすることができます。
継続的デプロイ: 記事「Azure App Service への継続的デプロイ」で説明されているように、GitHub Actions、Bitbucket、または Azure Repos からの継続的デプロイを設定します。または、記事「Azure App Service へのローカル Git デプロイ」で説明されているように、ローカル Git からの継続的デプロイを設定します。
カスタムアクション: 対象のアプリをホストする App Service コンテナー内で Django データベースの移行などのアクションを実行するには、SSH 経由でコンテナーに接続します。 Django データベースの移行を実行する例については、チュートリアル: PostgreSQL を使った Django Web アプリのデプロイ - データベーススキーマの生成に関する記事を参照してください。
- 継続的デプロイを使用している場合は、前の「ビルドの自動化のカスタマイズ」で説明したように、ビルド後コマンドを使用してこれらのアクションを実行できます。

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

Django アプリの運用設定

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

次の表では、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 が含まれている必要があります。この URL は、`os.environ['WEBSITE_HOSTNAME']` というコードを使用して実行時に取得できます。 App Service によって、`WEBSITE_HOSTNAME` 環境変数がアプリの URL に自動的に設定されます。
`DATABASES`	データベースに接続するための App Service の設定を定義し、それらを環境変数として読み込んで `DATABASES` ディクショナリを設定します。または、値 (特にユーザー名とパスワード) を Azure Key Vault シークレットとして格納することもできます。

Django アプリの静的ファイルを応答として返す

Django Web アプリに静的なフロントエンドファイルが含まれる場合はまず、Django ドキュメントの「静的ファイルの管理」に記載の手順に従います。

次に、App Service に対して次の変更を行います。

環境変数 (ローカル開発の場合) およびアプリ設定 (クラウドにデプロイする場合) を使用して、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 の collectstatic プロセスで検出されるように、そのフォルダーを Django の STATICFILES_DIRS 変数に追加してください。たとえば、フロントエンドフォルダーで yarn build を実行し、静的ファイルを含んだ build/static フォルダーが yarn によって生成される場合、次のようにしてそのフォルダーを追加します。
```
FRONTEND_DIR = "path-to-frontend-folder" 
STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]    
```
ここでは、FRONTEND_DIR を使用して、yarn などのビルドツールが実行される場所のパスを構築しています。ここでも、必要に応じて環境変数とアプリ設定を使用できます。
requirements.txt ファイルに whitenoise を追加します。 WhiteNoise (whitenoise.evans.io) は、運用環境の Django アプリから応答として静的ファイルを返すための作業を省力化する Python パッケージです。具体的に言うと、Django の STATIC_ROOT 変数で指定されたフォルダーに見つかったファイルを WhiteNoise が応答として返します。

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

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 アプリは App Service にデプロイされると、App Service Python GitHub リポジトリで定義された Linux Docker コンテナー内で動作します。イメージの構成は、バージョン固有のディレクトリ内で見つけることができます。

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

アプリは、Gunicorn WSGI HTTP サーバーを使用して実行されます。このとき、追加の引数 --bind=0.0.0.0 --timeout 600 が使用されます。
- スタートアップコマンドをカスタマイズすることによって、Gunicorn の構成設定を提供できます。
- 「Gunicorn のデプロイ」で説明されているように、偶発的または意図的な DDOS 攻撃から Web アプリを防御するために、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 (msdocs-hello-world.azurewebsites.net など) を使用して、WEBSITE_HOSTNAME という名前の環境変数が自動的に定義されます。また、アプリの名前 (msdocs-hello-world など) を使用して WEBSITE_SITE_NAME も定義されます。
Node ベースのビルドツール (yarn など) を実行できるよう、コンテナーには npm と Node.js がインストールされます。

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

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

カスタムスタートアップコマンドが用意されている場合は、それを使用します。
Django アプリの存在を確認し、検出された場合はそれに対して Gunicorn を起動します。
Flask アプリの存在を確認し、検出された場合はそれに対して Gunicorn を起動します。
他のアプリが見つからない場合は、コンテナーに組み込まれている既定のアプリを起動します。

次のセクションでは、各オプションについてさらに詳しく説明します。

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 引数を追加してください。たとえば、自分のプロジェクトのルートを基準として knboard/backend/config に wsgi.py が配置されている場合は、引数 --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 に他の引数を指定する場合は、カスタムのスタートアップコマンドを使用します。

既定の動作

カスタムコマンド、Django アプリ、または Flask アプリが App Service によって検出されない場合は、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 containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
```
詳細については、「Running Gunicor」(Gunicorn の実行) を参照してください。自動スケーリングルールを使って Web アプリをスケールアップまたはスケールダウンする場合は、スタートアップコマンドで NUM_CORES 環境変数を使って、Gunicorn ワーカーの数を動的に設定する必要もあります (例: --workers $((($NUM_CORES*2)+1)))。 Gunicorn ワーカーの推奨される数の設定について詳しくは、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 ログストリームに表示されます。

詳細については、「Gunicorn logging」(Gunicorn のログ) を参照してください。
カスタムの Flask メインモジュール: App Service は、既定では、Flask アプリのメインモジュールは application.py または app.py であると想定します。メインモジュールに別の名前を使用する場合は、スタートアップコマンドをカスタマイズする必要があります。たとえば、メインモジュールが hello.py で、そのファイルにおける Flask アプリオブジェクトの名前が myapp である Flask アプリがある場合、コマンドは次のようになります。
```
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 終了がネットワークロードバランサーで発生するため、すべての 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+C キーを押します。

ブラウザーから https://<app-name>.scm.azurewebsites.net/api/logs/docker でログファイルを検査することもできます。

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

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

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

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

Web アプリの Azure portal で、左側のメニューから [デプロイ]>[デプロイセンター] を選びます。
[ログ] タブで、最新のコミットの [コミット ID] を選択します。
表示された [ログの詳細] ページで、"Running oryx build... (oryx のビルドを実行しています...)" の横に表示される [ログの表示] リンクを選択します。

これらのログには、requirements.txt 内の不適切な依存関係、ビルド前またはビルド後のスクリプトのエラーなど、ビルドの問題が出力されます。要件ファイルが requirements.txt という名前ではない場合やプロジェクトのルートフォルダーに存在しない場合も、エラーが出力されます。

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

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

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。

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

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

SSH 接続

Note

/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。

ローカルコンピューターからリモート 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 診断を使用することです。

Azure portal で、Web アプリの左側のメニューから [問題の診断と解決] を選びます。
[Availability and Performance](可用性とパフォーマンス) を選択します。
最も一般的な問題が表示される、[アプリケーションログ]、[Container crash] (コンテナーのクラッシュ)、[Container Issues] (コンテナーの問題) の各オプションの情報を調べます。

次に、デプロイログとアプリログの両方で、エラーメッセージが出力されていないかを調べます。アプリのデプロイや起動を妨げる特定の問題が、これらのログによって明らかになることが少なくありません。たとえば、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 が識別できていません。 Django または Flask に関して App Service で想定されているとおりにお客様のアプリが構造化されていることをチェックします。または、カスタムスタートアップコマンドを使用します。
ブラウザーでメッセージ "サービス利用不可" が表示されます。 ブラウザーでは App Service からの応答を待ってタイムアウトしました。これは、App Service によって Gunicorn サーバーが起動されたものの、アプリ自体が起動しなかったことを示しています。この状況は、Gunicorn の引数が正しくないか、アプリのコードにエラーがあることを示しています。
- ブラウザーを最新の情報に更新します (特に、お客様が App Service プランの最も低い価格レベルを使用している場合)。たとえば、Free レベルを使用しているときは、アプリの起動にかかる時間が長くなることがあります。その場合、ブラウザーを最新の情報に更新すると、応答が速くなります。
- Django または Flask に関して App Service で想定されているとおりにお客様のアプリが構造化されていることをチェックします。または、カスタムスタートアップコマンドを使用します。
- アプリログストリームにエラーメッセージがないか調べます。このログには、アプリコードのエラーがすべて表示されます。

setup.py または requirements.txt が見つからない

ログストリームに "Could not find setup.py or requirements.txt; Not running pip install." (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: database is locked." (sqlite3. OperationalError: データベースロックされています。)このエラーは、お使いのアプリケーションで、Azure Database for PostgreSQL などのクラウドデータベースを使用せず、SQLite データベース (既定で Django が構成されています) を使用していることを示しています。

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

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

その他の問題

SSH セッションで、入力したパスワードが表示されない: SSH セッションでは、セキュリティ上の理由により、入力中のパスワードは非表示になります。ただし、文字は記録されているので、通常どおりにパスワードを入力し、完了したら Enter キーを押してください。
SSH セッションで、コマンドが途切れたように表示される: エディターでコマンドのテキストが折り返されないことがありますが、その場合でも正しく実行されます。
Django アプリに静的資産が表示されない: WhiteNoise モジュールを有効にしていることを確認します。
"Fatal SSL Connection is Required (致命的: SSL 接続が必要です)" というメッセージが表示される: アプリ内からリソース (データベースなど) へのアクセスに使用したユーザー名とパスワードを確認してください。

次の方法で共有

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

Python バージョンの構成

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

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

Django アプリの運用設定

Django アプリの静的ファイルを応答として返す

Flask アプリの静的ファイルを提供する

コンテナーの特性

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

Django アプリ

Flask アプリ

既定の動作

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

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

環境変数としてのアプリ設定へのアクセス

HTTPS セッションを検出する

診断ログにアクセスする

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

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

URL の書き換え

トラブルシューティング

アプリが表示されない

setup.py または requirements.txt が見つからない

アプリ起動時の ModuleNotFoundError

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

その他の問題

フィードバック

その他のリソース

次の方法で共有

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

Python バージョンの構成

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

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

Django アプリの運用設定

Django アプリの静的ファイルを応答として返す

Flask アプリの静的ファイルを提供する

コンテナーの特性

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

Django アプリ

Flask アプリ

既定の動作

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

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

環境変数としてのアプリ設定へのアクセス

HTTPS セッションを検出する

診断ログにアクセスする

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

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

URL の書き換え

トラブルシューティング

アプリが表示されない

setup.py または requirements.txt が見つからない

アプリ起動時の ModuleNotFoundError

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

その他の問題

関連するコンテンツ

フィードバック

その他のリソース

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

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

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

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