この記事では、Azure App Service でホストされている Python Web アプリのカスタム スタートアップ ファイルを構成するタイミングと方法について説明します。 ローカル開発にはスタートアップ ファイルは必要ありませんが、Azure App Service は、デプロイされた Web アプリを Docker コンテナー内で実行します。このコンテナーでは、スタートアップ コマンドを使用できます (指定されている場合)。
次の状況では、カスタム スタートアップ ファイルが必要です。
カスタム Gunicorn 引数: Gunicorn の既定の Web サーバーを、既定値を超える追加の引数 (
--bind=0.0.0.0 --timeout 600
) で起動する必要があります。代替フレームワークまたはサーバー: アプリは Flask または Django 以外のフレームワークで構築されているか、Gunicorn 以外の別の Web サーバーを使用する必要があります。
標準以外の Flask アプリケーション構造: メイン コード ファイルに app.py または application.py* 以外の名前が付けられている Flask アプリがある場合、またはアプリ オブジェクトに
app
の名前が付けられています。
つまり、プロジェクトのルート フォルダーに という名前の Flask アプリ オブジェクトを含む app.py または app
ファイルがない限り、カスタム スタートアップ コマンドが必要です。
詳細については、「 Python アプリの構成 - コンテナーの起動プロセス」を参照してください。
スタートアップ ファイルを作成する
カスタム スタートアップ ファイルが必要な場合は、次の手順に従います。
startup.txt、startup.sh、またはスタートアップ コマンドを含む別の名前のファイルをプロジェクトに作成します。 Django、Flask、およびその他のフレームワークの詳細については、この記事の後のセクションを参照してください。
スタートアップ ファイルには、必要に応じて複数のコマンドを含めることができます。
ファイルをコード リポジトリにコミットして、アプリの残りの部分と共にデプロイできるようにします。
Visual Studio Code で、アクティビティ バーの Azure アイコンを選択し、[ リソース] を展開し、サブスクリプションを検索して展開し、[ App Services] を展開して、App Service を右クリックして、[ ポータルで開く] を選択します。
Azure portal の App Service の [構成] ページで、[全般設定] を選択し、[スタック設定] の下にスタートアップ ファイルの名前 (startup.txt や startup.sh など) を入力します>[スタートアップ コマンド]、[保存] の順に選択します。
注
スタートアップ コマンド ファイルを使用する代わりに、スタートアップ コマンド自体を Azure portal の [スタートアップ コマンド] フィールドに直接配置できます。 構成はリポジトリに格納されるため、スタートアップ コマンド ファイルを使用することをお勧めします。 これにより、バージョン管理で変更を追跡でき、他の Azure App Service インスタンスへの再デプロイが簡略化されます。
App Service の再起動を求められたら、[ 続行] を選択します。
アプリケーション コードをデプロイする前に Azure App Service サイトにアクセスすると、要求を処理できるコードがないため、"アプリケーション エラー" が表示されます。
Django スタートアップ コマンド
既定では、Azure App Service は、wsgi.py ファイルを含むフォルダーを検索し、次のコマンドを使用して Gunicorn を起動します。
# <module> is the folder that contains wsgi.py. If you need to use a subfolder,
# specify the parent of <module> using --chdir.
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi
タイムアウト値を 1,200 秒 (--timeout 1200
) に増やすなど、Gunicorn 引数を変更する場合は、カスタム スタートアップ コマンド ファイルを作成します。 これにより、既定の設定を特定の要件でオーバーライドできます。 詳細については、「 コンテナーの起動プロセス - Django アプリ」を参照してください。
Flask のスタートアップ コマンド
既定では、App Service on Linux では、Flask アプリケーションが次の critear を満たしていることを前提としています。
- WSGI 呼び出し可能オブジェクトには、
app
という名前が付けられています。 - アプリケーション コードは、 application.py または app.py という名前のファイルに含 まれています。
- アプリケーション ファイルは、アプリのルート フォルダーにあります。
プロジェクトがこの構造と異なる場合、カスタム スタートアップ コマンドは、フォーマット ファイルでアプリ オブジェクトの場所を識別する必要があります :app_object。
別のファイル名またはアプリ オブジェクト名: アプリのメイン コード ファイルが hello.py され、アプリ オブジェクトの名前が
myapp
の場合、スタートアップ コマンドは次のようになります。gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp
スタートアップ ファイルはサブフォルダーにあります。スタートアップ ファイルが myapp/website.py で、アプリ オブジェクトが
app
されている場合は、Gunicorn の--chdir
引数を使用してフォルダーを指定し、スタートアップ ファイルとアプリ オブジェクトに通常どおり名前を付けます。gunicorn --bind=0.0.0.0 --timeout 600 --chdir myapp website:app
スタートアップ ファイルはモジュール内にあります。 python-sample-vscode-flask-tutorial コードでは、 webapp.py スタートアップ ファイルは 、__init__.pyファイルを 含むモジュールであるhello_appフォルダー内に含まれています。 アプリ オブジェクトは
app
という名前で、 __init__.py で 定義され、 webapp.py は相対インポートを使用します。この配置のため、Gunicorn を
webapp:app
ポイントすると、"パッケージ以外で相対インポートを試行しました" というエラーが発生し、アプリの起動に失敗します。このような場合は、モジュールからアプリ オブジェクトをインポートする shim ファイルを作成し、shim を使用して Gunicorn にアプリを起動させます。 たとえば 、python-sample-vscode-flask-tutorial コードには、次の内容の startup.py が含まれています。
from hello_app.webapp import app
その後、スタートアップ コマンドは次のようになります。
gunicorn --bind=0.0.0.0 --workers=4 startup:app
詳細については、「 コンテナーの起動プロセス - Flask アプリ」を参照してください。
その他のフレームワークと Web サーバー
Python アプリを実行する App Service コンテナーには、Gunicorn Web サーバーと共に Django と Flask が既定でインストールされています。
Django や Flask 以外のフレームワーク ( Falcon、 FastAPI など) を使用する場合、または別の Web サーバーを使用する場合:
requirements.txt ファイルにフレームワークや Web サーバーを含めます。
スタートアップ コマンドで、Flask について説明した前のセクションに従って、WSGI 呼び出し可能オブジェクトを特定します。
Gunicorn 以外の Web サーバーを起動するには、サーバーを直接呼び出す代わりに
python -m
コマンドを使用します。 たとえば、次のコマンドは、WSGI 呼び出し可能な名前が で、application.py にあると仮定してapp
サーバーを起動します。python -m uvicorn application:app --host 0.0.0.0
requirements.txt
python -m
インストールされた Web サーバーは Python グローバル環境に追加されないため、直接呼び出すことができないため、を使用します。python -m
コマンドは、現在の仮想環境内からサーバーを呼び出します。