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

この記事では、Azure App Service で Python アプリが実行される方法と、必要に応じて App Service の動作をカスタマイズする方法について説明します。This article describes how Azure App Service runs Python apps, and how you can customize the behavior of App Service when needed. Python アプリは、必要なすべての pip モジュールと共にデプロイする必要があります。Python apps must be deployed with all the required pip modules.

App Service デプロイ エンジンは、自動的に仮想環境をアクティブ化し、Git リポジトリをデプロイするとき、またはビルド プロセスがオンになっている Zip パッケージをデプロイするときに、pip install -r requirements.txt を実行します。The App Service deployment engine automatically activates a virtual environment and runs pip install -r requirements.txt for you when you deploy a Git repository, or a Zip package with build processes switched on.

このガイドでは、App Service の組み込み Linux コンテナーを使用する Python 開発者のために、主要な概念と手順を示します。This guide provides key concepts and instructions for Python developers who use a built-in Linux container in App Service. Azure App Service を使用したことがない場合は、まず Python クイック スタートPostgreSQL を使った Python のチュートリアルに従ってください。If you've never used Azure App Service, you should follow the Python quickstart and Python with PostgreSQL tutorial first.

注意

Linux は現在、App Service で Python アプリを実行するための推奨されるオプションです。Linux is currently the recommended option for running Python apps in App Service. Windows オプションについては、Windows フレーバーの App Service での Python に関するページを参照してください。For information on the Windows option, see Python on the Windows flavor of App Service.

Python バージョンの表示Show Python version

現在の Python バージョンを表示するには、Cloud Shell で次のコマンドを実行します。To show the current Python version, run the following command in the Cloud Shell:

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

サポートされているすべての Python バージョンを表示するには、Cloud Shell で次のコマンドを実行します。To show all supported Python versions, run the following command in the Cloud Shell:

az webapp list-runtimes --linux | grep PYTHON

サポートされない Python バージョンを実行するには、代わりに独自のコンテナー イメージを作成します。You can run an unsupported version of Python by building your own container image instead. 詳細については、カスタム Docker イメージの使用に関するページを参照してください。For more information, see use a custom Docker image.

Python バージョンの設定Set Python version

Python バージョンを 3.7 に設定するには、Cloud Shell で次のコマンドを実行します。Run the following command in the Cloud Shell to set the Python version to 3.7:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.7"

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

ビルドの自動化を有効にして Git または zip パッケージを使用してアプリをデプロイする場合、App Service のビルドの自動化によって、次の手順が実行されます。If you deploy your app using Git or zip packages with build automation turned on, the App Service build automation steps through the following sequence:

  1. PRE_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。Run custom script if specified by PRE_BUILD_SCRIPT_PATH.
  2. pip install -r requirements.txt を実行します。Run pip install -r requirements.txt.
  3. リポジトリのルートに manage.py がある場合、manage.py collectstatic を実行します。If manage.py is found in the root of the repository, run manage.py collectstatic. ただし、DISABLE_COLLECTSTATICtrue に設定されている場合、この手順はスキップされます。However, if DISABLE_COLLECTSTATIC is set to true, this step is skipped.
  4. POST_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。Run custom script if specified by POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMANDPOST_BUILD_COMMANDDISABLE_COLLECTSTATIC は、既定では空の環境変数です。PRE_BUILD_COMMAND, POST_BUILD_COMMAND, and DISABLE_COLLECTSTATIC are environment variables that are empty by default. ビルド前のコマンドを実行するには、PRE_BUILD_COMMAND を定義します。To run pre-build commands, define PRE_BUILD_COMMAND. ビルド後のコマンドを実行するには、POST_BUILD_COMMAND を定義します。To run post-build commands, define POST_BUILD_COMMAND. Django アプリをビルドするときに collectstatic の実行を無効にするには、DISABLE_COLLECTSTATIC=true を設定します。To disable running collectstatic when building Django apps, set DISABLE_COLLECTSTATIC=true.

次の例では、一連のコマンドに対して 2 つの変数をコンマ区切りで指定しています。The following example specifies the two variables to a series of commands, separated by commas.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

ビルドの自動化をカスタマイズするためのその他の環境変数については、「Oryx の構成」を参照してください。For additional environment variables to customize build automation, see Oryx configuration.

Linux 上で App Service によって Python アプリが実行されビルドされる方法に関する詳細については、Oryx ドキュメントの Python アプリが検出されビルドされる方法に関するページを参照してください。For more information on how App Service runs and builds Python apps in Linux, see Oryx documentation: How Python apps are detected and built.

コンテナーの特性Container characteristics

App Service on Linux にデプロイされた Python アプリは、App Service Python GitHub リポジトリで定義されている Docker コンテナー内で実行されます。Python apps deployed to App Service on Linux run within a Docker container that's defined in the App Service Python GitHub repository. イメージの構成は、バージョン固有のディレクトリ内で見つけることができます。You can find the image configurations inside the version-specific directories.

このコンテナーには次の特性があります。This container has the following characteristics:

  • アプリは、Gunicorn WSGI HTTP サーバーを使用して実行されます。このとき、追加の引数 --bind=0.0.0.0 --timeout 600 が使用されます。Apps are run using the Gunicorn WSGI HTTP Server, using the additional arguments --bind=0.0.0.0 --timeout 600.

  • 既定では、基本のイメージに Flask Web フレームワークが含まれています。ただし、コンテナーは、WSGI に準拠していて Python 3.7 と互換性のある他のフレームワーク (Django など) をサポートしています。By default, the base image includes the Flask web framework, but the container supports other frameworks that are WSGI-compliant and compatible with Python 3.7, such as Django.

  • Django など、追加のパッケージをインストールするには、pip freeze > requirements.txt を使用して、お客様のプロジェクトのルートに requirements.txt ファイルを作成します。To install additional packages, such as Django, create a requirements.txt file in the root of your project using pip freeze > requirements.txt. 次に、Git デプロイを使用してお客様のプロジェクトを App Service に公開します。これにより、コンテナー内で pip install -r requirements.txt が自動的に実行され、お客様のアプリの依存関係がインストールされます。Then, publish your project to App Service using Git deployment, which automatically runs pip install -r requirements.txt in the container to install your app's dependencies.

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

App Service on Linux コンテナーでは、起動中に次の手順が実行されます。During startup, the App Service on Linux container runs the following steps:

  1. カスタム スタートアップ コマンドが提供されている場合は、これを使用します。Use a custom startup command, if provided.
  2. Django アプリの存在を確認し、検出された場合はそれための Gunicorn を起動します。Check for the existence of a Django app, and launch Gunicorn for it if detected.
  3. Flask アプリの存在を確認し、検出された場合はそれための Gunicorn を起動します。Check for the existence of a Flask app, and launch Gunicorn for it if detected.
  4. 他のアプリが見つからない場合は、コンテナーに組み込まれている既定のアプリを起動します。If no other app is found, start a default app that's built into the container.

次のセクションでは、各オプションについてさらに詳しく説明します。The following sections provide additional details for each option.

Django アプリDjango app

Django アプリの場合、App Service によってお客様のアプリ コード内で wsgi.py という名前のファイルが検索され、次のコマンドを使用して Gunicorn が実行されます。For Django apps, App Service looks for a file named wsgi.py within your app code, and then runs Gunicorn using the following command:

# <module> is the path to the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

スタートアップ コマンドをより細かく制御したい場合は、カスタム スタートアップ コマンドを使用し、<module> を、wsgi.py が含まれているモジュールの名前に置き換えます。If you want more specific control over the startup command, use a custom startup command and replace <module> with the name of the module that contains wsgi.py.

Flask アプリFlask app

Flask の場合、App Service によって application.py または app.py という名前のファイルが検索され、Gunicorn が次のように起動されます。For Flask, App Service looks for a file named application.py or app.py and starts Gunicorn as follows:

# 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 に追加の引数を指定したい場合は、カスタム スタートアップ コマンドを使用します。If your main app module is contained in a different file, use a different name for the app object, or you want to provide additional arguments to Gunicorn, use a custom startup command.

既定の動作Default behavior

カスタム コマンド、Django アプリ、または Flask アプリが App Service によって検出されない場合は、opt/defaultsite フォルダーにある既定の読み取り専用アプリが実行されます。If the App Service doesn't find a custom command, a Django app, or a Flask app, then it runs a default read-only app, located in the opt/defaultsite folder. 既定のアプリは次のように表示されます。The default app appears as follows:

App Service on Linux の既定の Web ページ

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

カスタム Gunicorn スタートアップ コマンドを指定することで、コンテナーの起動動作を制御できます。You can control the container's startup behavior by providing a custom Gunicorn startup command. これを行うには、Cloud Shell で次のコマンドを実行します。To do this, running the following command in the Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

たとえば、メイン モジュールが hello.py で、そのファイルにおける Flask アプリ オブジェクトの名前が myapp である Flask アプリがある場合、 <custom-command> は次のようになります。For example, if you have a Flask app whose main module is hello.py and the Flask app object in that file is named myapp, then <custom-command> is as follows:

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

メイン モジュールがサブフォルダー (website など) に存在する場合、そのフォルダーを --chdir 引数で指定します。If your main module is in a subfolder, such as website, specify that folder with the --chdir argument:

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

また、--workers=4 のように、Gunicorn の追加の引数を <custom-command> に追加することもできます。You can also add any additional arguments for Gunicorn to <custom-command>, such as --workers=4. 詳細については、「Running Gunicorn (Gunicorn の実行)」 (docs.gunicorn.org) を参照してください。For more information, see Running Gunicorn (docs.gunicorn.org).

aiohttp のような Gunicorn 以外のサーバーを使用するには、 <custom-command> を次のように置き換えることができます。To use a non-Gunicorn server, such as aiohttp, you can replace <custom-command> with something like this:

python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func

注意

App Service では、カスタム コマンド ファイルの処理中に発生したエラーが無視されて、Django アプリおよび Flask アプリが検索されることでスタートアップ プロセスが続行されます。App Service ignores any errors that occur when processing a custom command file, then continues its startup process by looking for Django and Flask apps. 意図した動作が得られない場合は、お客様のスタートアップ ファイルが App Service にデプロイされていること、およびそのファイルにエラーが含まれていないことを確認してください。If you don't see the behavior you expect, check that your startup file is deployed to App Service and that it doesn't contain any errors.

環境変数へのアクセスAccess environment variables

App Service では、アプリ コードの外部でアプリ設定を指定できます。In App Service, you can set app settings outside of your app code. その後、標準の os.environ パターンを使用して、それらにアクセスできます。Then you can access them using the standard os.environ pattern. たとえば、WEBSITE_SITE_NAME というアプリ設定にアクセスするには、次のコードを使用します。For example, to access an app setting called WEBSITE_SITE_NAME, use the following code:

os.environ['WEBSITE_SITE_NAME']

HTTPS セッションの検出Detect HTTPS session

App Service では、SSL 終了がネットワーク ロード バランサーで発生するため、すべての HTTPS リクエストは暗号化されていない HTTP リクエストとしてアプリに到達します。In App Service, SSL termination happens at the network load balancers, so all HTTPS requests reach your app as unencrypted HTTP requests. ユーザー要求が暗号化されているかどうかをアプリ ロジックが確認する必要がある場合は、X-Forwarded-Proto ヘッダーを調べます。If your app logic needs to check if the user requests are encrypted or not, inspect the X-Forwarded-Proto header.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

一般的な Web フレームワークでは、標準のアプリ パターンで X-Forwarded-* 情報にアクセスできます。Popular web frameworks let you access the X-Forwarded-* information in your standard app pattern. CodeIgniter では、is_https () は既定で X_FORWARDED_PROTO の値をチェックします。In CodeIgniter, the is_https() checks the value of X_FORWARDED_PROTO by default.

診断ログにアクセスするAccess diagnostic logs

コンテナー内から生成されたコンソール ログにアクセスできます。You can access the console logs generated from inside the container. まず、Cloud Shell で次のコマンドを実行して、コンテナーのログ記録をオンにします。First, turn on container logging by running the following command in the Cloud Shell:

az webapp log config --name <app-name> --resource-group myResourceGroup --docker-container-logging filesystem

コンテナーのログ記録がオンになったら、次のコマンドを実行して、ログのストリームを確認します。Once container logging is turned on, run the following command to see the log stream:

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

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。If you don't see console logs immediately, check again in 30 seconds.

注意

https://<app-name>.scm.azurewebsites.net/api/logs/docker で、ブラウザーからログ ファイルを検査することもできます。You can also inspect the log files from the browser at https://<app-name>.scm.azurewebsites.net/api/logs/docker.

任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。To stop log streaming at any time, type Ctrl+C.

ブラウザーで SSH セッションを開くOpen SSH session in browser

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。To make open a direct SSH session with your container, your app should be running.

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。Paste the following URL into your browser and replace <app-name> with your app name:

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

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。If you're not yet authenticated, you're required to authenticate with your Azure subscription to connect. 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。Once authenticated, you see an in-browser shell, where you can run commands inside your container.

SSH 接続

注意

/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。Any changes you make outside the /home directory are stored in the container itself and don't persist beyond an app restart.

ローカル コンピューターからリモート SSH セッションを開くには、「リモート シェルから SSH セッションを開く」を参照してください。To open a remote SSH session from your local machine, see Open SSH session from remote shell.

トラブルシューティングTroubleshooting

  • 自分のアプリ コードをデプロイした後に既定のアプリが表示される。You see the default app after deploying your own app code. 既定のアプリは、アプリ コードが App Service にデプロイされていない場合、またはアプリ コードが App Service によって検出されず、代わりに既定のアプリが実行された場合に表示されます。The default app appears because you either haven't deployed your app code to App Service, or App Service failed to find your app code and ran the default app instead.
  • App Service を再起動し、15 から 20 秒待って、アプリをもう一度確認します。Restart the App Service, wait 15-20 seconds, and check the app again.
  • Windows ベースのインスタンスではなく、App Service for Linux が使用されていることを確認してください。Be sure you're using App Service for Linux rather than a Windows-based instance. Azure CLI から az webapp show --resource-group <resource_group_name> --name <app_service_name> --query kind コマンドを実行します。<resource_group_name><app_service_name> は適宜置き換えてください。From the Azure CLI, run the command az webapp show --resource-group <resource_group_name> --name <app_service_name> --query kind, replacing <resource_group_name> and <app_service_name> accordingly. 出力として app,linux が表示されるはずです。それ以外の場合は、App Service を再作成し、Linux を選択してください。You should see app,linux as output; otherwise, recreate the App Service and choose Linux.
  • SSH または Kudu コンソールを使用して App Service に直接接続し、お客様のファイルが site/wwwroot に存在することを確認します。Use SSH or the Kudu console to connect directly to the App Service and verify that your files exist under site/wwwroot. ファイルが存在しない場合は、デプロイ プロセスを見直してアプリを再デプロイします。If your files don't exist, review your deployment process and redeploy the app.
  • ファイルが存在する場合は、お客様固有のスタートアップ ファイルを App Service が識別できていません。If your files exist, then App Service wasn't able to identify your specific startup file. Django または Flask に関して App Service で想定されているとおりにお客様のアプリが構造化されていることをチェックします。または、カスタム スタートアップ コマンドを使用します。Check that your app is structured as App Service expects for Django or Flask, or use a custom startup command.
  • ブラウザーに "サービスは利用できません" というメッセージが表示される。You see the message "Service Unavailable" in the browser. ブラウザーは App Service からの応答を待ってタイムアウトしました。これは、App Service によって Gunicorn サーバーが起動されたもののアプリ コードを指定する引数が正しくないことを示しています。The browser has timed out waiting for a response from App Service, which indicates that App Service started the Gunicorn server, but the arguments that specify the app code are incorrect.
  • ブラウザーを最新の情報に更新します (特に、お客様が App Service プランの最も低い価格レベルを使用している場合)。Refresh the browser, especially if you're using the lowest pricing tiers in your App Service Plan. たとえば、無料のレベルを使用しているときは、アプリの起動にかかる時間が長くなることがあります。その場合、ブラウザーを最新の情報に更新すると、応答が速くなります。The app may take longer to start up when using free tiers, for example, and becomes responsive after you refresh the browser.
  • Django または Flask に関して App Service で想定されているとおりにお客様のアプリが構造化されていることをチェックします。または、カスタム スタートアップ コマンドを使用します。Check that your app is structured as App Service expects for Django or Flask, or use a custom startup command.
  • ログ ストリームにアクセスします。Access the log stream.

次のステップNext steps