Azure App Service 向けの PHP アプリを構成する
PHP バージョンを表示する
このガイドでは、Azure App Service の PHP Web アプリ、モバイル バックエンド、API アプリを構成する方法を示します。
このガイドでは、App Service にアプリをデプロイする PHP 開発者向けに主要な概念と手順を示します。 Azure App Service を使用したことがない場合は、最初に PHP クイック スタートと PHP と MySQL のチュートリアルに従ってください。
現在の PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。
az webapp config show --resource-group <resource-group-name> --name <app-name> --query phpVersion
Note
開発スロットに対処するには、--slot
パラメーターの後にスロット名を指定して含めます。
サポートされているすべての PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。
az webapp list-runtimes --os windows | grep PHP
このガイドでは、Azure App Service の PHP Web アプリ、モバイル バックエンド、API アプリを構成する方法を示します。
このガイドでは、App Service にアプリをデプロイする PHP 開発者向けに主要な概念と手順を示します。 Azure App Service を使用したことがない場合は、最初に PHP クイック スタートと PHP と MySQL のチュートリアルに従ってください。
現在の PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Note
開発スロットに対処するには、--slot
パラメーターの後にスロット名を指定して含めます。
サポートされているすべての PHP バージョンを表示するには、Cloud Shell で次のコマンドを実行します。
az webapp list-runtimes --os linux | grep PHP
PHP バージョンを設定する
PHP バージョンを 8.1 に設定するには、Cloud Shell で次のコマンドを実行します。
az webapp config set --resource-group <resource-group-name> --name <app-name> --php-version 8.1
PHP バージョンを 8.1 に設定するには、Cloud Shell で次のコマンドを実行します。
az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PHP|8.1"
Composer を実行する
デプロイ時に App Service で Composer を実行する場合、最も簡単な方法は、Composer をリポジトリに含めることです。
ローカルのターミナル ウィンドウから、リポジトリのルートにディレクトリを変更し、Download Composer (Composer のダウンロード) の指示に従い、ディレクトリ ルートに composer.phar をダウンロードします。
次のコマンドを実行します (npm をインストールしておく必要があります)。
npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt
リポジトリのルートには現在、 .deployment と deploy.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
リポジトリのルートには現在、 .deployment と deploy.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 のビルドの自動化によって、次の手順が実行されます。
PRE_BUILD_SCRIPT_PATH
によって指定された場合、カスタム スクリプトを実行します。php composer.phar install
を実行します。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 アプリが検出されビルドされる方法に関するページを参照してください。
スタートアップのカスタマイズ
必要に応じて、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 は、デプロイされたアプリケーション ファイルのルート ディレクトリ (/) に対して仮想アプリケーションのルート パス ( / ) をポイントします。
選択した Web フレームワークでは、サイト ルートとしてサブディレクトリを使用できます。 たとえば、Laravel は、サイト ルートとして public/
サブディレクトリを使用します。
App Service の既定の PHP イメージでは Nginx が使用されます。サイト ルートを変更するには、Nginx サーバーを root
ディレクティブで構成します。 このサンプル構成ファイルには、root
ディレクティブを変更する次のスニペットが含まれています。
server {
#proxy_cache cache;
#proxy_cache_valid 200 1s;
listen 8080;
listen [::]:8080;
root /home/site/wwwroot/public; # Changed for Laravel
location / {
index index.php index.html index.htm hostingstart.html;
try_files $uri $uri/ /index.php?$args; # Changed for Laravel
}
...
既定のコンテナーでは、/etc/nginx/sites-available/default にある構成ファイルが使用されます。 このファイルに行った編集はすべて、アプリの再起動時に消去されることにご留意ください。 アプリを再起動しても消去されない変更を行うには、次の例のようにカスタムの起動コマンドを追加します。
cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload
このコマンドにより、リポジトリ ルートにある default という名前のファイルが既定の Nginx 構成ファイルに取って代わり、Nginx が再起動されます。
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 ディレクティブを変更できます。
Note
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 ディレクティブをカスタマイズできます。
upload_max_filesize や expose_php など、linux Web アプリの PHP_INI_USER、PHP_INI_PERDIR、PHP_INI_ALL ディレクティブをカスタマイズするには、カスタムの "ini" ファイルを使用します。 これは、SSH セッションで作成できます。
- KUDU サイトの https://<sitename>.scm.azurewebsites.net に移動します。
- 上部のメニューから [Bash] または [SSH] を選びます。
- Bash または SSH で、"/home/site/wwwroot" ディレクトリに移動します。
- "ini" という名前のディレクトリを作成します (例: mkdir ini)。
- 現在の作業ディレクトリを、作成した "ini" フォルダーに変更します。
設定を追加するには、"ini" ファイルを作成する必要があります。 この例では、"extensions.ini" を使います。 Vi、Vim、Nano などのファイル エディターがないため、echo を使ってファイルに設定を追加します。 "upload_max_filesize" を 2M から 50M に変更します。 次のコマンドを使用して設定を追加し、"extensions.ini" ファイルがまだ存在しない場合は作成します。
/home/site/wwwroot/ini>echo "upload_max_filesize=50M" >> extensions.ini
/home/site/wwwroot/ini>cat extensions.ini
upload_max_filesize=50M
/home/site/wwwroot/ini>
次に、Azure portal に移動し、先ほど作成した "ini" ディレクトリをスキャンして upload_max_filesize の変更を適用するために、アプリケーション設定を追加します。
- Azure portal にアクセスし、App Service Linux PHP アプリケーションを選びます。
- アプリの [アプリケーション設定] を選びます。
- [アプリケーション設定] セクションで、[+ 新しい設定の追加] を選びます。
- [アプリ設定名] に「PHP_INI_SCAN_DIR」と入力し、値に「/home/site/wwwroot/ini」と入力します。
- 保存ボタンを選択します。
注意
GD などの PHP 拡張機能を再コンパイルした場合は、Azure App Service での PHP 拡張機能の再コンパイル - PHP 拡張機能の追加に関する記事の手順に従ってください
PHP_INI_SYSTEM ディレクティブをカスタマイズする
PHP_INI_SYSTEM ディレクティブをカスタマイズするには (php.ini ディレクティブを参照)、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\site
に ini
というディレクトリを作成し、続いてカスタマイズするディレクティブを使用した .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/site
に ini
というディレクトリを作成し、続いてカスタマイズするディレクティブを使用した .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 ディレクティブのカスタマイズと同じ方法で、追加の拡張機能を有効にすることができます。
Note
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 ディレクティブのカスタマイズと同じ方法で、追加の拡張機能を有効にすることができます。
Note
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
で有効な値は、Error
、Warning
、Info
、および Verbose
です。 後続の各レベルには、前のレベルが含まれます。 たとえば、Error
にはエラー メッセージのみが含まれ、Verbose
にはすべてのメッセージが含まれます。
診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。
az webapp log tail --resource-group <resource-group-name> --name <app-name>
コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。
Note
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 に応じて、実稼働モードに別々のパッケージ (
require
とrequire-dev
) がインストールされる場合があります。 - 特定の Web フレームワークでは、実稼働モードで静的ファイルを別にデプロイすることがあります。
- 特定の Web フレームワークでは、実稼働モードで実行しているときにカスタム スタートアップ スクリプトを使用することがあります。
- composer.json に応じて、実稼働モードに別々のパッケージ (
- デバッグ モードで 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 に知らせます。
次のステップ
または、その他のリソースを参照してください: