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

このガイドでは、Azure App Service の PHP Web アプリ、モバイル バックエンド、API アプリを構成する方法を示します。

このガイドでは、App Service にアプリをデプロイする PHP 開発者向けに主要な概念と手順を示します。 Azure App Service を使用したことがない場合は、最初に PHP クイック スタートPHP と MySQL のチュートリアルに従ってください。

PHP バージョンを表示する

現在の PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

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

注意

開発スロットに対処するには、--slot パラメーターの後にスロット名を指定して含めます。

サポートされているすべての PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

az webapp list-runtimes | grep php

現在の PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

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

注意

開発スロットに対処するには、--slot パラメーターの後にスロット名を指定して含めます。

サポートされているすべての PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。

az webapp list-runtimes --linux | grep PHP

PHP バージョンを設定する

PHP バージョンを 7.4 に設定するには、Cloud Shell で次のコマンドを実行します。

az webapp config set --resource-group <resource-group-name> --name <app-name> --php-version 7.4

PHP バージョンを 7.2 に設定するには、Cloud Shell で次のコマンドを実行します。

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

Composer を実行する

デプロイ時に App Service で Composer を実行する場合、最も簡単な方法は、Composer をリポジトリに含めることです。

ローカルのターミナル ウィンドウから、リポジトリのルートにディレクトリを変更し、Download Composer (Composer のダウンロード) の指示に従い、ディレクトリ ルートに composer.phar をダウンロードします。

次のコマンドを実行します (npm をインストールしておく必要があります)。

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

リポジトリのルートには現在、 .deploymentdeploy.sh の 2 つの追加ファイルがあります。

deploy.sh を開き、次のような Deployment セクションを見つけます。

##################################################################################################################################
# Deployment
# ----------

Deployment セクションの 末尾 に必要なツールの実行に必要なコード セクションを追加します。

# 4. Use composer
echo "$DEPLOYMENT_TARGET"
if [ -e "$DEPLOYMENT_TARGET/composer.json" ]; then
  echo "Found composer.json"
  pushd "$DEPLOYMENT_TARGET"
  php composer.phar install $COMPOSER_ARGS
  exitWithMessageOnError "Composer install failed"
  popd
fi

Git か、ビルド自動化を有効にした Zip デプロイを利用してすべての変更をコミットし、コードをデプロイします。 これで Composer はデプロイの自動化の一部として実行しているはずです。

Grunt/Bower/Gulp を実行する

Grunt、Bower、Gulp など、一般的な自動化ツールを App Service でデプロイ時に実行する場合、カスタム デプロイ スクリプトを提供する必要があります。 App Service では、Git か、ビルド自動化を有効にした Zip デプロイを利用してデプロイするとき、このスクリプトが実行されます。

リポジトリでこれらのツールを実行できるようにするには、package.json での依存関係にこれらを追加する必要があります。 次に例を示します。

"dependencies": {
  "bower": "^1.7.9",
  "grunt": "^1.0.1",
  "gulp": "^3.9.1",
  ...
}

ローカル ターミナル ウィンドウから、ディレクトリをリポジトリのルートに変更し、次のコマンドを実行します (npm をインストールしておく必要があります)。

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

リポジトリのルートには現在、 .deploymentdeploy.sh の 2 つの追加ファイルがあります。

deploy.sh を開き、次のような Deployment セクションを見つけます。

##################################################################################################################################
# Deployment
# ----------

このセクションは、npm install --production の実行で終わります。 Deployment セクションの 末尾 に必要なツールの実行に必要なコード セクションを追加します。

MEAN.js サンプルでの例を参照してください。ここでは、デプロイ スクリプトはカスタム npm install コマンドも実行します。

Bower

このスニペットは bower install を実行します。

if [ -e "$DEPLOYMENT_TARGET/bower.json" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/bower install
  exitWithMessageOnError "bower failed"
  cd - > /dev/null
fi

Gulp

このスニペットは gulp imagemin を実行します。

if [ -e "$DEPLOYMENT_TARGET/gulpfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/gulp imagemin
  exitWithMessageOnError "gulp failed"
  cd - > /dev/null
fi

Grunt

このスニペットは grunt を実行します。

if [ -e "$DEPLOYMENT_TARGET/Gruntfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/grunt
  exitWithMessageOnError "Grunt failed"
  cd - > /dev/null
fi

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

ビルドの自動化を有効にして Git または zip パッケージを使用してアプリをデプロイする場合、App Service のビルドの自動化によって、次の手順が実行されます。

  1. PRE_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。
  2. php composer.phar install を実行します。
  3. POST_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。

PRE_BUILD_COMMAND および POST_BUILD_COMMAND は、既定では空の環境変数です。 ビルド前のコマンドを実行するには、PRE_BUILD_COMMAND を定義します。 ビルド後のコマンドを実行するには、POST_BUILD_COMMAND を定義します。

次の例では、一連のコマンドに対して 2 つの変数をコンマ区切りで指定しています。

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 の構成」を参照してください。

Linux 上で App Service によって PHP アプリが実行されビルドされる方法に関する詳細については、Oryx ドキュメントの PHP アプリが検出されビルドされる方法に関するページを参照してください。

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

既定では、組み込みの PHP コンテナーによって Apache サーバーが実行されます。 起動時に apache2ctl -D FOREGROUND" を実行します。 必要に応じて、Cloud Shell で次のコマンドを実行することにより、起動時に別のコマンドを実行できます。

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

環境変数へのアクセス

App Service では、アプリ コードの外部でアプリ設定を指定できます。 その後、標準の getenv() パターンを使用して、それらにアクセスできます。 たとえば、DB_HOST というアプリ設定にアクセスするには、次のコードを使用します。

getenv("DB_HOST")

サイト ルートを変更する

選択した Web フレームワークでは、サイト ルートとしてサブディレクトリを使用できます。 たとえば、Laravel では、サイト ルートとして public/ サブディレクトリが使用されます。

サイト ルートをカスタマイズするには、az resource update コマンドを利用し、アプリの仮想アプリケーション パスを設定します。 次の例では、リポジトリの public/ サブディレクトリにサイト ルートが設定されます。

az resource update --name web --resource-group <group-name> --namespace Microsoft.Web --resource-type config --parent sites/<app-name> --set properties.virtualApplications[0].physicalPath="site\wwwroot\public" --api-version 2015-06-01

既定では、Azure App Service は、デプロイされたアプリケーション ファイルのルート ディレクトリ (sites\wwwroot) に対して仮想アプリケーションのルート パス ( / ) をポイントします。

選択した Web フレームワークでは、サイト ルートとしてサブディレクトリを使用できます。 たとえば、Laravel は、サイト ルートとして public/ サブディレクトリを使用します。

App Service の既定の PHP イメージでは Apache が使用されていて、アプリ用にサイト ルートをカスタマイズすることはできません。 この制限を回避するには、次の内容で .htaccess ファイルをリポジトリ ルートに追加します。

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_URI} ^(.*)
    RewriteRule ^(.*)$ /public/$1 [NC,L,QSA]
</IfModule>

.htaccess の書き換えを行わない場合は、代わりに カスタム Docker イメージを使用して Laravel アプリケーションをデプロイできます。

HTTPS セッションの検出

App Service では、TLS または SSL 終了がネットワーク ロード バランサーで発生するため、すべての HTTPS リクエストは暗号化されていない HTTP リクエストとしてアプリに到達します。 ユーザー要求が暗号化されているかどうかをアプリ ロジックが確認する必要がある場合は、X-Forwarded-Proto ヘッダーを調べます。

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
// Do something when HTTPS is used
}

一般的な Web フレームワークでは、標準のアプリ パターンで X-Forwarded-* 情報にアクセスできます。 CodeIgniter では、is_https () は既定で X_FORWARDED_PROTO の値をチェックします。

php.ini 設定をカスタマイズする

PHP のインストールを変更する必要がある場合は、以下の手順に従って、いずれかの php.ini ディレクティブを変更できます。

注意

PHP のバージョンと現在の php.ini 構成を確認する最善の方法は、アプリで phpinfo() を呼び出すことです。

非 PHP_INI_SYSTEM ディレクティブをカスタマイズする

PHP_INI_USER、PHP_INI_PERDIR、PHP_INI_ALL ディレクティブ (php.ini ディレクティブを参照) をカスタマイズするには、.user.ini ファイルをアプリのルート ディレクトリに追加します。

php.ini ファイルで使用するものと同じ構文を使用して、構成設定を .user.ini ファイルに追加します。 たとえば、display_errors 設定をオンにして upload_max_filesize を 10 M に設定する場合は、.user.ini ファイルに次のテキストを含めます。

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

 ; Write errors to d:\home\LogFiles\php_errors.log
 ; log_errors=On

変更内容でアプリを再デプロイし、再起動します。

.user.ini ファイルを使用する代わりに、アプリで ini_set() を使用し、これらの非 PHP_INI_SYSTEM ディレクティブをカスタマイズできます。

PHP_INI_USER、PHP_INI_PERDIR、および PHP_INI_ALL ディレクティブ (php.ini ディレクティブを参照) をカスタマイズするには、 .htaccess ファイルをアプリのルート ディレクトリに追加します。

.htaccess ファイルで、php_value <directive-name> <value> 構文を使用してディレクティブを追加します。 次に例を示します。

php_value upload_max_filesize 1000M
php_value post_max_size 2000M
php_value memory_limit 3000M
php_value max_execution_time 180
php_value max_input_time 180
php_value display_errors On
php_value upload_max_filesize 10M

変更内容でアプリを再デプロイし、再起動します。 Kudu でデプロイする場合 (たとえば Git を使用)、デプロイ後に自動的に再起動します。

.htaccess を使用する代わりに、アプリで ini_set() を使用して、これらの非 PHP_INI_SYSTEM ディレクティブをカスタマイズできます。

PHP_INI_SYSTEM ディレクティブをカスタマイズする

PHP_INI_SYSTEM ディレクティブをカスタマイズするには (php.ini ディレクティブを参照)、 .htaccess アプローチは使用できません。 App Service は、PHP_INI_SCAN_DIR アプリ設定を使用して、別のメカニズムを提供します。

最初に、Cloud Shell で次のコマンドを実行して、PHP_INI_SCAN_DIR というアプリ設定を追加します。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="d:\home\site\ini"

Kudu コンソール (https://<app-name>.scm.azurewebsites.net/DebugConsole) に移動し、d:\home\site に移動します。

d:\home\siteini というディレクトリを作成し、続いてカスタマイズするディレクティブを使用した .ini ファイル (たとえば、settings.ini) を d:\home\site\ini ディレクトリに作成します。 php.ini ファイルで使用するものと同じ構文を使用します。

たとえば、expose_php の値を変更するには、次のコマンドを実行します。

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

変更内容を有効にするには、アプリを再起動します。

PHP_INI_SYSTEM ディレクティブをカスタマイズするには (php.ini ディレクティブを参照)、 .htaccess アプローチは使用できません。 App Service は、PHP_INI_SCAN_DIR アプリ設定を使用して、別のメカニズムを提供します。

最初に、Cloud Shell で次のコマンドを実行して、PHP_INI_SCAN_DIR というアプリ設定を追加します。

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="/usr/local/etc/php/conf.d:/home/site/ini"

/usr/local/etc/php/conf.d は、php.ini が存在している既定のディレクトリです。 /home/site/ini は、カスタム .ini ファイルを追加するカスタム ディレクトリです。 : で値を区切ります。

Linux コンテナーを含む Web SSH セッションに移動します (https://<app-name>.scm.azurewebsites.net/webssh/host)。

/home/siteini というディレクトリを作成し、続いてカスタマイズするディレクティブを使用した .ini ファイル (たとえば、settings.ini) を /home/site/ini ディレクトリに作成します。 php.ini ファイルで使用するものと同じ構文を使用します。

ヒント

App Service でのビルトイン Linux コンテナーで、 /home は永続化された共有ストレージとして使用されます。

たとえば、expose_php の値を変更するには、次のコマンドを実行します。

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

変更内容を有効にするには、アプリを再起動します。

PHP 拡張機能を有効にする

ビルトイン PHP のインストールには、最もよく使用される拡張機能が含まれています。 php.ini ディレクティブのカスタマイズと同じ方法で、追加の拡張機能を有効にすることができます。

注意

PHP のバージョンと現在の php.ini 構成を確認する最善の方法は、アプリで phpinfo() を呼び出すことです。

追加の拡張機能を有効にするには、次の手順に従います。

アプリのルート ディレクトリに bin ディレクトリを追加して、その中に .dll 拡張ファイル (たとえば、mongodb.dll) を配置します。 拡張機能が Azure の PHP バージョンと互換性があり、VC9 および非スレッドセーフ (nts) 互換であることを確認してください。

変更をデプロイします。

PHP_INI_SYSTEM ディレクティブのカスタマイズの手順に従って、extension または zend_extension ディレクティブを使用したカスタム .ini ファイルに拡張機能を追加します。

extension=d:\home\site\wwwroot\bin\mongodb.dll
zend_extension=d:\home\site\wwwroot\bin\xdebug.dll

変更内容を有効にするには、アプリを再起動します。

ビルトイン PHP のインストールには、最もよく使用される拡張機能が含まれています。 php.ini ディレクティブのカスタマイズと同じ方法で、追加の拡張機能を有効にすることができます。

注意

PHP のバージョンと現在の php.ini 構成を確認する最善の方法は、アプリで phpinfo() を呼び出すことです。

追加の拡張機能を有効にするには、次の手順に従います。

アプリのルート ディレクトリに bin ディレクトリを追加して、その中に .so 拡張ファイル (たとえば、mongodb.so) を配置します。 拡張機能が Azure の PHP バージョンと互換性があり、VC9 および非スレッドセーフ (nts) 互換であることを確認してください。

変更をデプロイします。

PHP_INI_SYSTEM ディレクティブのカスタマイズの手順に従って、extension または zend_extension ディレクティブを使用したカスタム .ini ファイルに拡張機能を追加します。

extension=/home/site/wwwroot/bin/mongodb.so
zend_extension=/home/site/wwwroot/bin/xdebug.so

変更内容を有効にするには、アプリを再起動します。

診断ログにアクセスする

標準の error_log() ユーティリティを使用し、Azure App Service に診断ログを表示させます。

App Service のアプリケーション コード内から生成されたコンソール ログにアクセスするには、Cloud Shell で次のコマンドを実行して、診断ログを有効にします。

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

--level で有効な値は、ErrorWarningInfo、および Verbose です。 後続の各レベルには、前のレベルが含まれます。 たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。

診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。

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

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。

注意

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

任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。

コンテナー内から生成されたコンソール ログにアクセスできます。

まず、次のコマンドを実行して、コンテナーのログ記録をオンにします。

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 でログ ファイルを検査することもできます。

トラブルシューティング

動作中の PHP アプリが App Service で異なる動作をしたり、エラーが発生した場合は、次のことを試してください。

  • ログ ストリームにアクセスします。
  • 実稼働モードでローカルにアプリをテストします。 App Service では、アプリが実稼働モードで実行されるので、プロジェクトがローカルで実稼働モードで予想どおりに動作することを確認する必要があります。 次に例を示します。
    • composer.json に応じて、実稼働モードに別々のパッケージ (requirerequire-dev) がインストールされる場合があります。
    • 特定の Web フレームワークでは、実稼働モードで静的ファイルを別にデプロイすることがあります。
    • 特定の Web フレームワークでは、実稼働モードで実行しているときにカスタム スタートアップ スクリプトを使用することがあります。
  • デバッグ モードで Azure App Service でアプリを実行します。 たとえば、Laravel で、APP_DEBUG アプリ設定を true に指定することにより、実稼働環境でのデバッグ メッセージを出力するようにアプリを構成できます。

ログの robots933456

コンテナー ログで次のメッセージが表示されることがあります。

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

このメッセージは無視してかまいません。 /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。

次のステップ

または、その他のリソースを参照してください:

環境変数とアプリ設定のリファレンス