Azure App Service で PHP アプリを構成する

2025-05-07

警告

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

このガイドでは、Azure App Service の PHP Web アプリ、モバイルバックエンド、API アプリを構成する方法を示します。最も一般的な構成タスクについて説明します。

App Service を初めて使用する場合は、まず「 Azure App Service で PHP Web アプリを作成する」のクイックスタートと「PHP、MySQL、Redis アプリを Azure App Service にデプロイする」チュートリアルに従う必要があります。

PHP のバージョンを表示する

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

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

<resource-group-name> と <app-name> は、Web アプリに適した名前に置き換えます。

注

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

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

az webapp list-runtimes --os windows | grep PHP

PHP のバージョンを表示する

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

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

<resource-group-name> と <app-name> は、Web アプリに適した名前に置き換えます。

注

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

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

az webapp list-runtimes --os linux | grep PHP

PHP のバージョンを設定する

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

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

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

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

App Service の古いランタイムはどうなりますか?

古いランタイムは、保守組織によって非推奨になったり、重大な脆弱性が見つかったりします。そのため、ポータルの作成ページと構成ページから削除されます。古いランタイムがポータルから非表示になっている場合、そのランタイムをまだ使用しているアプリは引き続き実行されます。

ポータルに表示されなくなった古いランタイムバージョンのアプリを作成する場合は、Azure CLI、ARM テンプレート、または Bicep を使用します。これらのデプロイの代替手段を使用すると、ポータルで削除されたが、引き続きサポートされている非推奨のランタイムを作成できます。

ランタイムが App Service プラットフォームから完全に削除された場合、Azure サブスクリプション所有者は削除前に電子メール通知を受け取ります。

Composer を実行する

デプロイ時に App Service で Composer を実行する場合、最も簡単な方法は、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 はデプロイの自動化の一部として実行されているはずです。

Bower、gulp、または Grunt を実行する

App Service でデプロイ時に一般的な自動化ツール (Bower、Gulp、Grunt など) を実行する場合は、カスタムデプロイスクリプトを用意する必要があります。 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に、必要なツールの実行に必要なコードセクションを追加します。

バウアー
gulp
グラント

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

亭

このスニペットは 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 を実行します。

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

App Service が Linux で PHP アプリを実行およびビルドする方法については、 PHP アプリの検出方法とビルド方法に関する Oryx のドキュメントを参照してください。

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

カスタムコマンドは、コンテナの起動時に実行できます。次のコマンドを実行します。

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) をポイントします。

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 ディレクティブを変更できます。

注

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

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

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

.user.ini ファイルで使用するものと同じ構文を使用して、構成設定を php.ini ファイルに追加します。たとえば、display_errors 設定をオンにして upload_max_filesize 設定を 10M に設定する場合は、.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 ディレクティブをカスタマイズできます。

Linux Web アプリ (PHP_INI_USER や PHP_INI_PERDIR など) の PHP_INI_ALL、upload_max_filesize、expose_php ディレクティブをカスタマイズするには、カスタム .ini ファイルを使用します。これは、SSH セッションで作成できます。最初に、ディレクトリを設定します。

Kudu サイトに移動します。ランダムなハッシュ値とリージョン値を取得するには、アプリの [概要] で [デフォルトドメイン] をコピーします。
上部のメニューで、[ デバッグコンソール] を選択し、[ 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 拡張機能を再コンパイルした場合は、「PHP 拡張機能の再コンパイル」の手順に従ってください。

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

PHP_INI_SYSTEM ディレクティブをカスタマイズするには、PHP_INI_SCAN_DIR アプリ設定を使用します。

まず、次のコマンドを実行して、 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"

Azure portal で、アプリを選択します。サイドバーメニューの [開発ツール ]で、[ 詳細ツール]を選択し、[SSHを使用して d:\home\site ]に移動します。

d:\home\site 内に ini という名前のディレクトリを作成します。次に、ディレクトリに d:\home\site\ini ファイル (settings.ini など) を作成し、カスタマイズするディレクティブを含めます。 php.ini ファイルで使用するのと同じ構文を使用します。

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

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

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

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

まず、次のコマンドを実行して、 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 セッションに移動します。

/home/site 内に ini という名前のディレクトリを作成します。次に、ディレクトリに /home/site/ini ファイル (settings.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 構成を確認する最善の方法は、アプリで 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 秒以内にもう一度確認します。

ログストリーミングをいつでも停止するには、Ctrl+ キーを押します。

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

コンテナーのログを有効にするには、次のコマンドを実行します。

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+ キーを押します。

トラブルシューティング

動作中の 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、Redis アプリを Azure App Service にデプロイする

Azure App Service on Linux の FAQ

Azure App Service の環境変数とアプリ設定

次の方法で共有

Azure App Service で PHP アプリを構成する

PHP のバージョンを表示する

PHP のバージョンを表示する

PHP のバージョンを設定する

App Service の古いランタイムはどうなりますか?

Composer を実行する

Bower、gulp、または Grunt を実行する

亭

gulp

イサキ

ビルド オートメーションのカスタマイズ

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

環境変数へのアクセス

サイト ルートを変更する

HTTPS セッションを検出する

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

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

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

PHP 拡張機能を有効にする

診断ログにアクセスする

トラブルシューティング

ログ内の robots933456 メッセージを無視する

関連コンテンツ

フィードバック

その他のリソース

ビルドオートメーションのカスタマイズ

サイトルートを変更する