Mengonfigurasi aplikasi PHP untuk Azure App Service

Panduan ini menunjukkan cara mengonfigurasi aplikasi web PHP, backend seluler, dan aplikasi API di Azure App Service.

Panduan ini menyediakan petunjuk dan konsep utama untuk pengembang PHP yang menyebarkan aplikasi ke App Service. Jika Anda belum pernah menggunakan Azure App Service, ikuti mulai cepat PHP dan tutorial PHP dengan MySQL terlebih dahulu.

Menampilkan versi PHP

Untuk menunjukkan versi PHP saat ini, jalankan perintah berikut di Cloud Shell:

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

Catatan

Untuk mengatasi slot pengembangan, sertakan parameter --slot yang diikuti dengan nama slot.

Untuk menunjukkan semua versi PHP yang didukung, jalankan perintah berikut di Cloud Shell:

az webapp list-runtimes | grep php

Untuk menunjukkan versi PHP saat ini, jalankan perintah berikut di Cloud Shell:

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

Catatan

Untuk mengatasi slot pengembangan, sertakan parameter --slot yang diikuti dengan nama slot.

Untuk menunjukkan semua versi PHP yang didukung, jalankan perintah berikut di Cloud Shell:

az webapp list-runtimes --linux | grep PHP

Menetapkan versi PHP

Jalankan perintah berikut di Cloud Shell untuk menetapkan versi PHP ke 7.4:

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

Jalankan perintah berikut di Cloud Shell untuk menetapkan versi PHP ke 7.2:

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

Menjalankan Komposer

Jika Anda ingin App Service menjalankan Komposer pada waktu penyebaran, cara termudah adalah menyertakan Komposer di repositori Anda.

Dari jendela terminal lokal, ubah direktori ke akar repositori Anda, dan ikuti petunjuk saat mengunduh Komposer untuk mengunduh composer.phar ke akar direktori.

Jalankan perintah berikut (Anda perlu menginstal npm):

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

Akar repositori Anda sekarang memiliki dua file tambahan: .deployment dan deploy.sh.

Buka deploy.sh dan temukan bagian Deployment, yang terlihat seperti ini:

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

Tambahkan bagian kode yang Anda perlukan untuk menjalankan alat yang diperlukan di akhir bagian 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

Terapkan semua perubahan Anda dan sebarkan kode Anda menggunakan Git, atau sebaran Zip dengan otomatisasi build diaktifkan Komposer sekarang akan berjalan sebagai bagian dari otomatisasi penyebaran.

Menjalankan Grunt/Bower/Gulp

Jika Anda ingin App Service menjalankan alat otomatisasi populer pada waktu penyebaran, seperti Grunt, Bower, atau Gulp, Anda perlu menyediakan skrip penyebaran kustom. App Service menjalankan skrip ini saat Anda menyebarkan dengan Git, atau dengan Penyebaran zip dengan otomatisasi build diaktifkan.

Agar repositori Anda dapat menjalankan alat ini, Anda perlu menambahkannya ke dependensi di package.json. Contohnya:

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

Dari jendela terminal lokal, ubah direktori ke akar repositori Anda dan jalankan perintah berikut (Anda perlu menginstal npm):

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

Akar repositori Anda sekarang memiliki dua file tambahan: .deployment dan deploy.sh.

Buka deploy.sh dan temukan bagian Deployment, yang terlihat seperti ini:

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

Bagian ini diakhiri dengan menjalankan npm install --production. Tambahkan bagian kode yang Anda perlukan untuk menjalankan alat yang diperlukan di akhir bagian Deployment:

Lihat contoh dalam sampel MEAN.js, tempat skrip penyebaran juga menjalankan perintah npm install kustom.

Bower

Cuplikan ini menjalankan 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

Cuplikan ini menjalankan 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

Cuplikan ini menjalankan grunt.

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

Menyesuaikan otomatisasi build

Jika Anda menyebarkan aplikasi menggunakan paket zip atau Git dengan otomatisasi build diaktifkan, App Service membuat langkah-langkah otomatisasi melalui urutan berikut:

  1. Jalankan skrip kustom jika ditentukan oleh PRE_BUILD_SCRIPT_PATH.
  2. Jalankan php composer.phar install.
  3. Jalankan skrip kustom jika ditentukan oleh POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND dan POST_BUILD_COMMAND merupakan variabel lingkungan yang kosong secara default. Untuk menjalankan perintah pra-build, tentukan PRE_BUILD_COMMAND. Untuk menjalankan perintah pasca-build, tentukan POST_BUILD_COMMAND.

Contoh berikut menentukan dua variabel ke serangkaian perintah, yang dipisahkan oleh koma.

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"

Untuk variabel lingkungan tambahan untuk menyesuaikan otomatisasi build, lihat Konfigurasi Oryx.

Untuk mengetahui informasi selengkapnya tentang cara App Service menjalankan dan membuat aplikasi PHP di Linux, lihat Dokumentasi Oryx: Bagaimana aplikasi PHP dideteksi dan dibuat.

Menyesuaikan start-up

Secara default, kontainer PHP bawaan menjalankan server Apache. Pada start-up, kontainer menjalankan apache2ctl -D FOREGROUND". Jika mau, Anda dapat menjalankan perintah lain saat start-up, dengan menjalankan perintah berikut di Cloud Shell:

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

Mengakses variabel lingkungan

Di App Service, Anda dapat menetapkan pengaturan aplikasi di luar kode aplikasi. Lalu, Anda dapat mengaksesnya menggunakan pola getenv() standar. Misalnya, untuk mengakses pengaturan aplikasi yang disebut DB_HOST, gunakan kode berikut:

getenv("DB_HOST")

Mengubah akar situs

Kerangka kerja web pilihan Anda dapat menggunakan subdirektori sebagai akar situs. Misalnya, Laravel, menggunakan subdirektori public/ sebagai akar situs.

Untuk menyesuaikan akar situs, atur jalur aplikasi virtual untuk aplikasi menggunakan perintah az resource update. Contoh berikut ini mengatur akar situs ke subdirektori public/ di repositori Anda.

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

Secara default, Azure App Service menunjuk jalur aplikasi virtual akar ( / ) ke direktori akar file aplikasi yang disebarkan (sites\wwwroot).

Kerangka kerja web pilihan Anda dapat menggunakan subdirektori sebagai akar situs. Misalnya, Laravel, menggunakan subdirektori public/ sebagai akar situs.

Gambar PHP default untuk App Service menggunakan Apache, dan tidak memungkinkan Anda menyesuaikan akar situs untuk aplikasi Anda. Untuk mengatasi batasan ini, tambahkan file .htaccess ke akar repositori dengan konten berikut:

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

Jika Anda lebih suka tidak menggunakan tulisan ulang .htaccess, Anda dapat menyebarkan aplikasi Laravel dengan gambar Docker kustom sebagai gantinya.

Mendeteksi sesi HTTPS

Di App Service, penghentian SSL terjadi pada penyeimbang muatan jaringan, sehingga semua permintaan HTTPS mencapai aplikasi Anda sebagai permintaan HTTP yang tidak terenkripsi. Jika logika aplikasi Anda perlu memeriksa apakah permintaan pengguna dienkripsi atau tidak, periksa header X-Forwarded-Proto.

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

Kerangka kerja web populer memungkinkan Anda mengakses informasi X-Forwarded-* dalam pola aplikasi standar Anda. Di CodeIgniter, is_https() memeriksa nilai X_FORWARDED_PROTO secara default.

Menyesuaikan php.ini ini

Jika Anda perlu membuat perubahan pada penginstalan PHP, Anda dapat mengubah salah satu arahan php.ini dengan mengikuti langkah-langkah ini.

Catatan

Cara terbaik untuk melihat versi PHP dan konfigurasi php.ini saat ini adalah dengan memanggil phpinfo() di aplikasi Anda.

Menyesuaikan arahan non-PHP_INI_SYSTEM

Untuk menyesuaikan arahan PHP_INI_USER, PHP_INI_PERDIR, dan PHP_INI_ALL (lihat arahan php.ini), tambahkan file .user.ini ke direktori akar aplikasi Anda.

Tambahkan pengaturan konfigurasi ke file .user.ini menggunakan sintaksis yang sama dengan yang akan Anda gunakan dalam file php.ini. Misalnya, jika Anda ingin mengaktifkan pengaturan display_errors dan menetapkan pengaturan upload_max_filesize ke 10M, file .user.ini Anda akan berisi teks ini:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

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

Menyebarkan ulang aplikasi Anda dengan perubahan dan mulai ulang.

Sebagai alternatif untuk menggunakan file .user.ini, Anda dapat menggunakan ini_set() di aplikasi untuk menyesuaikan arahan non-PHP_INI_SYSTEM ini.

Untuk menyesuaikan arahan PHP_INI_USER, PHP_INI_PERDIR, dan PHP_INI_ALL (lihat arahan php.ini), tambahkan file .htaccess ke direktori akar aplikasi Anda.

Dalam file .htaccess, tambahkan arahan menggunakan sintaksis php_value <directive-name> <value>. Contohnya:

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

Menyebarkan ulang aplikasi Anda dengan perubahan dan mulai ulang. Jika Anda menyebarkannya dengan Kudu (misalnya, menggunakan Git), pemulaian ulang otomatis dilakukan setelah penyebaran.

Sebagai alternatif untuk menggunakan .htaccess, Anda dapat menggunakan ini_set() di aplikasi untuk menyesuaikan arahan non-PHP_INI_SYSTEM ini.

Menyesuaikan arahan PHP_INI_SYSTEM

Untuk menyesuaikan PHP_INI_SYSTEM (lihat arahan php.ini), Anda tidak dapat menggunakan pendekatan .htaccess. App Service menyediakan mekanisme terpisah menggunakan pengaturan aplikasi PHP_INI_SCAN_DIR.

Pertama, jalankan perintah berikut di Cloud Shell untuk menambahkan pengaturan aplikasi yang disebut 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"

Navigasi ke konsol Kudu (https://<app-name>.scm.azurewebsites.net/DebugConsole) dan navigasi ke d:\home\site.

Buat direktori di d:\home\site yang disebut ini, lalu buat file .ini di direktori d:\home\site\ini (misalnya, settings.ini) dengan arahan yang ingin Anda sesuaikan. Gunakan sintaksis yang sama dengan yang akan Anda gunakan dalam file php.ini.

Misalnya, untuk mengubah nilai expose_php, jalankan perintah berikut:

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

Agar perubahan diterapkan, mulai ulang aplikasi.

Untuk menyesuaikan PHP_INI_SYSTEM (lihat arahan php.ini), Anda tidak dapat menggunakan pendekatan .htaccess. App Service menyediakan mekanisme terpisah menggunakan pengaturan aplikasi PHP_INI_SCAN_DIR.

Pertama, jalankan perintah berikut di Cloud Shell untuk menambahkan pengaturan aplikasi yang disebut 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 adalah direktori default tempat php.ini berada. /home/site/ini adalah direktori kustom tempat Anda akan menambahkan file .ini. Anda memisahkan nilai dengan :.

Navigasi ke sesi SSH web dengan kontainer Linux Anda (https://<app-name>.scm.azurewebsites.net/webssh/host).

Buat direktori di /home/site yang disebut ini, lalu buat file .ini di direktori /home/site/ini (misalnya, settings.ini) dengan arahan yang ingin Anda sesuaikan. Gunakan sintaksis yang sama dengan yang akan Anda gunakan dalam file php.ini.

Tip

Dalam kontainer Linux bawaan di App Service, /home digunakan sebagai penyimpanan bersama yang mempertahankan.

Misalnya, untuk mengubah nilai expose_php, jalankan perintah berikut:

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

Agar perubahan diterapkan, mulai ulang aplikasi.

Mengaktifkan ekstensi PHP

Penginstalan PHP bawaan berisi ekstensi yang paling umum digunakan. Anda dapat mengaktifkan ekstensi tambahan dengan cara yang sama seperti saat Anda menyesuaikan arahan php.ini.

Catatan

Cara terbaik untuk melihat versi PHP dan konfigurasi php.ini saat ini adalah dengan memanggil phpinfo() di aplikasi Anda.

Untuk mengaktifkan ekstensi tambahan, dengan mengikuti langkah-langkah ini:

Tambahkan direktori bin ke direktori akar aplikasi Anda dan letakkan file ekstensi .dll di dalamnya (misalnya, mongodb.dll). Pastikan bahwa ekstensi kompatibel dengan versi PHP di Azure dan kompatibel dengan VC9 dan non-thread-safe (nts).

Sebarkan perubahan Anda.

Ikuti langkah-langkah dalam arahan PHP_INI_SYSTEM, dan tambahkan ekstensi ke dalam file .ini kustom dengan arahan extension atau zend_extension.

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

Agar perubahan diterapkan, mulai ulang aplikasi.

Penginstalan PHP bawaan berisi ekstensi yang paling umum digunakan. Anda dapat mengaktifkan ekstensi tambahan dengan cara yang sama seperti saat Anda menyesuaikan arahan php.ini.

Catatan

Cara terbaik untuk melihat versi PHP dan konfigurasi php.ini saat ini adalah dengan memanggil phpinfo() di aplikasi Anda.

Untuk mengaktifkan ekstensi tambahan, dengan mengikuti langkah-langkah ini:

Tambahkan direktori bin ke direktori akar aplikasi Anda dan letakkan file ekstensi .so di dalamnya (misalnya, mongodb.so). Pastikan bahwa ekstensi kompatibel dengan versi PHP di Azure dan kompatibel dengan VC9 dan non-thread-safe (nts).

Sebarkan perubahan Anda.

Ikuti langkah-langkah dalam arahan PHP_INI_SYSTEM, dan tambahkan ekstensi ke dalam file .ini kustom dengan arahan extension atau zend_extension.

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

Agar perubahan diterapkan, mulai ulang aplikasi.

Mengakses log diagnostik

Gunakan utilitas error_log() standar untuk membuat log diagnostik Anda muncul di Azure App Service.

Untuk mengakses log konsol yang dihasilkan dari dalam kode aplikasi Anda di App Service, aktifkan pembuatan log diagnostik dengan menjalankan perintah berikut di Cloud Shell:

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

Nilai yang mungkin untuk --level adalah: Error, Warning, Info, dan Verbose. Setiap level berikutnya mencakup level sebelumnya. Misalnya: Error hanya menyertakan pesan kesalahan, dan Verbose menyertakan semua pesan.

Setelah pembuatan log diagnostik diaktifkan, jalankan perintah berikut untuk melihat aliran log:

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

Jika Anda tidak segera melihat log konsol, periksa lagi dalam 30 detik.

Catatan

Anda juga dapat memeriksa file log dari browser di https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Untuk menghentikan streaming log kapan saja, ketikkan Ctrl+C.

Anda dapat mengakses log konsol yang dihasilkan dari dalam kontainer.

Pertama, aktifkan pengelogan kontainer dengan menjalankan perintah berikut:

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

Ganti <app-name> dan <resource-group-name> dengan nama yang sesuai untuk aplikasi web Anda.

Setelah pengelogan kontainer diaktifkan, jalankan perintah berikut untuk melihat aliran log:

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

Jika Anda tidak segera melihat log konsol, periksa lagi dalam 30 detik.

Untuk menghentikan streaming log kapan saja, tekan Ctrl+C.

Anda juga dapat memeriksa file log di browser di https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Pemecahan Masalah

Saat aplikasi PHP yang aktif berperilaku berbeda di App Service atau mengalami kesalahan, coba berikut ini:

  • Akses aliran log.
  • Uji aplikasi secara lokal dalam mode produksi. App Service menjalankan aplikasi Anda dalam mode produksi, jadi Anda perlu memastikan bahwa proyek berfungsi seperti yang diharapkan dalam mode produksi secara lokal. Contohnya:
    • Tergantung pada composer.json Anda, paket yang berbeda mungkin diinstal untuk mode produksi (require vs. require-dev).
    • Kerangka kerja web tertentu dapat menyebarkan file statis secara berbeda dalam mode produksi.
    • Kerangka kerja web tertentu mungkin menggunakan skrip startup kustom saat berjalan dalam mode produksi.
  • Jalankan aplikasi Anda di App Service dalam mode debug. Misalnya, di Laravel, Anda dapat mengonfigurasi aplikasi untuk menghasilkan pesan debug dalam produksi dengan mengatur pengaturan aplikasi APP_DEBUG ke true .

robot933456 dalam log

Anda mungkin melihat pesan berikut dalam log kontainer:

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

Anda dapat mengabaikan pesan ini dengan aman. /robots933456.txt adalah jalur URL dummy yang digunakan App Service untuk memeriksa apakah kontainer mampu melayani permintaan. Respons 404 hanya menunjukkan bahwa jalur tersebut tidak ada, tetapi ini memberi tahu App Service bahwa kontainernya sehat dan siap untuk menanggapi permintaan.

Langkah berikutnya

Atau, lihat sumber daya tambahan:

Variabel lingkungan dan referensi pengaturan aplikasi