تكوين تطبيق PHP لـ Azure App Service

مقالة
08/31/2023

إظهار إصدار PHP

تحذير

بلغ PHP على Windows نهاية العمر الافتراضي في نوفمبر 2022 وهو مدعوم فقط على App Service على Linux. هذه المقالة مخصصة للرجوع إليها فقط..

يوضح لك هذا الدليل كيفية تكوين تطبيقات ويب PHP والأطراف الخلفية للأجهزة المحمولة وتطبيقات واجهة برمجة التطبيقات في Azure App Service.

يوفر هذا الدليل المفاهيم والإرشادات الأساسية لمطوري PHP الذين يقومون بتوزيع التطبيقات في App Service. إذا لم يسبق لك استخدام Azure App Service، فاتبع التشغيل السريع لـ PHP والبرنامج التعليمي لـ PHP باستخدام MySQL أولاً.

لإظهار إصدار 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 --os windows | 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 --os linux | grep PHP

تعيين إصدار PHP

قم بتشغيل الأمر التالي في Cloud Shell لتعيين إصدار PHP إلى 8.1:

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

قم بتشغيل الأمر التالي في Cloud Shell لتعيين إصدار PHP إلى 8.1:

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

تشغيل Composer

إذا كنت تريد أن تقوم App Service بتشغيل Composer في وقت التوزيع، فإن أسهل طريقة هي تضمين Composer في المستودع الخاص بك.

من نافذة المحطة الطرفية المحلية، قم بتغيير الدليل إلى جذر المستودع الخاص بك، واتبع الإرشادات الواردة في تنزيل Composer لتنزيل composer.phar إلى جذر الدليل.

قم بتشغيل الأوامر التالية (تحتاج إلى تثبيت npm):

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

لدى جذر المستودع الآن ملفين إضافيين: .deployment وdeploy.sh.

قم بفتح 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

إذا كنت تريد أن تقوم App Service بتشغيل أدوات التنفيذ التلقائي الشائعة في وقت التوزيع، مثل Grunt أو Bower أو Gulp، فأنت بحاجة إلى توفير برنامج نصي مخصص للتوزيع. تقوم 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.

قم بفتح 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.

يحدد المثال التالي المتغيرين لسلسلة من الأوامر، مفصول بينها بفاصلات.

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 وإنشاء تطبيقات PHP في Linux، راجع وثائق 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")

تغيير جذر الموقع

قد يستخدم إطار عمل الويب الذي تختاره دليل فرعي كجذر للموقع. على سبيل المثال، يستخدم 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).

قد يستخدم إطار عمل الويب الذي تختاره دليل فرعي كجذر للموقع. على سبيل المثال، يستخدم Laravel الدليل الفرعي public/ كجذر الموقع.

تستخدم صورة PHP الافتراضية ل App Service 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

يستبدل هذا الأمر ملف تكوين Nginx الافتراضي بملف يسمى default في جذر المستودع الخاص بك ويعيد تشغيل Nginx.

الكشف عن جلسة عمل HTTPS

في خدمة التطبيقات، يحدث إنهاء 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
}

وتتيح لك أطر عمل الويب الشائعة الوصول إلى معلومات 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, and PHP_INI_ALL (راجع توجيهات php.ini)، أضف ملف .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.

لتخصيص توجيهات PHP_INI_USER PHP_INI_PERDIR PHP_INI_ALL لتطبيقات الويب linux، مثل upload_max_filesize expose_php، استخدم ملف "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>

ثم انتقل إلى مدخل Microsoft Azure وأضف إعداد التطبيق لمسح دليل "ini" الذي أنشأته للتو لتطبيق التغيير على upload_max_filesize.

انتقل إلى مدخل Microsoft Azure وحدد تطبيق App Service Linux PHP.
حدد Application الإعدادات للتطبيق.
ضمن قسم إعدادات التطبيق، حدد + إضافة إعداد جديد.
بالنسبة إلى App Setting Name، أدخل "PHP_INI_SCAN_DIR" وللقيمة، أدخل "/home/site/wwwroot/ini".
حدد زر الحفظ.

إشعار

إذا قمت بإعادة تحويل ملحق PHP، مثل GD، فاتبع الخطوات في إعادة التحويل البرمجي لملحقات PHP في Azure App Service - إضافة ملحقات 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 في الدليل 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 (راجع توجيهات 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 مخصصاً. يمكنك فصل القيم بـ :.

انتقل إلى جلسة عمل SSH على الويب باستخدام حاوية Linux (https://<app-name>.scm.azurewebsites.net/webssh/host).

قم بإنشاء دليل في /home/site يسمى ini، ثم قم بإنشاء ملف .ini في الدليل /home/site/ini (على سبيل المثال، settings.ini) مع التوجيهات التي تريد تخصيصها. استخدم نفس بناء الجملة الذي ستستخدمه في ملف php.ini.

تلميح

في حاويات Linux المضمنة في App Service، يتم استخدام /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). تأكد من أن الملحقات متوافقة مع إصدار PHP في Azure وVC9 وغير مؤشر ترابط آمن (nts) متوافق.

قم بتوزيع تغييراتك.

اتبع الخطوات الواردة في تخصيص توجيهات PHP_INI_SYSTEM، وأضف الملحقات إلى ملف .ini المخصص مع الملحق أو توجيهات zend_extension.

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). تأكد من أن الملحقات متوافقة مع إصدار PHP في Azure وVC9 وغير مؤشر ترابط آمن (nts) متوافق.

قم بتوزيع تغييراتك.

اتبع الخطوات الواردة في تخصيص توجيهات PHP_INI_SYSTEM، وأضف الملحقات إلى ملف .ini المخصص مع الملحق أو توجيهات zend_extension.

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

لكي تسري التغييرات، أعد تشغيل التطبيق.

الوصول إلى سجلات التشخيص

استخدم الأداة المساعدة error_log() القياسية لإظهار سجلات التشخيص الخاصة بك في Azure 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 ثانية.

إشعار

يمكنك أيضا فحص ملفات السجل من المستعرض في 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> بالأسماء المناسبة لتطبيق الويب الخاص بك.

بمجرد تشغيل تسجيل الحاويات، قم بتشغيل الأمر التالي لمشاهدة تدفق السجل:

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).
- قد توزع أطر عمل ويب معينة ملفات ثابتة على نحو مختلف في وضع الإنتاج.
- ربما تستخدم أطر عمل ويب معينة برامج نصية مخصصة لبدء التشغيل عند التشغيل في وضع الإنتاج.
قم بتشغيل في 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 هو مسار عنوان URL وهمي يستخدم "خدمة التطبيقات" للتحقق من إمكانية تقديم الحاوية "طلبات". يُشير رد 404 ببساطة إلى أن المسار غير موجود، ولكنه يتيح لـ"خدمة التطبيقات" معرفة أن الحاوية سليمة وجاهزة للاستجابة للطلبات.

الخطوات التالية

البرنامج التعليمي: تطبيق PHP مع MySQL

الأسئلة الشائعة حول App Service بنظام Linux

أو راجع موارد إضافية:

متغيرات البيئة ومرجع إعدادات التطبيق

تكوين تطبيق PHP لـ Azure App Service

إظهار إصدار PHP

تعيين إصدار PHP

تشغيل Composer

تشغيل Grunt/Bower/Gulp

Bower

Gulp

Grunt

تخصيص أتمتة البناء

تخصيص بدء التشغيل

الوصول إلى متغيرات البيئة

تغيير جذر الموقع

الكشف عن جلسة عمل HTTPS

تخصيص إعدادات php.ini

تخصيص توجيهات غير PHP_INI_SYSTEM

تخصيص توجيهات PHP_INI_SYSTEM

تمكين ملحقات PHP

الوصول إلى سجلات التشخيص

استكشاف الأخطاء وإصلاحها

robots933456 في السجلات

الخطوات التالية

الموارد الإضافية