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.

このガイドでは、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, first follow the Python quickstart and Python with PostgreSQL tutorial.

構成には Azure portal と Azure CLI のいずれかを使用できます。You can use either the Azure portal or the Azure CLI for configuration:

注意

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 バージョンの構成Configure Python version

  • Azure portal: Linux コンテナー向けに「全般設定を構成する」で説明されているとおり、 [構成] ページで [全般設定] を使用します。Azure portal: use the General settings tab on the Configuration page as described on Configure general settings for Linux containers.

  • Azure CLI:Azure CLI:

    • az webapp config show を使用して現在の Python バージョンを表示します。Show the current Python version with az webapp config show:

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

      <resource-group-name><app-name> は、Web アプリに適した名前に置き換えます。Replace <resource-group-name> and <app-name> with the names appropriate for your web app.

    • az webapp config set を使用して Python バージョンを設定しますSet the Python version with az webapp config set

      az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.7"
      
    • az webapp list-runtimes を使用して、Azure App Service でサポートされている Python バージョンをすべて表示します。Show all Python versions that are supported in Azure App Service with az webapp list-runtimes:

      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.

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

Oryx と呼ばれる App Service のビルド システムでは、Git または ZIP パッケージを使用してアプリをデプロイする際に、次のステップを実行します。App Service's build system, called Oryx, performs the following steps when you deploy your app using Git or zip packages:

  1. PRE_BUILD_COMMAND 設定を指定した場合は、カスタムのビルド前スクリプトを実行します。Run a custom pre-build script if specified by the PRE_BUILD_COMMAND setting.
  2. pip install -r requirements.txt を実行します。Run pip install -r requirements.txt. requirements.txt ファイルがプロジェクトのルート フォルダーに存在していなければなりません。The requirements.txt file must be present in the project's root folder. そうでないと、ビルド プロセスでエラーがレポートされます: "Could not find setup.py or requirements.txt; Not running pip install." (setup.py または requirements.txt が見つかりませんでした; pip install が実行されていません。)Otherwise, the build process reports the error: "Could not find setup.py or requirements.txt; Not running pip install."
  3. (Django アプリを示す) リポジトリのルートに manage.py がある場合は、manage.py collectstatic を実行します。If manage.py is found in the root of the repository (indicating a Django app), run manage.py collectstatic. ただし、DISABLE_COLLECTSTATIC 設定が true の場合、この設定はスキップされます。However, if the DISABLE_COLLECTSTATIC setting is true, this step is skipped.
  4. POST_BUILD_COMMAND 設定を指定した場合は、カスタムのビルド後スクリプトを実行します。Run custom post-build script if specified by the POST_BUILD_COMMAND setting.

既定では、PRE_BUILD_COMMANDPOST_BUILD_COMMANDDISABLE_COLLECTSTATIC の設定は空です。By default, the PRE_BUILD_COMMAND, POST_BUILD_COMMAND, and DISABLE_COLLECTSTATIC settings are empty.

  • Django アプリをビルドするときに collectstatic の実行を無効にするには、DISABLE_COLLECTSTATIC 設定を true にします。To disable running collectstatic when building Django apps, set the DISABLE_COLLECTSTATIC setting to true.

  • ビルド前コマンドを実行するには、コマンド (echo Pre-build command など)、または自分のプロジェクトのルートからスクリプト ファイルへの相対パス (scripts/prebuild.sh) が含まれるように PRE_BUILD_COMMAND の設定を行います。To run pre-build commands, set the PRE_BUILD_COMMAND setting to contain either a command, such as echo Pre-build command, or a path to a script file relative to your project root, such as scripts/prebuild.sh. どのコマンドでも、プロジェクトのルート フォルダーへの相対パスを使用する必要があります。All commands must use relative paths to the project root folder.

  • ビルド後コマンドを実行するには、コマンド (echo Post-build command など)、または自分のプロジェクトのルートからスクリプト ファイルへの相対パス (scripts/postbuild.sh) が含まれるように POST_BUILD_COMMAND の設定を行います。To run post-build commands, set the POST_BUILD_COMMAND setting to contain either a command, such as echo Post-build command, or a path to a script file relative to your project root, such as scripts/postbuild.sh. どのコマンドでも、プロジェクトのルート フォルダーへの相対パスを使用する必要があります。All commands must use relative paths to the project root folder.

ビルドの自動化をカスタマイズする設定の詳細については、「Oryx 構成」を参照してください。For additional settings that customize build automation, see Oryx configuration.

ビルドとデプロイのログにアクセスするには、「デプロイ ログにアクセスする」を参照してください。To access the build and deployment logs, see Access deployment logs.

App Service で Linux の Python アプリを実行、ビルドする方法の詳細については、Oryx による Python アプリの検出とビルドに関するページを参照してください。For more information on how App Service runs and builds Python apps in Linux, see How Oryx detects and builds Python apps.

注意

PRE_BUILD_SCRIPT_PATH および POST_BUILD_SCRIPT_PATH の設定は PRE_BUILD_COMMAND および POST_BUILD_COMMAND と同一で、従来の目的でサポートされています。The PRE_BUILD_SCRIPT_PATH and POST_BUILD_SCRIPT_PATH settings are identical to PRE_BUILD_COMMAND and POST_BUILD_COMMAND and are supported for legacy purposes.

SCM_DO_BUILD_DURING_DEPLOYMENT という名前の設定に true または 1 が含まれている場合、デプロイ中に Oryx によってビルドが行われます。A setting named SCM_DO_BUILD_DURING_DEPLOYMENT, if it contains true or 1, triggers an Oryx build happens during deployment. この設定は、Git、Azure CLI コマンド az webapp up、Visual Studio Code を使用してデプロイする場合に true になります。The setting is true when deploying using git, the Azure CLI command az webapp up, and Visual Studio Code.

注意

すべてのビルド前後のスクリプトで常に相対パスを使用してください。Oryx が動作するビルド コンテナーは、アプリが動作するランタイム コンテナーとは異なるためです。Always use relative paths in all pre- and post-build scripts because the build container in which Oryx runs is different from the runtime container in which the app runs. コンテナー内のアプリ プロジェクト フォルダーの正確な配置場所 (たとえば、site/wwwroot といった配置場所) は指定しないようにします。Never rely on the exact placement of your app project folder within the container (for example, that it's placed under site/wwwroot).

Django アプリの運用設定Production settings for Django apps

Azure App Service などの運用環境の場合、Django アプリは Django のデプロイ チェックリスト (djangoproject.com) に準拠する必要があります。For a production environment like Azure App Service, Django apps should follow Django's Deployment checklist (djangoproject.com).

次の表では、Azure に関連する運用設定について説明しています。The following table describes the production settings that are relevant to Azure. これらの設定は、アプリの setting.py ファイルで定義されます。These settings are defined in the app's setting.py file.

Django 設定Django setting Azure での手順Instructions for Azure
SECRET_KEY 環境変数としてのアプリ設定へのアクセス」の説明のとおりに、App Service 設定の値を格納します。Store the value in an App Service setting as described on Access app settings as environment variables. また、この値は "シークレット" として Azure Key Vault に格納することもできます。You can alternately store the value as a "secrete" in Azure Key Vault.
DEBUG 値を 0 (false) にして App Service で DEBUG 設定を作成してから、その値を環境変数として読み込みます。Create a DEBUG setting on App Service with the value 0 (false), then load the value as an environment variable. 実際の開発環境では、値を 1 (true) にして DEBUG 環境変数を作成してください。In your development environment, create a DEBUG environment variable with the value 1 (true).
ALLOWED_HOSTS 運用環境の Django では、settings.pyALLOWED_HOSTS 配列にアプリの URL が含まれている必要があります。In production, Django requires that you include app's URL in the ALLOWED_HOSTS array of settings.py. この URL は、os.environ['WEBSITE_HOSTNAME'] というコードを使用して実行時に取得できます。You can retrieve this URL at runtime with the code, os.environ['WEBSITE_HOSTNAME']. App Service によって、WEBSITE_HOSTNAME 環境変数がアプリの URL に自動的に設定されます。App Service automatically sets the WEBSITE_HOSTNAME environment variable to the app's URL.
DATABASES データベースに接続するための App Service の設定を定義し、それらを環境変数として読み込んで DATABASES ディクショナリを設定します。Define settings in App Service for the database connection and load them as environment variables to populate the DATABASES dictionary. または、値 (特にユーザー名とパスワード) を Azure Key Vault シークレットとして格納することもできます。You can alternately store the values (especially the username and password) as Azure Key Vault secrets.

コンテナーの特性Container characteristics

Python アプリは App Service にデプロイされると、App Service Python GitHub リポジトリで定義された Linux Docker コンテナー内で動作します。When deployed to App Service, Python apps run within a Linux 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.

    • Gunicorn の構成の概要に関するページ (docs.gunicorn.org) で説明されているとおり、プロジェクトのルートにある gunicorn.conf.py ファイルを使用して Gunicorn の構成設定を指定できます。You can provide configuration settings for Gunicorn through a gunicorn.conf.py file in the project root, as described on Gunicorn configuration overview (docs.gunicorn.org). また、スタートアップ コマンドをカスタマイズすることもできます。You can alternately customize the startup command.

    • Gunicorn のデプロイ」(docs.gunicorn.org) で説明されているとおり、偶発的または意図的な DDoS 攻撃から Web アプリを防御するために、Gunicorn は Nginx リバース プロキシの背後で実行されます。To protect your web app from accidental or deliberate DDOS attacks, Gunicorn is run behind an Nginx reverse proxy as described on Deploying Gunicorn (docs.gunicorn.org).

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

  • Django など、追加のパッケージをインストールするには、直接的な依存関係を指定したプロジェクトのルートに requirements.txt ファイルを作成します。To install additional packages, such as Django, create a requirements.txt file in the root of your project that specifies your direct dependencies. そうすることで、App Service によって、それらの依存関係がプロジェクトのデプロイ時に自動的にインストールされます。App Service then installs those dependencies automatically when you deploy your project.

    依存関係がインストールされるには、requirements.txt ファイルがプロジェクトのルートに "なければなりません"。The requirements.txt file must be in the project root for dependencies to be installed. そうでないと、ビルド プロセスでエラーがレポートされます: "Could not find setup.py or requirements.txt; Not running pip install." (setup.py または requirements.txt が見つかりませんでした; pip install が実行されていません。)Otherwise, the build process reports the error: "Could not find setup.py or requirements.txt; Not running pip install." このエラーが発生した場合は、自分の requirements ファイルの場所を確認してください。If you encounter this error, check the location of your requirements file.

  • App Service では、Web アプリの URL (msdocs-hello-world.azurewebsites.net など) を使用して、WEBSITE_HOSTNAME という名前の環境変数が自動的に定義されます。App Service automatically defines an environment variable named WEBSITE_HOSTNAME with the web app's URL, such as msdocs-hello-world.azurewebsites.net. また、アプリの名前 (msdocs-hello-world など) を使用して WEBSITE_SITE_NAME も定義されます。It also defines WEBSITE_SITE_NAME with the name of your app, such as msdocs-hello-world.

コンテナーのスタートアップ プロセス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 name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

スタートアップ コマンドをより細かくコントロールしたい場合、カスタム スタートアップ コマンドを使用し、<module>wsgi.py が含まれているフォルダーの名前に置き換えます。そのモジュールがプロジェクトのルートにない場合は --chdir 引数を追加してください。If you want more specific control over the startup command, use a custom startup command, replace <module> with the name of folder that contains wsgi.py, and add a --chdir argument if that module is not in the project root. たとえば、自分のプロジェクトのルートを基準として knboard/backend/configwsgi.py が配置されている場合は、引数 --chdir knboard/backend config.wsgi を使用します。For example, if your wsgi.py is located under knboard/backend/config from your project root, use the arguments --chdir knboard/backend config.wsgi.

運用ログを有効にするには、カスタム スタートアップ コマンドの例で示しているとおり、--access-logfile および --error-logfile パラメーターを追加します。To enable production logging, add the --access-logfile and --error-logfile parameters as shown in the examples for custom startup commands.

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 and shown in the following image.

コードをデプロイしても既定のアプリが表示される場合は、「トラブルシューティング」の「アプリが表示されない」を参照してください。If you deployed code and still see the default app, see Troubleshooting - App doesn't appear.

App Service on Linux の既定の Web ページDefault App Service on Linux web page

繰り返しになりますが、既定のアプリではなく、デプロイしたアプリを表示する必要がある場合は、「トラブルシューティング」の「アプリが表示されない」を参照してください。Again, if you expect to see a deployed app instead of the default app, see Troubleshooting - App doesn't appear.

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

この記事で前に述べたように、Gunicorn の構成の概要に関するページで説明されているとおり、プロジェクトのルートにある gunicorn.conf.py ファイルを使用して Gunicorn の構成設定を指定できます。As noted earlier in this article, you can provide configuration settings for Gunicorn through a gunicorn.conf.py file in the project root, as described on Gunicorn configuration overview.

このような構成では十分でない場合は、スタートアップ コマンド ファイルでカスタム スタートアップ コマンドまたは複数のコマンドを指定して、コンテナーのスタートアップ動作をコントロールできます。If such configuration is not sufficient, you can control the container's startup behavior by providing either a custom startup command or multiple commands in a startup command file. スタートアップ コマンド ファイルでは、startup.shstartup.cmdstartup.txt など、任意の名前を使用することができます。A startup command file can use whatever name you choose, such as startup.sh, startup.cmd, startup.txt, and so on.

どのコマンドでも、プロジェクトのルート フォルダーへの相対パスを使用する必要があります。All commands must use relative paths to the project root folder.

スタートアップ コマンドまたはコマンド ファイルを指定するには:To specify a startup command or command file:

  • Azure portal: アプリの [構成] ページを選択してから、 [全般設定] を選択します。Azure portal: select the app's Configuration page, then select General settings. [スタートアップ コマンド] フィールドで、自分のスタートアップ コマンドの完全なテキスト、または自分のスタートアップ コマンド ファイルの名前を入力します。In the Startup Command field, place either the full text of your startup command or the name of your startup command file. 次に、 [保存] を選択して変更を適用します。Then select Save to apply the changes. Linux コンテナー用に「全般設定を構成する」を参照してください。See Configure general settings for Linux containers.

  • Azure CLI: --startup-file パラメーターをスタートアップ コマンドまたはファイルに設定して、az webapp config set コマンドを使用します。Azure CLI: use the az webapp config set command with the --startup-file parameter to set the startup command or file:

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

    <custom-command> は、自分のスタートアップ コマンドの完全なテキスト、または自分のスタートアップ コマンド ファイルの名前に置き換えます。Replace <custom-command> with either the full text of your startup command or the name of your startup command file.

App Service では、カスタム スタートアップ コマンドまたはファイルの処理中に発生したエラーが無視されて、Django および Flask アプリが検索されることでスタートアップ プロセスが続行されます。App Service ignores any errors that occur when processing a custom startup command or 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 command or file is error-free and that a startup command file is deployed to App Service along with your app code. 診断ログで詳細な情報を確認することもできます。You can also check the Diagnostic logs for additional information. また、Azure portal でアプリの [問題の診断と解決] ページも確認してください。Also check the app's Diagnose and solve problems page on the Azure portal.

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

  • Gunicorn 引数の追加: 次の例では、Django アプリを起動するための Gunicorn コマンド ラインに --workers=4 を追加します。Added Gunicorn arguments: The following example adds the --workers=4 to a Gunicorn command line for starting a Django app:

    # <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 Gunicorn (Gunicorn の実行)」 (docs.gunicorn.org) を参照してください。For more information, see Running Gunicorn (docs.gunicorn.org).

  • Django での運用ログの有効化: --access-logfile '-' および --error-logfile '-' 引数をコマンド ラインに追加します。Enable production logging for Django: Add the --access-logfile '-' and --error-logfile '-' arguments to the command line:

    # '-' 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 ログ ストリームに表示されます。These logs will appear in the App Service log stream.

    詳細については、Gunicorn のログに関するページ (docs.gunicorn.org) を参照してください。For more information, see Gunicorn logging (docs.gunicorn.org).

  • カスタムの Flask メイン モジュール: 既定では、Flask アプリのメイン モジュールは application.pyapp.py であると App Service によって想定されています。Custom Flask main module: by default, App Service assumes that a Flask app's main module is application.py or app.py. メイン モジュールに別の名前を使用する場合は、スタートアップ コマンドをカスタマイズする必要があります。If your main module uses a different name, then you must customize the startup command. たとえば、メイン モジュールが hello.py で、そのファイルにおける Flask アプリ オブジェクトの名前が myapp である Flask アプリがある場合、コマンドは次のようになります。For example, yf you have a Flask app whose main module is hello.py and the Flask app object in that file is named myapp, then the 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
    
  • Gunicorn 以外のサーバーの使用: 別の Web サーバー (aiohttp など) を使用する場合は、スタートアップ コマンドとして、またはスタートアップ コマンド ファイルで、適切なコマンドを使用します。Use a non-Gunicorn server: To use a different web server, such as aiohttp, use the appropriate command as the startup command or in the startup command file:

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

環境変数としてのアプリ設定へのアクセスAccess app settings as environment variables

アプリケーションの設定の構成」で説明されているとおり、アプリの設定は、お客様のアプリのためにクラウドに格納された値です。App settings are values stored in the cloud specifically for your app as described on Configure app settings. これらの設定は、環境変数として自分のアプリのコードで利用できます。アクセスには標準の os.environ パターンを使用します。These settings are available to your app code as environment variables and accessed using the standard os.environ pattern.

たとえば、DATABASE_SERVER というアプリ設定を作成したら、その設定の値は次のコードで取得します。For example, if you've created app setting called DATABASE_SERVER, the following code retrieves that setting's value:

db_server = os.environ['DATABASE_SERVER']

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

App Service では、SSL 終了 (wikipedia.org) がネットワーク ロード バランサーで発生するため、すべての HTTPS リクエストは暗号化されていない HTTP リクエストとしてアプリに到達します。In App Service, SSL termination (wikipedia.org) 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.

まず、次のコマンドを実行して、コンテナーのログ記録をオンにします。First, turn on container logging by running the following command:

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

<app-name><resource-group-name> は、Web アプリに適した名前に置き換えます。Replace <app-name> and <resource-group-name> with the names appropriate for your web app.

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

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

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

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

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

Azure portal を使用してログにアクセスするには、アプリの左側のメニューにある [監視] > [ログ ストリーム] を選択します。To access logs through the Azure portal, select Monitoring > Log stream on the left side menu for your app.

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

コードをデプロイすると、「ビルドの自動化のカスタマイズ」セクションで説明したビルド プロセスが App Service によって実行されます。When you deploy your code, App Service performs the build process described earlier in the section Customize build automation. ビルドはそれ独自のコンテナー内で実行されるため、ビルド ログは、アプリの診断ログとは別に格納されます。Because the build runs in its own container, build logs are stored separately from the app's diagnostic logs.

デプロイ ログにアクセスするには、次の手順を使用します。Use the following steps to access the deployment logs:

  1. Web アプリの Azure portal で、左側のメニューから [デプロイ] > [デプロイ センター (プレビュー)] を選択します。On the Azure portal for your web app, select Deployment > Deployment Center (Preview) on the left menu.
  2. [ログ] タブで、最新のコミットの [コミット ID] を選択します。On the Logs tab, select the Commit ID for the most recent commit.
  3. 表示された [ログの詳細] ページで、"Running oryx build... (oryx のビルドを実行しています...)" の横に表示される [ログの表示] リンクを選択します。On the Log details page that appears, select the Show Logs... link that appears next to "Running oryx build...".

これらのログには、requirements.txt 内の不適切な依存関係、ビルド前またはビルド後のスクリプトのエラーなど、ビルドの問題が出力されます。Build issues such as incorrect dependencies in requirements.txt and errors in pre- or post-build scripts will appear in these logs. 要件ファイルが厳密に requirements.txt という名前になっていない場合やプロジェクトのルート フォルダーに存在しない場合も、エラーが出力されます。Errors also appear if your requirements file is not exactly named requirements.txt or does not appear in the root folder of your project.

ブラウザーで 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.

SSH セッションへの接続に成功すると、ウィンドウ下部に "SSH CONNECTION ESTABLISHED (SSH 接続が確立されました)" というメッセージが表示されます。When you're successfully connected to the SSH session, you should see the message "SSH CONNECTION ESTABLISHED" at the bottom of the window. "SSH_CONNECTION_CLOSED" などのエラーや、コンテナーが再起動されているというメッセージが表示される場合は、エラーが原因でアプリ コンテナーが起動できなくなっている可能性があります。If you see errors such as "SSH_CONNECTION_CLOSED" or a message that the container is restarting, an error may be preventing the app container from starting. 考えられる問題を調査する手順については、「トラブルシューティング」を参照してください。See Troubleshooting for steps to investigate possible issues.

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

一般に、トラブルシューティングにおける最初の手順は、App Service 診断を使用することです。In general, the first step in troubleshooting is to use App Service Diagnostics:

  1. Web アプリの Azure portal で、左側のメニューから [問題の診断と解決] を選択します。On the Azure portal for your web app, select Diagnose and solve problems from the left menu.
  2. [Availability and performance](可用性とパフォーマンス) を選択します。Select Availability and performance.
  3. 最も一般的な問題が表示される、 [アプリケーション ログ][Container crash](コンテナーのクラッシュ)[Container Issues](コンテナーの問題) の各オプションの情報を調べます。Examine the information in the Application Logs, Container crash, and Container Issues options, where the most common issues will appear.

次に、デプロイ ログアプリ ログの両方で、エラー メッセージが出力されていないかを調べます。Next, examine both the deployment logs and the app logs for any error messages. アプリのデプロイや起動を妨げる特定の問題が、これらのログによって明らかになることが少なくありません。These logs often identify specific issues that can prevent app deployment or app startup. たとえば、requirements.txt ファイルがプロジェクトのルート フォルダーに存在しない場合やファイル名に誤りがある場合は、ビルドに失敗する可能性があります。For example, the build can fail if your requirements.txt file has the wrong filename or isn't present in your project root folder.

具体的な問題の詳細なガイダンスについては、次のセクションを参照してください。The following sections provide additional guidance for specific issues.

アプリが表示されないApp doesn't appear

  • 自分のアプリ コードをデプロイした後に既定のアプリが表示される。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-name> --query kind コマンドを実行します。<resource-group-name><app-name> は適宜置き換えてください。From the Azure CLI, run the command az webapp show --resource-group <resource-group-name> --name <app-name> --query kind, replacing <resource-group-name> and <app-name> accordingly. 出力として app,linux が表示されるはずです。それ以外の場合は、App Service を再作成し、Linux を選択してください。You should see app,linux as output; otherwise, recreate the App Service and choose Linux.

    • SSH を使用して App Service コンテナーに直接接続し、ファイルが site/wwwroot に存在することを確認します。Use SSH to connect directly to the App Service container and verify that your files exist under site/wwwroot. ファイルが存在しない場合は、次の手順を実行します。If your files don't exist, use the following steps:

      1. SCM_DO_BUILD_DURING_DEPLOYMENT という名前のアプリ設定を作成し、その値を 1 とします。コードを再デプロイして、数分待ってから、再度アプリにアクセスを試みます。Create an app setting named SCM_DO_BUILD_DURING_DEPLOYMENT with the value of 1, redeploy your code, wait a few minutes, then try to access the app again. アプリ設定の作成の詳細については、「Azure portal で App Service アプリを構成する」を参照してください。For more information on creating app settings, see Configure an App Service app in the Azure portal.
      2. デプロイ プロセスを確認し、デプロイ ログをチェックしてエラーがあれば修正し、アプリを再デプロイします。Review your deployment process, check the deployment logs, correct any errors, 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 app itself did not start. この状況は、Gunicorn の引数が正しくないか、アプリのコードにエラーがあることを示しています。This condition could indicate that the Gunicorn arguments are incorrect, or that there's an error in the app code.

    • ブラウザーを最新の情報に更新します (特に、お客様が 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.

    • アプリ ログ ストリームにエラー メッセージがないか調べます。Examine the app log stream for any error messages. このログには、アプリ コードのエラーがすべて表示されます。The logs will show any errors in the app code.

setup.py または requirements.txt が見つからないCould not find setup.py or requirements.txt

  • ログ ストリームに "Could not find setup.py or requirements.txt; Not running pip install." (setup.py または requirements.txt が見つかりませんでした; pip install が実行されていません。) と表示される。 Oryx のビルド プロセスで、requirements.txt ファイルの検出が失敗しました。The log stream shows "Could not find setup.py or requirements.txt; Not running pip install.": The Oryx build process failed to find your requirements.txt file.

    • SSH を介して Web アプリのコンテナーに接続し、requirements.txt が正しい名前になっていることと site/wwwroot の直下に存在することを確認します。Connect to the web app's container via SSH and verify that requirements.txt is named correctly and exists directly under site/wwwroot. 存在しない場合は、ファイルが自分のリポジトリに存在していて、自分のデプロイに含まれている場所を作ります。If it doesn't exist, make site the file exists in your repository and is included in your deployment. 別のフォルダーに存在する場合は、それをルートに移動させてください。If it exists in a separate folder, move it to the root.

その他の問題Other issues

  • SSH セッションで、入力したパスワードが表示されない: SSH セッションでは、セキュリティ上の理由により、入力中のパスワードは非表示になります。Passwords don't appear in the SSH session when typed: For security reasons, the SSH session keeps your password hidden as you type. ただし文字は記録されているので、通常どおりにパスワードを入力し、終わったら Enter キーを押してください。The characters are being recorded, however, so type your password as usual and press Enter when done.

  • SSH セッションで、コマンドが途切れたように表示される: エディターでコマンドのテキストが折り返されないことがありますが、その場合でも正しく実行されます。Commands in the SSH session appear to be cut off: The editor may not be word-wrapping commands, but they should still run correctly.

  • Django アプリに静的資産が表示されない: whitenoise モジュールを有効にしていることを確認してください。Static assets don't appear in a Django app: Ensure that you have enabled the whitenoise module

  • "Fatal SSL Connection is Required (致命的: SSL 接続が必要です)" というメッセージが表示される: アプリ内からリソース (データベースなど) へのアクセスに使用したユーザー名とパスワードを確認してください。You see the message, "Fatal SSL Connection is Required": Check any usernames and passwords used to access resources (such as databases) from within the app.

次のステップNext steps