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

[アーティクル]
08/31/2023

PHP バージョンを表示する

警告

Windows 上の PHP は 2022 年 11 月にサポート終了となり、App Service on Linux でのみサポートされています。この記事は参照専用です。。

このガイドでは、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 アプリを構成する方法を示します。

現在の 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 セクションの末尾に必要なツールの実行に必要なコードセクションを追加します。

Bower
Gulp
Grunt

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

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

Note

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

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

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

変更をデプロイします。

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 フレームワークでは、実稼働モードで実行しているときにカスタムスタートアップスクリプトを使用することがあります。
デバッグモードで 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 に知らせます。

次のステップ

チュートリアル:PHP アプリと MySQL

App Service Linux の FAQ

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

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

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

PHP バージョンを表示する

PHP バージョンを設定する

Composer を実行する

Grunt/Bower/Gulp を実行する

Bower

Gulp

Grunt

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

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

環境変数にアクセスする

サイト ルートを変更する

HTTPS セッションを検出する

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

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

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

PHP 拡張機能を有効にする

診断ログにアクセスする

トラブルシューティング

ログの robots933456

次のステップ

その他のリソース

サイトルートを変更する