إدارة الوظائف

يمكنك نشر الوظائف وحذفها وتعديلها باستخدام أوامر Firebase CLI أو عن طريق تعيين خيارات وقت التشغيل في التعليمات البرمجية المصدر للوظائف.

نشر الوظائف

لنشر الوظائف ، قم بتشغيل أمر Firebase CLI:

firebase deploy --only functions

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

firebase deploy --only functions:addMessage,functions:makeUppercase

عند نشر عدد كبير من الوظائف ، قد تتجاوز الحصة القياسية وتتلقى رسائل خطأ HTTP 429 أو 500. لحل هذه المشكلة ، انشر الوظائف في مجموعات من 10 أو أقل.

راجع مرجع Firebase CLI للحصول على قائمة كاملة بالأوامر المتاحة.

بشكل افتراضي ، يبحث Firebase CLI في functions/ المجلد عن شفرة المصدر. إذا كنت تفضل ذلك ، يمكنك تنظيم الوظائف في قواعد بيانات أو مجموعات متعددة من الملفات.

حذف الوظائف

يمكنك حذف الوظائف التي تم نشرها مسبقًا بهذه الطرق:

• صراحةً في Firebase CLI مع functions:delete
• صراحةً في Google Cloud Console .
• ضمنيًا عن طريق إزالة الوظيفة من المصدر قبل النشر.

تطالبك جميع عمليات الحذف بالتأكيد قبل إزالة الوظيفة من الإنتاج.

يدعم حذف الوظيفة الصريح في Firebase CLI وسيطات متعددة بالإضافة إلى مجموعات الوظائف ، ويسمح لك بتحديد وظيفة تعمل في منطقة معينة. أيضًا ، يمكنك تجاوز مطالبة التأكيد.

# Delete all functions that match the specified name in all regions.
firebase functions:delete myFunction

# Delete a specified function running in a specific region.
firebase functions:delete myFunction --region us-east-1

# Delete more than one function
firebase functions:delete myFunction myOtherFunction

# Delete a specified functions group.
firebase functions:delete groupA

# Bypass the confirmation prompt.
firebase functions:delete myFunction --force

مع حذف الوظيفة الضمني ، firebase deploy مصدرك ويزيل أي وظائف تمت إزالتها من الملف من الإنتاج.

تعديل اسم الوظيفة أو المنطقة أو المشغل

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

إعادة تسمية دالة

لإعادة تسمية دالة ، قم بإنشاء إصدار جديد تمت إعادة تسميته من الوظيفة في المصدر الخاص بك ، ثم قم بتشغيل أمري نشر منفصلين. يقوم الأمر الأول بنشر الوظيفة المسماة حديثًا ، بينما يقوم الأمر الثاني بإزالة الإصدار الذي تم نشره مسبقًا. على سبيل المثال ، إذا كانت لديك وظيفة Node.js تسمى webhook والتي ترغب في تغييرها إلى webhookNew ، فراجع الكود كما يلي:

// before
const functions = require('firebase-functions');

exports.webhook = functions.https.onRequest((req, res) => {
    res.send("Hello");
});

// after
const functions = require('firebase-functions');

exports.webhookNew = functions.https.onRequest((req, res) => {
    res.send("Hello");
});

ثم قم بتشغيل الأوامر التالية لنشر الوظيفة الجديدة:

# Deploy new function called webhookNew
firebase deploy --only functions:webhookNew

# Wait until deployment is done; now both webhookNew and webhook are running

# Delete webhook
firebase functions:delete webhook

تغيير منطقة الوظيفة أو المناطق

إذا كنت تقوم بتغيير المناطق المحددة لوظيفة تتعامل مع حركة مرور الإنتاج ، فيمكنك منع فقدان الحدث عن طريق تنفيذ هذه الخطوات بالترتيب:

1. أعد تسمية الوظيفة ، وقم بتغيير منطقتها أو مناطقها حسب الرغبة.
2. انشر الوظيفة المعاد تسميتها ، والتي تؤدي إلى تشغيل نفس الرمز مؤقتًا في كلتا مجموعتي المناطق.
3. حذف الوظيفة السابقة.

على سبيل المثال ، إذا كانت لديك وظيفة تسمى webhook الموجودة حاليًا في منطقة الوظائف الافتراضية من us-central1 ، وتريد ترحيلها إلى asia-northeast1 ، فأنت بحاجة أولاً إلى تعديل كود المصدر لإعادة تسمية الوظيفة ومراجعة المنطقة .

// before
const functions = require('firebase-functions');

exports.webhook = functions
    .https.onRequest((req, res) => {
            res.send("Hello");
    });

// after
const functions = require('firebase-functions');

exports.webhookAsia = functions
    .region('asia-northeast1')
    .https.onRequest((req, res) => {
            res.send("Hello");
    });

ثم انشر عن طريق تشغيل:

firebase deploy --only functions:webhookAsia

الآن هناك وظيفتان متطابقتان قيد التشغيل: webhook يعمل في us-central1 ، و webhookAsia يعمل في asia-northeast1 .

ثم احذف الرد webhook :

firebase functions:delete webhook

الآن هناك وظيفة واحدة فقط - webhookAsia ، والتي تعمل في asia-northeast1 .

تغيير نوع مشغل الوظيفة

أثناء قيامك بتطوير وظائف السحابة لنشر Firebase بمرور الوقت ، قد تحتاج إلى تغيير نوع مشغل الوظيفة لأسباب مختلفة. على سبيل المثال ، قد ترغب في التغيير من نوع واحد من حدث Firebase Realtime Database أو Cloud Firestore إلى نوع آخر.

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

1. قم بتعديل شفرة المصدر لتضمين وظيفة جديدة بنوع المشغل المطلوب.
2. انشر الوظيفة ، مما يؤدي إلى تشغيل كل من الوظائف القديمة والجديدة مؤقتًا.
3. احذف الوظيفة القديمة صراحةً من الإنتاج باستخدام Firebase CLI.

على سبيل المثال ، إذا كانت لديك وظيفة Node.js تسمى objectChanged والتي تحتوي على نوع حدث onChange القديم ، وتريد تغييرها إلى onFinalize ، فأعد تسمية الوظيفة أولاً وقم بتحريرها للحصول على نوع حدث onFinalize .

// before
const functions = require('firebase-functions');

exports.objectChanged = functions.storage.object().onChange((object) => {
    return console.log('File name is: ', object.name);
});

// after
const functions = require('firebase-functions');

exports.objectFinalized = functions.storage.object().onFinalize((object) => {
    return console.log('File name is: ', object.name);
});

ثم قم بتشغيل الأوامر التالية لإنشاء الوظيفة الجديدة أولاً ، قبل حذف الوظيفة القديمة:

# Create new function objectFinalized
firebase deploy --only functions:objectFinalized

# Wait until deployment is done; now both objectChanged and objectFinalized are running

# Delete objectChanged
firebase functions:delete objectChanged

اضبط خيارات وقت التشغيل

تتيح لك وظائف السحابة لـ Firebase تحديد خيارات وقت التشغيل مثل إصدار وقت تشغيل Node.js ومهلة كل وظيفة وتخصيص الذاكرة ومثيلات الوظائف الدنيا / القصوى.

كأفضل ممارسة ، يجب تعيين هذه الخيارات (باستثناء إصدار Node.js) على كائن تكوين داخل كود الوظيفة. كائن RuntimeOptions هذا هو مصدر الحقيقة لخيارات وقت تشغيل وظيفتك ، وسيتجاوز الخيارات التي تم تعيينها عبر أي طريقة أخرى (مثل عبر وحدة تحكم Google Cloud أو gcloud CLI).

إذا كان سير عمل التطوير الخاص بك يتضمن تعيين خيارات وقت التشغيل يدويًا عبر وحدة تحكم Google Cloud أو gcloud CLI ولا تريد تجاوز هذه القيم في كل عملية نشر ، فاضبط الخيار preserveExternalChanges إلى true . مع ضبط هذا الخيار على true ، يدمج Firebase خيارات وقت التشغيل المعينة في التعليمات البرمجية الخاصة بك مع إعدادات الإصدار المنشور حاليًا من وظيفتك مع الأولوية التالية:

1. تم تعيين الخيار في كود الوظائف: تجاوز التغييرات الخارجية.
2. تم تعيين الخيار على RESET_VALUE في كود الوظائف: تجاوز التغييرات الخارجية بالقيمة الافتراضية.
3. لم يتم تعيين الخيار في كود الوظائف ، ولكن تم تعيينه في الوظيفة المنشورة حاليًا: استخدم الخيار المحدد في الوظيفة المنشورة.

لا يُنصح باستخدام الخيار preserveExternalChanges: true لمعظم السيناريوهات لأن التعليمات البرمجية الخاصة بك لن تكون مصدر الحقيقة الكامل لخيارات وقت التشغيل لوظائفك. إذا كنت تستخدمه ، فتحقق من وحدة تحكم Google Cloud أو استخدم gcloud CLI لعرض التكوين الكامل للوظيفة.

قم بتعيين إصدار Node.js

يسمح Firebase SDK للوظائف السحابية 2.0.0 والإصدارات الأحدث بمجموعة مختارة من وقت تشغيل Node.js. يمكنك اختيار تشغيل جميع الوظائف في مشروع حصريًا في بيئة وقت التشغيل المقابلة لأحد إصدارات Node.js المدعومة:

• Node.js 20 (معاينة)
• Node.js 18
• Node.js 16
• Node.js 14

لتعيين إصدار Node.js:

عيّن الإصدار في حقل engines في ملف package.json الذي تم إنشاؤه في functions/ الدليل أثناء التهيئة. على سبيل المثال ، لاستخدام الإصدار 18 فقط ، قم بتحرير هذا السطر في package.json :

  "engines": {"node": "18"}

مجال engines مطلوب ؛ يجب تحديد أحد إصدارات Node.js المدعومة حتى تتمكن من نشر الوظائف وتشغيلها.

قم بترقية وقت تشغيل Node.js الخاص بك

لترقية وقت تشغيل Node.js الخاص بك:

1. تأكد من أن مشروعك على خطة تسعير Blaze .
2. تأكد من أنك تستخدم Firebase CLI v11.18.0 أو أحدث.
3. غيّر قيمة engines في ملف package.json الذي تم إنشاؤه في مجلد functions/ الدليل أثناء التهيئة. على سبيل المثال ، إذا كنت تقوم بالترقية من الإصدار 16 إلى الإصدار 18 ، فيجب أن يبدو الإدخال كما يلي: "engines": {"node": "18"}
4. اختياريًا ، اختبر تغييراتك باستخدام Firebase Local Emulator Suite .
5. أعد نشر جميع الوظائف.

التحكم في سلوك التحجيم

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

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

قلل عدد مرات البدء الباردة

لتعيين الحد الأدنى لعدد المثيلات لدالة في التعليمات البرمجية المصدر ، استخدم التابع runWith . تقبل هذه الطريقة كائن JSON المطابق لواجهة RuntimeOptions ، التي تحدد قيمة minInstances . على سبيل المثال ، تحدد هذه الوظيفة ما لا يقل عن 5 حالات للتدفئة:

exports.getAutocompleteResponse = functions
    .runWith({
      // Keep 5 instances warm for this latency-critical function
      minInstances: 5,
    })
    .https.onCall((data, context) => {
      // Autocomplete a user's search term
    });
index.js

فيما يلي بعض الأشياء التي يجب مراعاتها عند تعيين قيمة لـ minInstances :

• إذا قامت Cloud Functions for Firebase بتوسيع نطاق تطبيقك أعلى من إعداد minInstances الخاص بك ، فسوف تواجه بداية باردة لكل مثيل أعلى من هذا الحد.
• البدايات الباردة لها التأثير الأشد على التطبيقات ذات حركة المرور المرتفعة. إذا كان تطبيقك يحتوي على حركة مرور شائكة وقمت بتعيين قيمة minInstances عالية بما يكفي لتقليل البدايات الباردة مع كل زيادة في حركة المرور ، فسترى انخفاضًا ملحوظًا في زمن الوصول. بالنسبة للتطبيقات ذات حركة المرور المستمرة ، من غير المحتمل أن تؤثر البدايات الباردة بشدة على الأداء.

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

  // Get Firebase project id from `FIREBASE_CONFIG` environment variable
  const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId;
  
  exports.renderProfilePage = functions
      .runWith({
        // Keep 5 instances warm for this latency-critical function
        // in production only. Default to 0 for test projects.
        minInstances: envProjectId === "my-production-project" ? 5 : 0,
      })
      .https.onRequest((req, res) => {
        // render some html
      });
  index.js
  

تحديد الحد الأقصى لعدد مثيلات دالة

لتعيين الحد الأقصى من المثيلات في التعليمات البرمجية المصدر للدالة ، استخدم طريقة runWith . تقبل هذه الطريقة كائن JSON المطابق لواجهة RuntimeOptions ، التي تحدد قيم maxInstances . على سبيل المثال ، تحدد هذه الوظيفة حدًا يبلغ 100 مثيل حتى لا تطغى على قاعدة بيانات قديمة افتراضية:

exports.mirrorOrdersToLegacyDatabase = functions
    .runWith({
      // Legacy database only supports 100 simultaneous connections
      maxInstances: 100,
    })
    .firestore.document("orders/{orderId}")
    .onWrite((change, context) => {
      // Connect to legacy database
    });
index.js

إذا تم رفع مستوى وظيفة HTTP إلى حد maxInstances ، يتم وضع الطلبات الجديدة في قائمة الانتظار لمدة 30 ثانية ثم يتم رفضها برمز استجابة من 429 Too Many Requests إذا لم يكن هناك مثيل متاح بحلول ذلك الوقت.

لمعرفة المزيد حول أفضل الممارسات لاستخدام الحد الأقصى من إعدادات المثيلات ، تحقق من أفضل الممارسات لاستخدام maxInstances .

تعيين المهلة وتخصيص الذاكرة

في بعض الحالات ، قد يكون لوظائفك متطلبات خاصة لقيمة مهلة طويلة أو تخصيص كبير للذاكرة. يمكنك تعيين هذه القيم إما في Google Cloud Console أو في كود مصدر الوظيفة (Firebase فقط).

لتعيين تخصيص الذاكرة والمهلة في التعليمات البرمجية المصدر للوظائف ، استخدم المعلمة runWith المقدمة في Firebase SDK للوظائف السحابية 2.0.0. يقبل خيار وقت التشغيل هذا كائن JSON المطابق لواجهة RuntimeOptions ، التي تحدد قيم timeoutSeconds memory . على سبيل المثال ، تستخدم وظيفة التخزين هذه ذاكرة بسعة 1 جيجابايت وتنتهي المهلة بعد 300 ثانية:

exports.convertLargeFile = functions
    .runWith({
      // Ensure the function has enough memory and time
      // to process large files
      timeoutSeconds: 300,
      memory: "1GB",
    })
    .storage.object()
    .onFinalize((object) => {
      // Do some complicated things that take a lot of memory and time
    });
index.js

الحد الأقصى لقيمة timeoutSeconds هو 540 ، أو 9 دقائق. يتوافق مقدار الذاكرة الممنوحة لوظيفة ما مع وحدة المعالجة المركزية المخصصة للوظيفة ، كما هو مفصل في قائمة القيم الصالحة memory هذه:

• 128MB - 200 ميجاهرتز
• 256MB - 400 ميجاهرتز
• 512MB - 800 ميجاهرتز
• 1GB - 1.4 جيجاهرتز
• 2GB - 2.4 جيجاهرتز
• 4GB - 4.8 جيجا هرتز
• 8GB - 4.8 جيجا هرتز

لتعيين تخصيص الذاكرة والمهلة في Google Cloud Console:

1. في Google Cloud Console ، حدد Cloud Functions من القائمة اليسرى.
2. حدد وظيفة من خلال النقر على اسمها في قائمة الوظائف.
3. انقر فوق أيقونة تحرير في القائمة العلوية.
4. حدد تخصيصًا للذاكرة من القائمة المنسدلة بعنوان الذاكرة المخصصة .
5. انقر فوق المزيد لعرض الخيارات المتقدمة ، وأدخل عدد الثواني في مربع نص المهلة .
6. انقر فوق حفظ لتحديث الوظيفة.