قم بتكوين تطبيق Linux Python لـ Azure App Service

توضح هذه المقالة كيفية تشغيل Azure App Service لتطبيقات Python، وكيف يمكنك ترحيل التطبيقات الموجودة إلى Azure، وكيف يمكنك تخصيص سلوك App Service عندما تحتاج إلى ذلك. يجب نشر تطبيقات Python مع جميع وحدات pip النمطية المطلوبة.

يقوم محرك توزيع App Service تلقائيا بتنشيط بيئة ظاهرية وتشغيله pip install -r requirements.txt لك عند نشر مستودع Git، أو عند نشر حزمة مضغوطةمع تمكين أتمتة البناء.

يوفر هذا الدليل المفاهيم الأساسية والإرشادات لمطوري Python الذين يستخدمون حاوية Linux مضمنة في خدمة التطبيقات. إذا لم يسبق لك استخدام Azure App Service، فاتبع أولا البرنامج التعليمي Python quickstart وFlask أو Django أو FastAPI مع PostgreSQL.

يمكنك استخدام إما مدخل Azure أو Azure CLI للتكوين:

• مدخل Azure، استخدم صفحة تكوين الإعدادات>الخاصة بالتطبيق كما هو موضح في تكوين تطبيق App Service في مدخل Microsoft Azure.

• Azure CLI: لديك خياران.

  • قم بتشغيل الأوامر في Azure Cloud Shell.
  • قم بتشغيل الأوامر محليًّا عن طريق تثبيت أحدث إصدار من Azure CLI، ثم تسجيل الدخول إلى Azure باستخدام تسجيل الدخول إلى az.

تكوين إصدار Python

• مدخل Microsoft Azure: استخدم علامة التبويب الإعدادات العامة في صفحة التكوين كما هو موضح في تكوين الإعدادات العامة لحاويات Linux.

• Azure CLI:

  • اعرض إصدار Python الحالي مع عرض تكوين تطبيقات الويب من az:

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

    استبدل <resource-group-name> و<app-name> بالأسماء المناسبة لتطبيق الويب الخاص بك.

  • اعرض إصدار Python الحالي مع عرض تكوين تطبيقات الويب من az

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

  • اعرض كافة إصدارات Python المدعومة في Azure App Service مع أوقات تشغيل قائمة تطبيقات ويب az:

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

يمكنك تشغيل إصدار غير مدعوم من Python عن طريق إنشاء صورة حاوية خاصة بك بدلًا من ذلك. لمزيد من المعلومات، راجع استخدام صورة Docker مخصصة.

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

يقوم نظام إنشاء App Service، المسمى Oryx، بتنفيذ الخطوات التالية عند نشر تطبيقك، إذا تم تعيين إعداد SCM_DO_BUILD_DURING_DEPLOYMENT التطبيق إلى 1:

1. قم بتشغيل برنامج نصي مخصص قبل الإنشاء، إذا تم تحديد هذه الخطوة بواسطة PRE_BUILD_COMMAND الإعداد . (يمكن للنص البرمجي نفسه تشغيل نصوص Python وNode.js الأخرى وأوامر pip وnpm والأدوات المستندة إلى Node مثل yarn، على سبيل المثال، yarn install و yarn build.)

2. شغّل pip install -r requirements.txt. يجب أن يكون الملف requirements.txt موجودًا في المجلد الجذر للمشروع. بخلاف ذلك، تبلغ عملية الإنشاء عن الخطأ: "تعذر العثور على setup.py أو requirements.txt؛ لا يتم تشغيل تثبيت pip."

3. إذا تم العثور على manager.py في جذر المستودع (للإشارة إلى تطبيق Django)، فقم بتشغيل management.py collectstatic. ومع ذلك، إذا كانت إعدادات DISABLE_COLLECTSTATIC عبارة عن true، يتم تخطي هذه الخطوة.

4. قم بتشغيل برنامج نصي مخصص لما بعد الإنشاء، إذا تم تحديد هذه الخطوة بواسطة POST_BUILD_COMMAND الإعداد . (مرة أخرى، يمكن للبرنامج النصي تشغيل نصوص Python وNode.js الأخرى وأوامر pip وnpm والأدوات المستندة إلى Node.)

بشكل افتراضي، تكون إعدادات PRE_BUILD_COMMAND وPOST_BUILD_COMMAND وDISABLE_COLLECTSTATIC فارغة.

• لتعطيل تشغيل collectstatic عند إنشاء تطبيقات Django، قم بتعيين DISABLE_COLLECTSTATIC الإعداد إلى true.

• لتشغيل أوامر ما قبل الإنشاء، قم بتعيين PRE_BUILD_COMMAND الإعداد ليحتوي إما على أمر، مثل echo Pre-build command، أو مسار إلى ملف برنامج نصي، بالنسبة إلى جذر المشروع، مثل scripts/prebuild.sh. يجب أن تستخدم كافة الأوامر المسارات النسبية للمجلد الجذر للمشروع.

• لتشغيل أوامر ما بعد الإنشاء، قم بتعيين POST_BUILD_COMMAND الإعداد ليحتوي إما على أمر، مثل echo Post-build command، أو مسار إلى ملف برنامج نصي، بالنسبة إلى جذر المشروع، مثل scripts/postbuild.sh. يجب أن تستخدم كافة الأوامر المسارات النسبية للمجلد الجذر للمشروع.

للحصول على إعدادات أخرى تقوم بتخصيص أتمتة البناء، راجع تكوين Oryx.

للوصول إلى سجلات الإصدار والنشر، راجع الوصول إلى سجلات النشر.

لمزيد من المعلومات حول كيفية تشغيل خدمة التطبيقات وإنشائها لتطبيقات Python في Linux، راجع كيف يكتشف Oryx تطبيقات Python ويبنيها.

ترحيل التطبيقات الموجودة إلى Azure

يمكن إعادة نشر تطبيقات الويب الموجودة في Azure على النحو التالي:

1. مستودع المصدر: حافظ على شفرة المصدر في مستودع مناسب مثل GitHub، مما يتيح لك إعداد النشر المستمر لاحقًا في هذه العملية.

   • يجب أن يكون ملف requirements.txt الخاص بك في جذور المستودع الخاص بك لـ App Service لتثبيت الحزم الضرورية تلقائيًّا.

2. قاعدة البيانات: إذا كان تطبيقك يعتمد على قاعدة بيانات، فبادر بإنشاء الموارد الضرورية على Azure أيضا.

3. موارد خدمة التطبيق: إنشاء مجموعة موارد وخطة App Service وتطبيق ويب App Service لاستضافة تطبيقك. يمكنك القيام بذلك بسهولة عن طريق تشغيل أمر az webapp upAzure CLI . أو يمكنك إنشاء الموارد ونشرها كما هو موضح في البرنامج التعليمي Flask أو Django أو FastAPI باستخدام PostgreSQL. استبدل أسماء مجموعة الموارد وخطة App Service وتطبيق الويب لتكون أكثر ملاءمة للتطبيق الخاص بك.

4. متغيرات البيئة: إذا كان تطبيقك يتطلب أي متغيرات بيئة، فأنشئ إعدادات تطبيق خدمة التطبيق المكافئة. تظهر إعدادات App Service هذه للتعليمات البرمجية كمتغيرات بيئة، كما هو موضح في متغيرات بيئة Access.

   • غالبا ما تتم إدارة اتصالات قاعدة البيانات، على سبيل المثال، من خلال مثل هذه الإعدادات، كما هو موضح في البرنامج التعليمي: نشر تطبيق ويب Django باستخدام PostgreSQL - تحقق من إعدادات الاتصال.
   • راجع إعدادات الإنتاج لتطبيقات Django للحصول على إعدادات محددة لتطبيقات Django النموذجية.

5. بدء تشغيل التطبيق: راجع قسم عملية بدء تشغيل الحاوية لاحقا في هذه المقالة لفهم كيفية محاولة App Service تشغيل تطبيقك. تستخدم خدمة التطبيقات خادم الويب Gunicorn افتراضيًّا، والذي يجب أن يكون قادرًا على العثور على كائن التطبيق أو مجلد wsgi.py. إذا كنت بحاجة إلى ذلك، يمكنك تخصيص أمر بدء التشغيل.

6. التوزيع المستمر: إعداد النشر المستمر من GitHub Actions أو Bitbucket أو Azure Repos كما هو موضح في المقالة التوزيع المستمر إلى Azure App Service. أو قم بإعداد النشر المستمر من Local Git كما هو موضح في المقالة Local Git deployment to Azure App Service.

7. الإجراءات المخصصة: لتنفيذ إجراءات داخل حاوية App Service التي تستضيف التطبيق الخاص بك، مثل ترحيلات قاعدة بيانات Django، يمكنك الاتصال بالحاوية من خلال SSH. للحصول على مثال لتشغيل عمليات ترحيل قاعدة بيانات Django، راجع البرنامج التعليمي: نشر تطبيق ويب Django باستخدام PostgreSQL - إنشاء مخطط قاعدة البيانات.

   • عند استخدام النشر المستمر، يمكنك تنفيذ هذه الإجراءات باستخدام الأوامر اللاحقة للإنشاء كما هو موضح سابقًا ضمن تخصيص أتمتة البناء.

مع إكمال هذه الخطوات، يجب أن تكون قادرًا على إجراء تغييرات على مستودع المصدر الخاص بك ونشر هذه التحديثات تلقائيًّا إلى App Service.

إعدادات الإنتاج لتطبيقات Django

بالنسبة لبيئة إنتاج مثل Azure App Service، يجب أن تتبع تطبيقات Django قائمة التحقق من النشر الخاصة ب Django.

يصف الجدول التالي إعدادات الإنتاج ذات الصلة بـ Azure. ويتم تعريف هذه الإعدادات في ملف setting.py الخاص بالتطبيق.

خدمة الملفات الثابتة لتطبيقات Django

إذا كان تطبيق Django على الويب يتضمن ملفات واجهة أمامية ثابتة، فاتبع أولا الإرشادات المتعلقة بإدارة الملفات الثابتة في وثائق Django.

بالنسبة لـ App Service، قم بإجراء التعديلات التالية:

1. تدبر في استخدام متغيرات البيئة (للتنمية المحلية) وإعدادات التطبيق (عند النشر إلى السحابة) لتعيين Django STATIC_URL والمتغيرات STATIC_ROOT تعيينًا ديناميكيًّا. على سبيل المثال:

   STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
   STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")    
   

   يمكن تغيير DJANGO_STATIC_URL وDJANGO_STATIC_ROOT حسب الضرورة للبيئات المحلية والسحابية. على سبيل المثال، إذا كانت عملية الإنشاء لملفاتك الثابتة تضعها في مجلد يسمى django-static، فيمكنك تعيين DJANGO_STATIC_URL إلى /django-static/ لتجنب استخدام الافتراضي.

2. وإذا كان لديك برنامج نصي سابق للنشر من شأنه إنشاء ملفات ثابتة في مجلد مختلف، فقم بتضمين هذا المجلد في متغير Django STATICFILES_DIRS بحيث يمكن لعملية Django collectstatic إيجادها. على سبيل المثال، إذا قمت بتشغيل yarn build في مجلد الواجهة الأمامية، وأنشأ yarn المجلد build/static بحيث يحتوي على ملفات ثابتة، فقم بتضمين هذا المجلد على النحو التالي:

   FRONTEND_DIR = "path-to-frontend-folder" 
   STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]    
   

   هنا، FRONTEND_DIR يتم استخدام لبناء مسار إلى حيث يتم تشغيل أداة بناء مثل yarn. ويمكنك مرة أخرى استخدام متغير البيئة وإعداد التطبيق حسب المطلوب.

3. أضف whitenoise إلى ملف requirements.txt الخاص بك. WhiteNoise (whitenoise.evans.io) هي حزمة Python التي تجعل من السهل على تطبيق Django للإنتاج خدمة ملفاته الثابتة الخاصة. يخدم WhiteNoise على وجه التحديد تلك الملفات التي تم العثور عليها في المجلد المحدد بواسطة متغير Django STATIC_ROOT .

4. في ملف settings.py، أضف السطر التالي ل WhiteNoise:

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. قم أيضا بتعديل القوائم MIDDLEWARE و INSTALLED_APPS لتضمين WhiteNoise:

   MIDDLEWARE = [                                                                   
       'django.middleware.security.SecurityMiddleware',
       # Add whitenoise middleware after the security middleware                             
       'whitenoise.middleware.WhiteNoiseMiddleware',
       # Other values follow
   ]
   
   INSTALLED_APPS = [
       "whitenoise.runserver_nostatic",
       # Other values follow
   ]
   

تقديم ملفات ثابتة لتطبيقات Flask

إذا كان تطبيق Flask على الويب يتضمن ملفات ثابتة في الواجهة الأمامية، فاتبع في البداية الإرشادات التي تخص إدارة الملفات الثابتة في وثائق Flask. للحصول على مثال لخدمة الملفات الثابتة في تطبيق Flask، راجع نموذج تطبيق Flask على GitHub.

لتقديم ملفات ثابتة مباشرة من مسار على تطبيقك، يمكنك استخدام الأسلوب send_from_directory:

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

خصائص الحاوية

عند نشرها في App Service، تعمل تطبيقات Python داخل حاوية Linux Docker المحددة في مستودع App Service Python GitHub. يمكنك العثور على تكوينات الصورة داخل الدلائل الخاصة بالإصدار.

فهذه الحاوية لها الخصائص التالية:

• يتم تشغيل التطبيقات باستخدام خادم Gunicorn WSGI HTTP، باستخدام الوسيطات --bind=0.0.0.0 --timeout 600الإضافية .

  • يمكنك توفير إعدادات التكوين لـ Gunicorn عن طريق تخصيص أمر بدء التشغيل.

  • لحماية تطبيق الويب الخاص بك من هجمات DDOS العرضية أو المتعمدة، يتم تشغيل Gunicorn خلف وكيل عكسي Nginx كما هو موضح في Deploying Gunicorn.

• وعلى نحو افتراضي، تتضمن صورة الحاوية الأساسية إطار عمل الويب الخاص بـ Flask، ولكن الحاوية تدعم أطر العمل الأخرى المتوافقة مع WSGI والمتوافقة مع Python 3.6+، مثل Django.

• لتثبيت حزم أخرى، مثل Django، قم بإنشاء ملف requirements.txt في جذر مشروعك الذي يحدد تبعياتك المباشرة. ثم تقوم App Service بتثبيت هذه التبعيات تلقائيًّا عند نشر المشروع.

  يجب أن يكون ملف requirements.txtموجودًا في جذر المشروع ليتم تثبيت التبعيات. وإلا، تبلغ عملية الإنشاء عن الخطأ: «تعذر العثور على setup.py أو requirements.txt؛ عدم تشغيل تثبيت pip.» في حال واجهت هذا الخطأ، فتحقق من موقع ملف المتطلبات.

• يحدد App Service تلقائيًّا متغير البيئة المسمى WEBSITE_HOSTNAME بعنوان URL لتطبيق الويب، مثل msdocs-hello-world.azurewebsites.net. كما أنه يعرف WEBSITE_SITE_NAMEباسم تطبيقك، مثل msdocs-hello-world.

• ويتم تثبيت npm وNode.js في الحاوية حتى تتمكن من تشغيل أدوات البناء المستندة إلى Node، مثل yarn.

عملية بدء تشغيل الحاوية

أثناء بدء التشغيل، تقوم App Service بتنفيذ الخطوات التالية على حاوية Linux:

1. استخدم أمر بدء تشغيل مخصص، إذا تم توفيره.
2. تحقق من وجود تطبيق Django، وابدأ تشغيل Gunicorn له إذا تم الكشف عن أحدها.
3. تحقق من وجود تطبيق Flask، وقم بتشغيل Gunicorn له إذا تم الكشف عن أحدها.
4. إذا لم يتم العثور على أي تطبيق آخر، فابدأ تطبيقًا افتراضيًّا مدمجًا في الحاوية.

توفر الأقسام التالية تفاصيل إضافية لكل خيار.

تطبيق Django

بالنسبة لتطبيقات Django، تبحث App Service عن ملف مسمى wsgi.py ضمن رمز التطبيق، ثم تشغل Gunicorn باستخدام الأمر التالي:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

إذا كنت تريد تحكما أكثر تحديدا في أمر بدء التشغيل، فاستخدم أمر بدء تشغيل مخصصا، واستبدل <module> باسم المجلد الذي يحتوي على wsgi.py، وأضف وسيطة --chdir إذا لم تكن هذه الوحدة النمطية في جذر المشروع. على سبيل المثال، إذا كان wsgi.py الخاص بك موجودًا ضمن knboard/backend/config من جذر المشروع الخاص بك، فاستخدم الوسيطات --chdir knboard/backend config.wsgi.

لتمكين تسجيل الإنتاج، أضف المعلمتين --access-logfile و--error-logfile كما هو موضح في الأمثلة تخصيص أوامر بدء التشغيل.

تطبيق Flask

بالنسبة إلى Flask، تبحث App Service عن ملف يسمى application.py أو app.py وتبدأ تشغيل Gunicorn كما يلي:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

إذا كانت وحدة التطبيق الرئيسية موجودة في ملف مختلف، فاستخدم اسما مختلفا لكائن التطبيق. إذا كنت تريد توفير وسيطات أخرى إلى Gunicorn، فاستخدم أمر بدء تشغيل مخصص.

السلوكْ الافتراضي

إذا لم تعثر App Service على أمر مخصص أو تطبيق Django أو تطبيق Flask، فإنها تعمل على تطبيق افتراضي للقراءة فقط، يقع في مجلد opt/defaultsite ويظهر في الصورة التالية.

وإذا قمت بنشر التعليمات البرمجية وما تزال تشاهد التطبيق الافتراضي، فراجع استكشاف الأخطاء وإصلاحها - التطبيق لا يظهر.

تخصيص أمر بدء التشغيل

يمكنك التحكم في سلوك بدء تشغيل الحاوية عن طريق توفير أمر بدء تشغيل مخصص أو أوامر متعددة في ملف أمر بدء تشغيل. ويمكن لملف أوامر بدء التشغيل استخدام أي اسم تختاره، مثل startup.sh، وstartup.cmd، وstartup.txt وهكذا.

يجب أن تستخدم كافة الأوامر المسارات النسبية للمجلد الجذر للمشروع.

لتحديد أمر بدء تشغيل أو ملف الأمر:

• بوابة Azure: حدد صفحة تكوين التطبيق، ثم حدد الإعدادات العامة. في حقل أمر بدء التشغيل، ضع إما النص الكامل لأمر بدء التشغيل أو اسم ملف أمر بدء التشغيل. حدد تكوين لتطبيق التغييرات. راجع تكوين الإعدادات العامة لحاويات Linux.

• Azure CLI: استخدام الأمر مجموعة تكوين تطبيق ويب az مع --startup-fileمعلمة لتعيين الأمر بدء التشغيل أو الملف:

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

  استبدل <custom-command> إما بالنص الكامل لأمر بدء التشغيل أو اسم ملف أمر بدء التشغيل.

فيما تتجاهل App Service أي أخطاء تحدث عند معالجة أمر أو ملف بدء تشغيل مخصص، ثم تواصل عملية بدء التشغيل من خلال البحث عن تطبيقات Django وFlask. إذا لم تشاهد السلوك الذي تتوقعه، فتحقق من أن أمر بدء التشغيل أو الملف خال من الأخطاء، ومن نشر ملف أمر بدء التشغيل إلى App Service مع رمز التطبيق الخاص بك. يمكنك أيضا التحقق من سجلات التشخيص لمزيد من المعلومات. وتحقق أيضًا من صفحة الكشف عن المشكلات وإصلاحها في التطبيق على بوابة Azure.

مثال على أوامر بدء التشغيل

• تمت إضافة وسيطات Gunicorn: يضيف المثال التالي الوسيطة --workers=4 إلى سطر أوامر Gunicorn لبدء تطبيق Django:

  # <module-path> is the relative path to the folder that contains the module
  # that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
  

  لمزيد من المعلومات، راجع تشغيل Gunicorn. إذا كنت تستخدم قواعد التحجيم التلقائي لتوسيع نطاق تطبيق الويب الخاص بك صعودا وهبوطا، يجب عليك أيضا تعيين عدد عمال Gunicorn ديناميكيا باستخدام NUM_CORES متغير البيئة في أمر بدء التشغيل الخاص بك، على سبيل المثال: --workers $((($NUM_CORES*2)+1)). لمزيد من المعلومات حول تعيين العدد الموصى به من عمال Gunicorn، راجع الأسئلة المتداولة حول Gunicorn.

• تمكين تسجيل الإنتاج لـ Django: إضافة الوسيطتين --access-logfile '-' و--error-logfile '-' إلى سطر الأوامر:

  # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'
  

  ستظهر هذه السجلات في دفق سجل App Service.

  لمزيد من المعلومات، راجع تسجيل Gunicorn.

• وحدة Flask الرئيسية المخصصة: بشكل افتراضي، تفترض App Service أن الوحدة النمطية الرئيسية لتطبيق Flask هي application.py أو app.py. إذا كانت الوحدة النمطية الرئيسية تستخدم اسمًا مختلفًا، فيجب عليك تخصيص أمر بدء التشغيل. على سبيل المثال، إذا كان لديك تطبيق Flask وحدته النمطية الرئيسية هي hello.py وكان كائن تطبيق Flask في هذا الملف يسمى myapp، فسيكون الأمر كما يلي:

  gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp
  

  إذا كانت الوحدة النمطية الرئيسية في مجلد فرعي، مثل website، حدد ذلك المجلد باستخدام الوسيطة --chdir:

  gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp
  

• استخدام ملقم غير Gunicorn: لاستخدام ملقم ويب مختلف مثل aiohttp، استخدم الأمر المناسب مثل أمر بدء التشغيل أو في ملف أمر بدء التشغيل:

  python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func
  

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

إعدادات التطبيق هي قيم مخزنة في السحابة خصيصا لتطبيقك، كما هو موضح في تكوين إعدادات التطبيق. حيث تتوفر هذه الإعدادات لرمز التطبيق كمتغيرات البيئة، ويتم الوصول إليها باستخدام نمط os.environ القياسي.

على سبيل المثال، إذا قمت بإنشاء إعداد تطبيق يسمى DATABASE_SERVER، فإن التعليمات البرمجية التالية تسترد قيمة هذا الإعداد:

db_server = os.environ['DATABASE_SERVER']

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

في خدمة التطبيقات، يحدث إنهاء TLS/SSL في موازنات تحميل الشبكة، لذلك تصل جميع طلبات HTTPS إلى تطبيقك كطلبات HTTP غير مشفرة. إذا كان منطق التطبيق الخاص بك يحتاج إلى التحقق مما إذا كانت طلبات المستخدم مشفرة أم لا، فافحص ترويسة X-Forwarded-Proto.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

وتتيح لك أطر عمل الويب الشائعة الوصول إلى معلومات X-Forwarded-* في نمط التطبيق القياسي. على سبيل المثال، في Django يمكنك استخدام SECURE_PROXY_SSL_HEADER لإخبار Django باستخدام X-Forwarded-Proto العنوان.

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

يمكنك الوصول إلى سجلات وحدة التحكم المنشأة من داخل الحاوية.

أولًا، قم بتشغيل تسجيل الحاويات عن طريق تشغيل الأمر التالي:

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.

للوصول إلى السجلات من خلال بوابة Azure، حدد مراقبة>تدفق السجل في القائمة الجانبية اليمنى لتطبيقك.

الوصول إلى سجلات التوزيع

عند نشر التعليمات البرمجية الخاصة بك، تنفذ App Service عملية البناء الموضحة سابقًا في القسم تخصيص أتمتة البناء. ونظرًا لأن البناء يعمل في الحاوية الخاصة به، يتم تخزين سجلات البناء بشكل منفصل عن سجلات التشخيص للتطبيق.

استخدم الخطوات التالية للوصول إلى سجلات التوزيع:

1. في مدخل Microsoft Azure لتطبيق الويب الخاص بك، حدد Deployment>Deployment Center في القائمة اليسرى.
2. في علامة التبويب السجلات، حدد معرّف الالتزام لآخر عملية تنفيذ.
3. في صفحة تفاصيل السجل التي تظهر، حدد الارتباط Show Logs الذي يظهر بجوار "Running oryx build...".

ستظهر مشكلات البناء مثل التبعيات غير الصحيحة في ملف requirements.txt والأخطاء في النصوص البرمجية قبل الإنشاء أو اللاحقة له في هذه السجلات. تظهر الأخطاء أيضا إذا لم تتم تسمية ملف المتطلبات requirements.txt أو لم يظهر في المجلد الجذر لمشروعك.

فتح جلسة SSH في المستعرض

لفتح جلسة SSH مباشرة مع حاويتك، يجب أن يكون تطبيقك قيد التشغيل.

الصق عنوان URL التالي في المتصفح واستبدله<app-name> باسم التطبيق:

https://<app-name>.scm.azurewebsites.net/webssh/host

إذا لم تتم مصادقتكَ بعد، يجب عليك المصادقة باستخدام اشتراك Azure للاتصال. بمجرد المصادقة، سترى shell في المستعرض، حيث يمكنك تشغيل الأوامر داخل حاويتك.

لفتح جلسة SSH بعيدة من الجهاز المحلي، راجعجلسة SSH المفتوحة من واجهة بعيدة.

عند الاتصال بنجاح بجلسة عمل SSH، يجب أن ترى الرسالة "SSH CONNECTION ESTABLISHED" في أسفل النافذة. إذا رأيت أخطاء مثل "SSH_CONNECTION_CLOSED" أو رسالة تفيد بأن الحاوية قيد إعادة التشغيل، فقد يمنع خطأ حاوية التطبيق من البدء. راجع استكشاف الأخطاء وإصلاحها للحصول على خطوات للتحقيق في المشكلات المحتملة.

إعادة كتابة عنوان URL

عند نشر تطبيقات Python على Azure App Service لنظام Linux، قد تحتاج إلى معالجة إعادة كتابة عنوان URL داخل التطبيق الخاص بك. هذا مفيد بشكل خاص لضمان إعادة توجيه أنماط محددة ل URL إلى نقاط النهاية الصحيحة دون الاعتماد على تكوينات خادم الويب الخارجي. بالنسبة لتطبيقات Flask، يمكن استخدام معالجات URL والبرامج الوسيطة المخصصة لتحقيق ذلك. في تطبيقات Django، يسمح مرسل URL القوي بإدارة فعالة لإعادة كتابة عنوان URL.

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

بشكل عام، الخطوة الأولى في استكشاف الأخطاء وإصلاحها هي استخدام تشخيصات App Service:

1. في مدخل Microsoft Azure لتطبيق الويب الخاص بك، حدد تشخيص المشكلات وحلها من القائمة اليسرى.
2. قم بتحديد التوفر والأداء.
3. افحص المعلومات الموجودة في خيارات سجلات التطبيق وتعطل الحاوية ومشكلات الحاوية، حيث ستظهر المشكلات الأكثر شيوعا.

بعد ذلك، افحص كل من سجلات النشر وسجلات التطبيق للعثور على أي رسائل خطأ. وغالبًا ما تحدد هذه السجلات مشكلات معينة يمكن أن تمنع نشر التطبيق أو بدء تشغيل التطبيق. على سبيل المثال، يمكن أن يفشل البناء إذا كان ملف requirements.txt الخاص بك يحتوي على اسم ملف خاطئ أو غير موجود في مجلد جذر المشروع.

توفر الأقسام التالية إرشادات لمشكلات معينة.

• التطبيق لا يظهر - عروض التطبيقات الافتراضية
• التطبيق لا يظهر - رسالة "الخدمة غير متوفرة"
• تعذر العثور على setup.py أو requirements.txt
• ModuleNotFoundError عند بدء التشغيل
• قاعدة البيانات مؤمَّنة
• كلمات المرور لا تظهر في جلسة عمل SSH عند كتابتها
• يبدو أن الأوامر في جلسة عمل SSH مقطوعة
• الأصول الثابتة في تطبيق Django لا تظهر
• مطلوب اتصال SSL حاسم

التطبيق لا يظهر

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

  • أعد تشغيل App Service وانتظر من 15 إلى 20 ثانية وتحقق من التطبيق مرة أخرى.

  • استخدم SSH للاتصال مباشرة بحاوية App Service والتحقق من وجود ملفاتك ضمن site/wwwroot. إذا لم تكن الملفات موجودة، فاستخدم الخطوات التالية:

    1. أنشئ إعداد تطبيقات يحمل اسم SCM_DO_BUILD_DURING_DEPLOYMENT بالقيمة 1، ثم أعد نشر التعليمات البرمجية، وانتظر بضع دقائق، ثم حاول الوصول إلى التطبيق مرة أخرى. لمزيد من المعلومات حول إنشاء إعدادات التطبيق، راجع تكوين تطبيق App Service في مدخل Azure.
    2. راجع عملية النشر، وتحقق من سجلات النشر، وصحح أي أخطاء، ثم أعد نشر التطبيق.

  • إذا كانت ملفاتك موجودة، فلن تتمكن App Service من تحديد ملف بدء التشغيل الخاص بك. تحقق من أن تطبيقك منظم كما تتوقع App Service لـ Django أو Flask، أو استخدم أمر بدء تشغيل مخصص.

• تظهر الرسالة "الخدمة غير متوفرة" في المستعرض. لقد انفدت مهلة المستعرض في انتظار استجابة من App Service، ما يشير إلى أن App Service بدأت تشغيل خادم Gunicorn، ولكن التطبيق نفسه لم يبدأ. وقد يشير هذا الشرط إلى أن وسائط Gunicorn غير صحيحة، أو أن هناك خطأ في رمز التطبيق.

  • قم بتحديث المتصفح، خاصة إذا كنت تستخدم أدنى مستويات التسعير في خطة App Service. قد يستغرق بدء تشغيل التطبيق وقتا أطول عند استخدام المستويات المجانية، على سبيل المثال، ويصبح مستجيبا بعد تحديث المستعرض.

  • تحقق من أن تطبيقك منظم كما تتوقع App Service لـ Django أو Flask، أو استخدم أمر بدء تشغيل مخصص.

  • افحص دفق سجل التطبيق للعثور على أي رسائل خطأ. ستظهر السجلات أي أخطاء في رمز التطبيق.

تعذر العثور على setup.py أو requirements.txt

• يظهر دفق السجل "تعذر العثور على setup.py أو requirements.txt؛ عدم تشغيل تثبيت pip.": فشلت عملية بناء Oryx في العثور على ملف requirements.txt.

  • اتصل بحاوية تطبيق الويب عبر SSH وتحقق من أن requirements.txt تم تسميته بشكل صحيح وأنه موجود مباشرة ضمن site/wwwroot. إذا لم يكن موجودا، فتأكد من وجود الملف في المستودع الخاص بك ومن تضمينه في النشر الخاص بك. إذا كان موجودًا في مجلد منفصل، انقله إلى الجذر.

ModuleNotFoundError عند بدء تشغيل التطبيق

إذا رأيت خطأ مثل ModuleNotFoundError: No module named 'example'، فلن تتمكن Python من العثور على وحدة نمطية واحدة أو أكثر عند بدء تشغيل التطبيق. يحدث هذا الخطأ في معظم الأحيان إذا قمت بنشر البيئة الظاهرية الخاصة بك مع التعليمات البرمجية الخاصة بك. البيئات الظاهرية ليست قابلة للنقل، لذلك لا ينبغي نشر بيئة ظاهرية مع التعليمات البرمجية للتطبيق الخاص بك. بدلًا من ذلك، دع Oryx تنشئ بيئة ظاهرية وتثبت الحزم على تطبيق الويب من خلال إنشاء إعدادات تطبيق، وSCM_DO_BUILD_DURING_DEPLOYMENT، وإعداده إلى 1. سيفرض هذا الإعداد على Oryx تثبيت الحزم الخاصة بك كلما قمت بالنشر إلى App Service. لمزيد من المعلومات، راجع هذه المقالة حول إمكانية نقل البيئة الظاهرية.

قاعدة البيانات مؤمنة

عند محاولة تشغيل عمليات ترحيل قاعدة البيانات باستخدام تطبيق Django، قد ترى "sqlite3. OperationalError: قاعدة البيانات مؤمنة." يشير الخطأ إلى أن التطبيق الخاص بك يستخدم قاعدة بيانات SQLite، والتي تم تكوين Django لها بشكل افتراضي، بدلا من استخدام قاعدة بيانات سحابية مثل قاعدة بيانات Azure ل PostgreSQL.

تحقق من المتغير DATABASES في ملف settings.py للتطبيق للتأكد من أن تطبيقك يستخدم قاعدة بيانات سحابية بدلًا من SQLite.

إذا كنت تواجه هذا الخطأ مع النموذج في البرنامج التعليمي: نشر تطبيق ويب Django باستخدام PostgreSQL، فتحقق من إكمال الخطوات في التحقق من إعدادات الاتصال.

مسائل أخرى

• لا تظهر كلمات المرور في جلسة SSH عند كتابتها: لأسباب تتعلق بالأمان، تحافظ جلسة SSH على إخفاء كلمة المرور عند الكتابة. ومع ذلك، يتم تسجيل الأحرف، لذا اكتب كلمة المرور كالمعتاد وحدد Enter عند الانتهاء.

• يبدو أن الأوامر في جلسة SSH مقتطعة: قد لا يكون المحرر أوامر التفاف الكلمات، ولكن يجب أن يستمر تشغيلها بشكل صحيح.

• لا تظهر الأصول الثابتة في تطبيق Django: تأكد من تمكين الوحدة النمطية WhiteNoise.

• ترى الرسالة، "مطلوب اتصال SSL حاسم": تحقق من أي أسماء مستخدمين وكلمات مرور مستخدمة للوصول إلى الموارد (مثل قواعد البيانات) من داخل التطبيق.

المحتوى ذو الصلة

• البرنامج التعليمي: تطبيق Flask مع PostgreSQL
• البرنامج التعليمي: تطبيق Django مع PostgreSQL
• البرنامج التعليمي: تطبيق FastAPI مع PostgreSQL
• البرنامج التعليمي: النشر من مستودع حاوياتك
• الأسئلة المتداولة App Service على Linux
• متغيرات البيئة ومرجع إعدادات التطبيق