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

  • مقالة

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

يقوم محرك نشر خدمة التطبيقات تلقائيًا بتنشيط بيئة افتراضية ويُجريpip install -r requirements.txt لك التشغيل عندما توزّعGit repository,أو zip packageمن خلال تمكين بنية التشغيل التلقائي.

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

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

إشعار

Linux هو خيار نظام التشغيل الوحيد لتشغيل تطبيقات Python في App Service. لم يعد Python على Windows مدعومًا. ومع ذلك، يمكنك إنشاء صورة حاوية Windows المخصصة الخاصة بك وتشغيلها في App Service. لمزيد من المعلومات، راجع استخدام صورة Docker مخصصة.

تكوين إصدار 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 ويبنيها.

إشعار

إن إعدادات PRE_BUILD_SCRIPT_PATH وPOST_BUILD_SCRIPT_PATH متطابقة مع PRE_BUILD_COMMAND وPOST_BUILD_COMMAND وهي مدعومة للأغراض القديمة.

يؤدي الإعداد المسمى SCM_DO_BUILD_DURING_DEPLOYMENT، إذا كان يحتوي على true أو 1، إلى تشغيل إصدار Oryx أثناء النشر. يكون الإعداد صحيحًا عند النشر باستخدام git وأمر Azure CLI az webapp up وVisual Studio Code.

إشعار

استخدم دائمًا المسارات النسبية في جميع البرامج النصية قبل الإنشاء وبعده لأن حاوية الإنشاء التي يتم تشغيل Oryx فيها تختلف عن حاوية وقت التشغيل التي يتم تشغيل التطبيق فيها. لا تعتمد أبدًا على الموضع الدقيق لمجلد مشروع تطبيقك داخل الحاوية (على سبيل المثال، وضعه ضمن site/wwwroot).

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

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

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

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

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

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

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

  5. بدء تشغيل التطبيق: راجع القسم، عملية بدء تشغيل الحاوية لاحقًا في هذه المقالة لفهم كيف تحاول خدمة التطبيقات تشغيل تطبيقك. تستخدم خدمة التطبيقات خادم الويب 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 (djangoproject.com).

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

إعداد Django إرشادات عن Azure
SECRET_KEY خزِّن القيمة في إعداد "App Service" على النحو الموضح في إعدادات تطبيق Access كمتغيرات البيئة. يمكنك بدلًا من ذلك تخزين القيمة كـ "سر" في Azure Key Vault.
DEBUG أنشئ إعداد DEBUG في خدمة التطبيقات بالقيمة 0 (خطأ)، ثم قم بتحميل القيمة كمتغير بيئة. في بيئة التطوير لديك، أنشئ متغير البيئة DEBUG مع القيمة 1 (صحيح).
ALLOWED_HOSTS في الإنتاج، يتطلب Django تضمين عنوان URL للتطبيق في مجموعة ALLOWED_HOSTS الخاصة بـ settings.py. يمكنك استرداد عنوان URL هذا في وقت التشغيل باستخدام التعليمات البرمجية os.environ['WEBSITE_HOSTNAME']. حيث تقوم App Service تلقائيًّا بتعيين متغير البيئة WEBSITE_HOSTNAME إلى عنوان URL الخاص بالتطبيق.
DATABASES عرِّف الإعدادات في "App Service" للاتصال بقاعدة البيانات وتحميلها كمتغيرات البيئة لملء القاموس DATABASES. ويمكنك تخزين القيم بالتناوب (وخاصة اسم المستخدم وكلمة المرور) كأسرار Azure Key Vault.

خدمة الملفات الثابتة لتطبيقات 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 كما هو موضح في نشر Gunicorn (docs.gunicorn.org).

  • وعلى نحو افتراضي، تتضمن صورة الحاوية الأساسية إطار عمل الويب الخاص بـ 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 ويظهر في الصورة التالية.

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

Screenshot of the default App Service on Linux web page.

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

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

يمكنك التحكم في سلوك بدء تشغيل الحاوية عن طريق توفير أمر بدء تشغيل مخصص أو أوامر متعددة في ملف أمر بدء تشغيل. ويمكن لملف أوامر بدء التشغيل استخدام أي اسم تختاره، مثل 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 (docs.gunicorn.org). إذا كنت تستخدم قواعد التحجيم التلقائي لتوسيع نطاق تطبيق الويب الخاص بك صعودا وهبوطا، يجب عليك أيضا تعيين عدد عمال 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 (docs.gunicorn.org).

  • وحدة 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 (wikipedia.org) عند موازنات تحميل الشبكة، لذا تصل جميع طلبات 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. في صفحة تفاصيل السجل التي تظهر، حدد رابط إظهار السجلات... الذي يظهر بجوار "تشغيل إنشاء oryx...".

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

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

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

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

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

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

SSH connection

إشعار

تخزن أي تغييرات تقوم بها خارج الدليل /home في الحاوية نفسها ولا تستمر بعد إعادة تشغيل التطبيق.

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

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

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

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

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

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

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

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

  • يمكنك مشاهدة التطبيق الافتراضي بعد نشر رمز التطبيق الخاص بك. يظهر التطبيق الافتراضي لأنك إما لم تنشر رمز التطبيق إلى خدمة التطبيقات، أو فشلت 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 لها بشكل افتراضي بدلا من استخدام قاعدة بيانات سحابية مثل PostgreSQL ل Azure.

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

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

مسائل أخرى

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

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

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

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

موارد إضافية