كيفية تشغيل WebJobs في Azure App Service

يتيح لك Azure WebJobs تشغيل المهام الخلفية في تطبيق خدمة التطبيقات الخاص بك، دون الحاجة إلى بنية تحتية منفصلة. يكتشف محرك كودو هذه المهام ويديرها. محرك Kudu هو خدمة نشر وإدارة وقت التشغيل المدمجة في خدمة التطبيقات. يعالج Kudu تنفيذ WebJob والوصول إلى نظام الملفات والتشخيصات وجمع السجلات خلف الكواليس.

تشرح هذه المقالة كيف يتم اكتشاف WebJobs، وكيف يقرر وقت التشغيل ما يجب تشغيله، وكيف يمكنك تكوين السلوك باستخدام الملف الاختياري settings.job .

ملاحظات خاصة بالنظام الأساسي

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

أنواع الملفات المدعومة للبرامج النصية أو البرامج

هام

لا يتم دعم WebJobs في حاويات Linux المخصصة المستندة إلى Alpine Linux ، بما في ذلك تطبيقات Linux التي تستخدم مكدسات وقت تشغيل Java 8 و Java 11. بدءا من تطبيقات Java 17 Linux، تستخدم Azure App Service صورا غير مستندة إلى جبال الألب، والتي تتوافق مع WebJobs.

أنواع الملفات التالية مدعومة:

  • استخدام Windows cmd: .cmd،.bat، .exe
  • استخدام PowerShell: .ps1
  • استخدام Bash: .sh
  • استخدام Node.js: .js
  • استخدام Java: .jar

أوقات التشغيل الضرورية لتشغيل أنواع الملفات هذه مثبتة بالفعل على مثيل تطبيق الويب.

هام

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

لضمان تشغيل WebJobs بشكل موثوق، فعل إعداد Always on في قسم الإعدادات في App Service.

يتوفر هذا الإعداد فقط في مستويات التسعير الأساسية والقياسية والمتميزة.

اكتشاف الوظيفة وبنية المجلد

يتم تخزين WebJobs في site/wwwroot/App_Data/jobs/ مجلد تطبيق App Service. هناك مجلدان فرعيان:

  • continuous/: للوظائف طويلة الأمد التي تبدأ تلقائيا وتشغل بشكل مستمر.
  • triggered/: للوظائف التي تعمل عند الطلب أو على جدول زمني.

كل مهمة لها مجلد فرعي خاص بها تحت النوع المقابل، المسمى باسم WebJob. على سبيل المثال:

  • App_Data/jobs/triggered/myjob/
  • App_Data/jobs/continuous/myjob/

داخل مجلد الوظائف، يبحث محرك Kudu عن ملف لتشغيله. يمكن أن يكون هذا الملف برنامج نصي أو قابل للتنفيذ.

الكشف عن نقطة الإدخال

يستخدم وقت تشغيل WebJobs ملفا يسمى run.*، مثل run.py، run.sh، أو run.js، كنقطة دخول صريحة للوظيفة. يخبر هذا الملف المنصة أي سكريبت أو ثنائي يجب تنفيذه أولا، مما يضمن سلوكا متسقا ومتوقعا عبر البيئات.

يجب أن يكون اسم الملف بالضبط run.* ليتم الكشف التلقائي. الملفات تحب start.sh أو job.py تتجاهل إلا إذا تم تفعيلها يدويا. إذا لم يتم العثور على أي run.* ملف، يحاول النظام الأساسي الكشف عن نقطة إدخال احتياطية عن طريق تحديد أول ملف مدعوم استنادا إلى النظام الأساسي للغة WebJob. على سبيل المثال:

  • وظيفة ويب بايثون تحتوي على عدة .py ملفات (على سبيل المثال، file1.py، file2.py) تشغل أول .py ملف تجده في الأرشيف.
  • يبحث Node.js WebJob عن الملف الأول .js .
  • يبحث WebJob المستند إلى Bash عن البرنامج النصي الأول .sh .

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

في WebJobs المبنية على لينكس، .sh يجب أن تتضمن السكريبتات شيبانغ (#!) ويجب أن تضع علامة على أنها قابلة للتنفيذ.

تكوين WebJob مع settings.job

يمكنك تخصيص سلوك WebJob باستخدام ملف اختياري settings.job (بتنسيق JSON) في مجلد الوظيفة الجذري. يدعم هذا الملف العديد من الخصائص:

الخاصية تنسيق وصف
schedule سلسلة تعبير CRON يستخدم لجدولة مهمة يتم تفعيلها. مثال:"0 */15 * * * *". ينطبق فقط على الوظائف التي تم تشغيلها.
is_singleton قيمة منطقية يضمن أن نسخة واحدة فقط من المهمة تعمل عبر جميع الحالات المصغرة. الافتراضي: true للوظائف المستمرة، false للمشغل/عند الطلب.
stopping_wait_time الرقم، الثواني فترة سماح (افتراضية 5 ثوان) تمنح للنص قبل أن يتوقف عند توقف WebJob، على سبيل المثال، أثناء تبديل المواقع أو إعادة تشغيله.
shutdownGraceTimeLimit الرقم، الثواني أقصى وقت (0 افتراضي، أي لا يوجد حد) يعطى لإيقاف عملية WebJob بالكامل، بما في ذلك stopping_wait_time، قبل أن يتم إنهاؤها بالقوة.
run_mode سلسلة القيم: continuous, scheduled, on_demand. يتجاوز الكشف عن نوع المهمة استنادا إلى المجلد.

إشعار

stopping_wait_time ينطبق تحديدا على فترة السماح للسكريبت الجاري التشغيل، بينما shutdownGraceTimeLimit يحدد مهلة إيقاف العملية الكلي. لمزيد من المعلومات، راجع وثائق Kudu.

مثال

{
  "schedule": "0 0 * * * *", // Run once at the top of every hour
  "is_singleton": true,
  "stopping_wait_time": 60,
  "shutdownGraceTimeLimit": 120
}

تسجيل الدخول والتشخيص

محرك Kudu يتعامل مع سجلات WebJob. هي متوفرة في App_Data/jobs/<type>/<jobname> المجلد. بالإضافة إلى ذلك، يمكن عرض السجلات في بوابة Azure أو الوصول إليها باستخدام نقطة نهاية SCM (Kudu):

https://<your-app>.scm.azurewebsites.net/api/triggeredwebjobs/<job>/history

لمزيد من قدرات المراقبة والاستعلام المتقدمة، ضع في اعتبارك التكامل مع Application Insights.

تتضمن WebJobs المشغلة تاريخا كاملا لعمليات التنفيذ. سجلات دفق WebJobs المستمرة في الوقت الفعلي.

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

  • لم يبدأ WebJob: تحقق من وجود ملف مفقود أو غير مسمى run.* . تأكد من وجودها في مجلد الوظائف الصحيح: triggered أو continuous.
  • خطأ في الأذونات (لينكس): تأكد من أن السكربت لديه صلاحيات التنفيذ (chmod +x run.sh) ويتضمن شيبانغ صالح (على سبيل المثال، #!/bin/bash).
  • المهمة لا تتوقف بأمان: استخدم settings.job لتعريف stopping_wait_time وربما shutdownGraceTimeLimit.
  • المهمة المجدولة غير قيد التشغيل: تحقق من صحة تعبير CRON في settings.job وتم تمكين "Always On" في خطة خدمة التطبيقات إذا لزم الأمر.
  • تحقق من سجلات كودو: افحص سجلات التنفيذ التفصيلية وسجلات النشر المتوفرة في وحدة Kudu (https://<your-app>.scm.azurewebsites.net/) تحت Tools>WebJobs وربما تدفق السجلات.

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

  • Last updated on