Catch up on everything we announced at this year's Firebase Summit. Learn more

إدارة نشر الوظائف وخيارات وقت التشغيل

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

نشر الوظائف

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

$ firebase deploy --only functions

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

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

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

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

افتراضيا، Firebase CLI يبدو في functions/ مجلد لرمز المصدر. يمكنك تحديد مجلد آخر عن طريق إضافة الأسطر التالية في firebase.json :

"functions": {
  "source": "another-folder"
}

حذف الوظائف

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

  • صراحة في CLI Firebase مع functions:delete
  • بشكل صريح باستخدام قائمة السياق في قائمة المهام في وحدة تحكم Firebase
  • implictly عن طريق إزالة وظيفة من index.js قبل النشر.

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

يدعم حذف الوظيفة الصريح في 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 يوزع index.js ويزيل من إنتاج أي الوظائف التي تم إزالتها من الملف.

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

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

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

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

  • التغيير من التخزين القديمة onChange الحدث ل onFinalize ، onDelete ، onArchive ، و onMetadataUpdate . (تعرف على المزيد حول هذا الموضوع في بيتا لV1 أو V2 ترقية دليل ).
  • التغيير من نوع واحد من قاعدة البيانات Firebase الحقيقي أو حدث سحابة Firestore مع بعضها البعض، مثل عام onWrite حدث إلى الحبيبية onCreate الحدث.

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

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

على سبيل المثال، إذا كان لديك وظيفة 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

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

  • Node.js 16 (تجريبي)
  • Node.js 14
  • Node.js 12
  • Node.js 10
  • نود.جي إس 8 (إهمال في 8 يونيو 2020) نشر المهام إلى نود.جي إس تم تعطيل 8 وقت التشغيل في Firebase CLI في 15 ديسمبر، و2020. تنفيذ المهام نشرت بالفعل تتوقف عند مرحلة ما في المستقبل؛ إذا قمت بنشره المهام إلى وقت نود.جي إس 8، نوصي الترقية إلى نود.جي إس 14 وقت التشغيل .

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

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

  "engines": {"node": "14"}

على engines مطلوب الميدان؛ يجب تحديد واحد من الإصدارات نود.جي إس معتمدة في لتتمكن من نشر وظائف التشغيل. حاليا firebase init functions مجموعات هذا المجال إلى 14 .

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

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

  1. تأكد من المشروع الخاص بك هو على خطة التسعير الحريق .
  2. تأكد من أنك تستخدم Firebase CLI v8.6.0 أو أحدث.
  3. تغيير engines القيمة في package.json الملف الذي تم إنشاؤه في الخاص functions/ دليل أثناء التهيئة. على سبيل المثال، إذا كنت تقوم بالترقية من الإصدار 10 إلى الإصدار 14، ينبغي للدخول تبدو مثل هذا: "engines": {"node": "14"}
  4. اختياريا، واختبار التغييرات باستخدام Firebase المحلية المحاكي جناح .
  5. أعد نشر الوظائف باستخدام Firebase CLI v8.1.0 أو إصدار أحدث.

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

بشكل افتراضي ، تعمل 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
    });

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

  • إذا الغيمة وظائف ل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
        });
    

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

إلى الحالات القصوى المنصوص عليها في التعليمات البرمجية المصدر ظيفة، استخدم 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
    });

إذا تم تحجيم وظيفة 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
    });

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

  • 128MB - 200MHZ
  • 256MB - بسرعة 400MHz
  • 512MB - 800MHz و
  • 1GB - 1.4 غيغاهرتز
  • 2GB - 2.4 غيغاهرتز
  • 4GB - 4.8 غيغاهرتز
  • 8GB - 4.8 غيغاهرتز

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

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