مشاركة عبر

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

التوزيع إلى Azure

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

يقوم محرك نشر خدمة التطبيقات تلقائيا بتفعيل بيئة افتراضية ويثبت التبعيات من requirements.txtملف ، pyproject.toml، أو setup.py ملف عند نشر مستودع Git أو عند نشر حزمة zipمع تفعيل أتمتة البناء.

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

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

  • مدخل Microsoft Azure. في الجزء الأيمن من التطبيق، حدد متغيرات البيئة الإعدادات> أوتكوينالإعدادات>، كما هو موضح في تكوين تطبيق App Service في مدخل Microsoft Azure.

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

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

إشعار

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

تكوين إصدار Python

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

  • Azure CLI:

    • إظهار إصدار Python الحالي باستخدام az webapp config show:

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

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

    • قم بتعيين إصدار Python باستخدام az webapp config set:

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

    • إظهار جميع إصدارات Python المدعومة في App Service باستخدام az webapp list-runtimes:

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

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

ماذا يحدث لأقات التشغيل القديمة في App Service؟

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

إذا كنت ترغب في إنشاء تطبيق بإصدار وقت تشغيل قديم لم يعد معروضا على المدخل، فاستخدم Azure CLI أو قالب ARM أو Bicep. تتيح لك بدائل التوزيع هذه إنشاء أوقات تشغيل مهملة تمت إزالتها من المدخل ولكن لا تزال مدعومة.

إذا تمت إزالة وقت التشغيل بالكامل من النظام الأساسي لخدمة التطبيقات، يتلقى مالك اشتراك Azure إشعارا بالبريد الإلكتروني قبل الإزالة.

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

إشعار

عند نشر تطبيقات Python باستخدام أتمتة الإنشاء، يتم نشر المحتوى وتقديمه من /tmp/<uid>، وليس تحت /home/site/wwwroot. يمكنك الوصول إلى دليل المحتوى هذا باستخدام APP_PATH متغير البيئة. يجب عليك كتابة أي ملفات إضافية تم إنشاؤها في وقت التشغيل إلى موقع ضمن /homeأو باستخدام إحضار التخزين الخاص بك للاستمرار. لمزيد من المعلومات حول هذا السلوك، راجع تغييرات بناء Python.

يقوم نظام إنشاء 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. تثبيت التبعيات: يقوم نظام البناء بالتحقق من الملفات التالية في جذر المشروع:

    • requirements.txt: يركض pip install -r requirements.txt.
    • pyproject.toml مع uv.lock: يستخدم uv.
    • pyproject.toml مع poetry.lock: استخدامات poetry.
    • pyproject.toml: يستخدم poetry.
    • setup.py: يركض.pip install .

    إشعار

    إذا كان pyproject.toml موجودا لكن uv.lock مفقود، فإن خدمة التطبيقات تستخدم Poetry افتراضيا، حتى لو كان poetry.lock مفقودا أيضا. لاستخدام uv، يجب أن تدرج uv.lock في نشرك.

    إذا لم يتم العثور على أي من هذه الملفات، تبلغ عملية البناء عن الخطأ "لم يتمكن من العثور على setup.py أو requirements.txt; لا أعمل على تثبيت البيب."

  3. إذا تم العثور على manage.py في جذر المستودع (الذي يشير إلى تطبيق Django)، فقم بتشغيل manage.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. يجب أن تستخدم كافة الأوامر مسارات مرتبطة بالمجلد الجذر للمشروع.

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

للحصول على معلومات حول الوصول إلى سجلات الإنشاء والنشر، راجع الوصول إلى سجلات النشر.

لمزيد من المعلومات حول كيفية تشغيل App Service وإنشاء تطبيقات 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 التي تحدث أثناء النشر. يكون true الإعداد عند النشر باستخدام Git، والأمر az webapp upAzure CLI، وVisual Studio Code.

إشعار

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

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

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

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

    • يجب أن يكون ملف الاعتماد الخاص بك (مثل requirements.txtأو pyproject.toml أو setup.py) في جوهر مستودعك إذا كنت تريد من App Service تثبيت الحزم اللازمة تلقائيا.

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

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

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

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

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

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

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

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

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

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

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

إعداد Django إرشادات عن Azure
SECRET_KEY قم بتخزين القيمة في إعداد App Service، كما هو موضح في إعدادات تطبيق Access كمتغيرات بيئة. يمكنك بدلا من ذلك تخزين القيمة كبيانات سرية في Azure Key Vault.
DEBUG قم بإنشاء DEBUG إعداد على App Service بالقيمة 0 (false)، ثم قم بتحميل القيمة كمتغير بيئة. في بيئة التطوير الخاصة بك، قم بإنشاء DEBUG متغير بيئة بالقيمة 1 (true).
ALLOWED_HOSTS في الإنتاج، يتطلب Django تضمين عنوان URL للتطبيق في ALLOWED_HOSTS صفيف settings.py. يمكنك استرداد عنوان URL هذا في وقت التشغيل باستخدام التعليمات البرمجية os.environ['WEBSITE_HOSTNAME']. حيث تقوم App Service تلقائيًّا بتعيين متغير البيئة WEBSITE_HOSTNAME إلى عنوان URL الخاص بالتطبيق.
DATABASES عرِّف الإعدادات في "App Service" للاتصال بقاعدة البيانات وتحميلها كمتغيرات البيئة لملء القاموس DATABASES. يمكنك بدلا من ذلك تخزين القيم (خاصة اسم المستخدم وكلمة المرور) كأسرار 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 مجلد الواجهة الأمامية وقام build/static Yarn بإنشاء مجلد يحتوي على ملفات ثابتة، فقم بتضمين هذا المجلد كما هو موضح هنا:

    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.

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

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

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

  • تحدد 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 ويظهر في الصورة التالية.

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

لقطة شاشة لخدمة التطبيقات الافتراضية على صفحة ويب Linux.

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

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

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

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

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

  • Azure CLI. استخدم الأمر az webapp config set مع المعلمة --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 مع التعليمات البرمجية للتطبيق. يمكنك أيضا التحقق من سجلات التشخيص لمزيد من المعلومات. ويمكنك التحقق من صفحة تشخيص المشكلات وحلها في التطبيق على مدخل Microsoft 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 that contains 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

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

في App Service، يحدث إنهاء 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.

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

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

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

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

  1. في صفحة مدخل Microsoft Azure لتطبيق الويب الخاص بك، حددمركز توزيع> في الجزء الأيمن.
  2. في علامة التبويب Logs ، حدد Commit ID لأحدث تثبيت.
  3. في صفحة تفاصيل السجل التي تظهر، حدد الارتباط إظهار السجلات الذي يظهر بجوار تشغيل إنشاء المذهب.

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

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

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

استخدم الأمر az webapp ssh .

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

اتصال SSH

إشعار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      1. قم بإنشاء إعداد تطبيق باسم SCM_DO_BUILD_DURING_DEPLOYMENT قيمة 1، وأعد توزيع التعليمات البرمجية الخاصة بك، وانتظر بضع دقائق، ثم حاول الوصول إلى التطبيق مرة أخرى. لمزيد من المعلومات حول إنشاء إعدادات التطبيق، راجع تكوين تطبيق App Service في مدخل Microsoft 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; لا أعمل على تثبيت البيب." فشلت عملية بناء Oryx في العثور على ملفrequirements.txtأو pyproject.toml أو ملف setup.py .

    • اتصل بحاوية تطبيق الويب عبر SSH وتحقق من أن ملف التبعية الخاص بك مسمى بشكل صحيح وموجود مباشرة تحت 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 Database for PostgreSQL.

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

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

مسائل أخرى

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

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

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

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

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

  • Last updated on