مشاركة عبر

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

التوزيع إلى Azure

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

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

إشعار

تتطلب requirements.txt App Service حاليا في الدليل الجذر لمشروعك حتى إذا كان لديك pyproject.toml. راجع إنشاء requirements.txt من pyproject.toml للنهج الموصى بها.

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

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

إشعار

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.11"

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

يقوم نظام إنشاء 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. إذا تم العثور على 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. يجب أن تستخدم كافة الأوامر المسارات النسبية للمجلد الجذر للمشروع.

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

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

لمزيد من المعلومات حول كيفية تشغيل 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).

إنشاء requirements.txt من pyproject.toml

لا تدعم pyproject.toml App Service مباشرة في الوقت الحالي. إذا كنت تستخدم أدوات مثل الشعر أو الأشعة فوق البنفسجية، فإن النهج الموصى به هو إنشاء متوافق requirements.txt قبل النشر في جذر مشروعك:

استخدام الشعر

استخدام الشعر مع المكون الإضافي للتصدير:


poetry export -f requirements.txt --output requirements.txt --without-hashes

استخدام الأشعة فوق البنفسجية

استخدام الأشعة فوق البنفسجية:


uv export --format requirements-txt --no-hashes --output-file requirements.txt

ترحيل التطبيقات الموجودة إلى 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 مكافئة. تظهر إعدادات App Service هذه للتعليمات البرمجية كمتغيرات بيئة، كما هو موضح في متغيرات بيئة Access.

  5. بدء تشغيل التطبيق: راجع قسم عملية بدء تشغيل الحاوية لاحقا في هذه المقالة لفهم كيفية محاولة App Service تشغيل تطبيقك. تستخدم 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 إرشادات عن 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 كما هو موضح في 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 ويظهر في الصورة التالية.

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

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

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

يمكنك التحكم في سلوك بدء تشغيل الحاوية عن طريق توفير أمر بدء تشغيل مخصص أو أوامر متعددة في ملف أمر بدء تشغيل. يمكن لملف أوامر بدء التشغيل استخدام أي اسم تختاره، مثل startup.shstartup.cmdstartup.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 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

في 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، حدد Monitoring>Log stream في القائمة اليمنى لتطبيقك.

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

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

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

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

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

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

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

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

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

اتصال SSH

إشعار

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

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

عند الاتصال بنجاح بجلسة عمل 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 يحتوي على اسم ملف غير صحيح أو غير موجود في المجلد الجذر للمشروع.

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

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

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

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

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

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

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

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

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

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

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

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

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

    • اتصل بحاوية تطبيق الويب عبر SSH وتحقق من تسمية requirements.txt بشكل صحيح وأنه موجود مباشرة ضمن الموقع/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 القاتل مطلوب": تحقق من أي أسماء المستخدمين وكلمات المرور المستخدمة للوصول إلى الموارد (مثل قواعد البيانات) من داخل التطبيق.

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