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


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

نشر الوظائف

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

firebase deploy --only functions

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

# 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 .

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

أثناء قيامك بتطوير Cloud Functions لنشر 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

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

تتيح لك Cloud Functions for Firebase تحديد خيارات وقت التشغيل مثل إصدار وقت تشغيل Node.js والمهلة لكل وظيفة، وتخصيص الذاكرة، والحد الأدنى/الحد الأقصى لمثيلات الوظائف.

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

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

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

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

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

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

  • Node.js 20 (معاينة)
  • نود.جي إس 18
  • نود.جي إس 16
  • نود.جي إس 14

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

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

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

إذا كنت تستخدم مدير حزم Yarn أو لديك متطلبات محددة أخرى في مجال engines ، فيمكنك تعيين وقت التشغيل لـ Firebase SDK للوظائف السحابية في firebase.json بدلاً من ذلك:

  {
    "functions": {
      "runtime": "nodejs18" // or nodejs14, nodejs16 or nodejs20
    }
  }

تستخدم واجهة سطر الأوامر القيمة المحددة في firebase.json بدلاً من أي قيمة أو نطاق تقوم بتعيينه بشكل منفصل في package.json .

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

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

  1. تأكد من أن مشروعك مدرج في خطة تسعير Blaze .
  2. تأكد من أنك تستخدم الإصدار 11.18.0 من Firebase CLI أو الإصدارات الأحدث.
  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 لـ Cloud Functions 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 Google Cloud Console، حدد Cloud Functions من القائمة اليسرى.
  2. حدد وظيفة من خلال النقر على اسمها في قائمة الوظائف.
  3. انقر على أيقونة التحرير في القائمة العلوية.
  4. حدد تخصيص الذاكرة من القائمة المنسدلة المسماة الذاكرة المخصصة .
  5. انقر فوق المزيد لعرض الخيارات المتقدمة، وأدخل عدد الثواني في مربع النص Timeout .
  6. انقر فوق حفظ لتحديث الوظيفة.