تم إيقاف خدمة "إضافات Firebase" نهائيًا، وسيتم إيقافها في 31 مارس 2027. مع أنّ الإضافات المثبَّتة ستستمر في العمل إلى أجل غير مسمى، لن تكون ميزات إدارة المفاتيح متاحة بعد هذا التاريخ. سيتم إصدار المزيد من الإرشادات والأدوات المتعلقة بنقل البيانات في سبتمبر 2026.
نظرة عامة حول الإيقاف النهائي
لماذا سنوقف نهائيًا Firebase Extensions؟
بسبب التغييرات وعمليات الإيقاف النهائي القادمة في البنية الأساسية Google Cloud، سنوقف نهائيًا خدمة Firebase Extensions المُدارة.
هل ستتوقّف الإضافات الحالية التي تم نشرها عن العمل بعد 31 مارس 2027؟
لا، يتم تشغيل الإضافات التي تم نشرها مباشرةً على البنية الأساسية العادية Google Cloud (مثل Cloud Functions وEventarc وCloud Run وCloud Tasks) وستستمر في التنفيذ إلى أجل غير مسمى.
ومع ذلك، بعد 31 مارس 2027، لن تتمكّن من تعديل هذه الإضافات أو إعادة ضبطها أو إلغاء تثبيتها من خلال وحدة تحكّم Firebase أو واجهة سطر الأوامر. وستفقد أيضًا القدرة على تنزيل إعدادات الإضافة الحالية للمساعدة في نقلها إلى حزمة دوال. ننصحك بشدة بنقل إعدادات الإضافة أو تصديرها بحلول 31 آذار (مارس) 2027.
ماذا يحدث إذا لم يتّخذ المستخدم أي إجراء؟
في حال عدم اتّخاذ المستخدم أي إجراء، ستستمر الدوال الحالية التي تم نشرها في العمل كأصول عادية. بعد 31 مارس 2027:
- لا يمكنهم تغيير مَعلمات الإعداد أو تعديل متغيّرات البيئة.
- ولا يمكنهم تطبيق إصلاحات الأخطاء أو رموز تصحيح الأمان أو ترقيات التبعية.
- لا يمكنهم تنزيل إعدادات الإضافة للمساعدة في إعداد مجموعة وظائف بديلة بشكل مطابق.
- يتم حاليًا إنشاء معظم الإضافات باستخدام الإصدار القديم Cloud Functions من حزمة تطوير البرامج (SDK)، والذي يرتبط بأوقات تشغيل Node.js القديمة. بعد أن توقف Google Cloud نهائيًا عن توفير بيئات التشغيل القديمة هذه، قد تتوقف الدوال عن العمل أو يتم إيقافها. اطّلِع على دعم وقت التشغيل.
هل هناك أي بديل لـ "إضافات Firebase"؟
أضفنا العديد من الميزات إلى Cloud Functions لجعلها قادرة على استبدال الإضافات. أبرزها حِزم الدوال التي يمكن توزيعها باستخدام npm وتتيح لك نشر عدة مثيلات من الدوال، على غرار الطريقة التي يمكنك بها تثبيت الإضافات عدة مرات في مشروع واحد.
ومع ذلك، يعود إلى كل ناشر إضافة تحديد ما إذا كان يريد نشر بديل رسمي لمجموعة الدوال على npm. بما أنّ الإضافات مفتوحة المصدر، إذا لم يرِد الناشر توفير بديل رسمي، يمكن لأي مطوّر إنشاء نسخة معدَّلة غير رسمية باستخدام Cloud Functions من خلال الجيل الثاني من واجهات برمجة التطبيقات في حزمة تطوير البرامج (SDK) الخاصة بـ Node.
على الناشرين الذين يريدون إجراء عملية استبدال اتّباع التعليمات الواردة في دليل نقل البيانات للناشرين.
يمكن للمستخدمين الذين يريدون الاستفادة من حِزم الاستبدال الرسمية أو إنشاء حِزم استبدال خاصة بهم اتّباع التعليمات الواردة في دليل نقل البيانات للمستخدمين.
ماذا يجب أن أفعل كمستخدم للإضافة؟
إذا كنت تستخدم الإضافات ولم تعُد تستخدم الإضافات المثبَّتة، عليك إلغاء تثبيتها قبل 31 آذار (مارس) 2027.
بعد إيقاف الخدمة، ستتم إزالة زر "إلغاء التثبيت" في وحدة تحكّم Firebase وأوامر واجهة سطر الأوامر ذات الصلة. يجب حذف جميع موارد Google Cloud المرتبطة يدويًا، بما في ذلك Cloud Functions وSecret Manager وCloud Tasks وقوائم الانتظار وحسابات خدمة إدارة الهوية وإمكانية الوصول (IAM) المخصّصة، وذلك باستخدام وحدة تحكّم Google Cloud.
ومع ذلك، إذا كنت تستخدم الإضافات المثبَّتة بشكل نشط، ننصحك بشدة بنقلها إلى حِزم الدوال. للانتقال إلى حِزم الدوال، اتّبِع التعليمات الواردة في دليل نقل البيانات للمستخدمين.
يمكنك اختيار عدم نقل البيانات إلى حِزم الدوال، وفي هذه الحالة، ننصحك بشدة بتحديث جميع إضافاتك إلى أحدث إصداراتها، والحفاظ على تحديثها، وتصدير إعدادات الإضافات الحالية في حال أردت نقل البيانات لاحقًا.
ما هي الإجراءات التي يجب اتّخاذها بصفتي ناشر إضافة؟
ننصحك بنقل إضافاتك المنشورة إلى حِزم وظائف منشورة على npm. يمكنك البدء بنقل الإضافة إلى الجيل الثاني من الدوال، وهو شرط أساسي لإنشاء حزمة دوال. يتضمّن ذلك تجميع منطق الإضافة باستخدام الإصدار 2 من حزمة تطوير البرامج (SDK) الخاصة بـ Cloud Functions. عدّلنا حزمة تطوير البرامج (SDK) Cloud Functions الإصدار 2 لتتوافق مع ميزات مثل الأمان التعريفي وأحداث مراحل النشاط. يمكنك الآن نقل رمز الإضافة الحالي إلى دالة من الجيل الثاني مع إجراء الحد الأدنى من التغييرات على منطق نشاطك التجاري الأساسي. يمكن نشر هذه الدوال باستخدام حزمة npm. لمزيد من التفاصيل، يُرجى الاطّلاع على دليل نقل البيانات الخاص بالناشرين.
ماذا لو كان لديّ أسئلة أخرى؟
يمكن للمستخدمين الذين لديهم أسئلة الاستعانة بدليل نقل بيانات المستخدمين. إذا كانت لديك أسئلة أخرى بعد استخدام الدليل، يمكنك التواصل مع فريق دعم Firebase.
يمكن للناشرين الذين لديهم أسئلة حول كيفية نقل البيانات Firebase Extensions الاستعانة بدليل نقل البيانات للناشرين. يتضمّن هذا الدليل تعليمات حول كيفية البقاء على اطّلاع على التحديثات والحصول على مساعدة في تقديم بديل لإضافاتك المنشورة.
خيارات نقل البيانات والتنفيذ الفني
ما هي مسارات نقل البيانات الأساسية المتاحة؟
اعتبارًا من سبتمبر 2026، سيتيح Firebase مسارَي نقل بيانات أساسيَّين:
- النقل إلى دالة مشترَكة في NPM ("مجموعة الدوال"): يُنصح بهذا الخيار لنقل بيانات Firestore إلى BigQuery وأي مجموعات دوال أخرى تصبح متاحة على npm. يتم تجميع المنطق الأساسي في مكتبة NPM عادية باستخدام الإصدار 2 من حزمة تطوير البرامج (SDK) الخاصة بـ Cloud Functions. يبدأ المستخدمون بإنشاء قاعدة رموز برمجية Cloud Functions عادية، ثم يثبّتون الحزمة ويعيدون تصدير الدوال، وينشرونها بشكل مستقل باستخدام واجهة سطر الأوامر.
- Fork and Self-Manage: يُنصح باستخدام هذا الخيار لجميع الإضافات التي لا تتضمّن حزمة وظائف متاحة على npm. ينسخ المستخدمون رمز المصدر للإضافة المفتوحة المصدر أو ينشئون نسخة منه، ثم يعيدون تصميم المشغّلات في Firebase الإصدار 2 القياسي باستخدام مهارات نقل البيانات المستندة إلى الذكاء الاصطناعي أو الأدلة اليدوية، ويتولّون ملكية قاعدة الرموز وصيانتها المستمرة بشكل كامل.
ما هي الإضافات التي سيتم نقلها إلى مجموعات الوظائف؟
تم نقل إضافة نقل بيانات Firestore إلى BigQuery إلى حزمة دوال متاحة كحزمة npm @firebase-function-kits/firestore-bigquery-export.
لماذا تتطلّب عملية نقل البيانات الترقية من الإصدار 1 من Cloud Functions إلى الإصدار 2؟
ينتهي الدعم العادي للإصدار 1 من Cloud Functions مع وقت تشغيل Node.js 22. لتجنُّب حدوث "عملية نقل مزدوجة"، حيث ينقل المطوّرون وظائفهم من Firebase Extensions ثم يُضطرون إلى إجراء عملية إعادة تصميم يدوية ثانية عند إيقاف بيئات التشغيل القديمة نهائيًا، تنصح Firebase بشدة بترقية جميع الوظائف التي تم نقلها إلى حزمة SDK الإصدار 2 على الفور أثناء عملية النقل هذه، وهي خطوة مطلوبة لحِزم الوظائف.
بصفتك مستخدمًا لـ "إضافات Firebase"، يمكنك أيضًا إنشاء حِزم الدوال الخاصة بك باستخدام دليل نقل البيانات للمستخدمين.
الفوترة والأسعار
هل سيؤدي الانتقال إلى Cloud Functions المُدارة ذاتيًا إلى تغيير في فوترة العميل؟
بشكل عام، لا، لأنّ الإضافات التي تم نشرها تفرض رسومًا على العملاء مقابل Google Cloud الموارد الأساسية التي يستهلكونها، مثل عمليات استدعاء Cloud Functions أو Cloud Storage أو مساحة التخزين والاستعلامات BigQuery. ومع ذلك، خلال فترة النقل، قد يتحمّل العملاء تكلفة إضافية صغيرة ومؤقتة إذا كانوا يشغّلون كلاً من Firebase Extensions القديم والوظيفة البديلة التي تم نشرها حديثًا بالتوازي لضمان عملية نقل آمنة.
كيف تتم معالجة الفوترة لحسابات Mandiant أو حسابات المؤسسات المتخصّصة الأخرى؟
هذا الإيقاف النهائي هو تغيير على مستوى المنصة ويؤثر في جميع المشاريع التي تستخدم Firebase وGoogle Cloud. لن تتأثر ترتيبات الفوترة والاشتراك العادية. إذا طلب العملاء الحصول على أرصدة بموجب اتفاقية مستوى الخدمة بسبب فترة توقّف الخدمة نتيجة إيقافها نهائيًا أو واجهوا استثناءات معقّدة في الفوترة، يجب تصعيد الطلب مباشرةً من خلال قنوات دعم الفوترة العادية.
تحديد المشاكل وحلّها والحدّ من المخاطر
ما هي مخاطر فقدان البيانات أو توقّف الخدمة أثناء عملية نقل البيانات؟
يؤدي نقل الموارد المُدارة إلى قواعد بيانات ذاتية الإدارة إلى خطر بسيط من انقطاع الخدمة أو فقدان الأحداث.
- تعطُّل المشغّلات: إذا تم حذف المشغّلات القديمة قبل تفعيل المشغّلات الجديدة، ستحدث فجوة يتم فيها فقدان الأحداث (مثل عمليات كتابة المستندات Cloud Firestore) بشكل دائم. ننصحك بتفعيل الحزمة البديلة والتحقّق من صحتها قبل إزالة الإضافة لتجنُّب فقدان أي بيانات.
- فجوات الأذونات: إذا كانت قاعدة الرموز البرمجية التي تم تفعيلها حديثًا تفتقر إلى أذونات إدارة الهوية وإمكانية الوصول (IAM) اللازمة، ستتعذّر العمليات، مثل الكتابة إلى BigQuery، بدون إظهار أي رسالة خطأ أو ستتوقف عن العمل أثناء وقت التشغيل. لقد أضفنا ميزة الأمان التعريفية للوظائف، لذا فإنّ عملية نشر المجموعة الأولى التي يجريها حساب يمكنه طلب الأدوار وتحديدها وإنشاء حساب خدمة من المفترض أن تحدّ من هذه المشكلة.
كيف يمكننا منع فقدان البيانات في إضافة التصدير من Cloud Firestore إلى BigQuery المهمة؟
لتحقيق انتقال آمن بدون فقدان أي بيانات، يجب أن ينصح فريق الدعم المستخدمين باتّباع عملية نقل مستندة إلى التداخل بدلاً من عملية مستندة إلى الفجوات. هذا هو الإعداد التلقائي عند نقل البيانات إلى حِزم:
- انشر حزمة وظائف الاستبدال بينما لا تزال الإضافة مثبّتة وقيد التشغيل. انتظِر بضع دقائق حتى يتم توفير Eventarc بالكامل.
- اكتب مستندًا تجريبيًا إلى مجموعة Cloud Firestore التي تتم مراقبتها وتأكَّد من أنّ الدالة الجديدة المُدارة ذاتيًا تكتب صفًا مطابقًا بنجاح في جدول سجلّ التغيير BigQuery (الذي يتضمّن معرّف حدث جديدًا).
- بعد التأكّد من أنّ عملية النشر الجديدة تعمل بشكل سليم، ألغِ تثبيت الإضافة القديمة أو أوقِفها على الفور لإنهاء سلوك الكتابة المزدوجة.
- احرص على أن تكون فترة التداخل قصيرة قدر الإمكان للحدّ من تكلفة المعالجة المكرّرة لكل عملية كتابة واحتمالية تكرار الصفوف في سجلّ التغيير BigQuery الأولي.
- في معظم الحالات، سيزيل جدول سجلّ التغيير الأوّلي (
*_raw_changelog) التكرار حسبinsertID، وحتى في الحالات التي تحصل فيها على صفوف مكرّرة في سجلّ التغيير، ستكون أحدث طريقة عرض للجدول (*_raw_latest) صحيحة.
يمكنك الاطّلاع على مزيد من المعلومات حول نقل هذه الإضافة تحديدًا وكيفية استرداد أي بيانات مفقودة في ملف README.md الخاص بالحزمة.
ماذا أفعل إذا تعذّر تنفيذ خطوة توفير دورة الحياة؟
في إطار الخدمة المُدارة، تم التعامل تلقائيًا مع مهام الإعداد (مثل إنشاء BigQueryمجموعات البيانات والجداول وطرق العرض). في نموذج NPM المُدار ذاتيًا، يتم تشغيل هذه الإجراءات باستخدام دالة قائمة انتظار مهام دورة الحياة، مثلاً، في firestore-bigquery-export، يُطلق على هذه الدالة اسم initBigQuerySync.
في حال تعذُّر تنفيذ هذه الخطوة أو عدم تنفيذها تلقائيًا، اتّبِع الخطوات التالية:
تأكَّد من منح حساب خدمة وقت التشغيل Cloud Functions أدوار إدارة الهوية وإمكانية الوصول (IAM) المطلوبة. على سبيل المثال، بالنسبة إلى
firestore-bigquery-export، يشمل ذلك ما يلي:- لإنشاء المراجع وإدراج الصفوف:
roles/bigquery.dataEditor - لتشغيل المهام وإنشاء طرق العرض:
roles/bigquery.user - لإضافة مهمة التوفير إلى قائمة الانتظار، اتّبِع الخطوات التالية:
roles/cloudtasks.enqueuer
- لإنشاء المراجع وإدراج الصفوف:
تأكَّد من أنّ المتصل لديه أذونات
roles/cloudtasks.enqueuer.أعِد تشغيل أمر تهيئة مراحل النشاط يدويًا باستخدام واجهة سطر الأوامر:
firebase functions:lifecycle:run afterInstall KIT_INSTANCE_IDراجِع سجلّات Cloud Logging لكلّ من دالة المشغّل وتنفيذ قائمة انتظار المهام لتشخيص أي أخطاء في الأذونات أو الإعدادات.
كيف يتم نقل بيانات اعتماد Secret Manager؟
في النموذج المُدار، تم ربط موارد Secret Manager تلقائيًا بنسخ الإضافة. عند استخدام الأمرَين ext:migrate أو ext:export
--mode functions لتصدير إعدادات الإضافات إلى حزمة وظائف، نتوقف عن السماح للإضافات بإدارة هذه الأسرار حتى تبقى في مشروعك بعد إلغاء تثبيت الإضافة. إذا أردت إزالة هذه الأسرار في المستقبل، عليك إجراء ذلك يدويًا في وحدة تحكّم Google Cloud.
ماذا لو أراد المستخدم تشغيل عدة مثيلات من إضافة تم نقل بياناتها؟
لقد طرحنا حِزم الدوال كوسيلة لإتاحة مثيلات متعددة لدالة ما، على غرار إمكانية توفير إصدارات متعددة من إضافة. سيحصل كل حزمة على معرّف فريد لمثيل الحزمة، وهو مشابه لقاعدة الرموز البرمجية ويمكن استخدامه بالتبادل مع قواعد الرموز البرمجية في أوامر واجهة سطر الأوامر. عند نشر جميع الدوال في نسخة من الحزمة، سيتم إضافة البادئة kit-<instance-id>- إلى جميع الدوال لضمان أن يكون لكل دالة اسم فريد، على غرار البادئة ext-<extension-instance-id>- في الإضافات. لمزيد من المعلومات حول كيفية استخدام حِزم الدوال البرمجية كجزء من عملية نقل البيانات، يمكنك الاطّلاع على دليل نقل بيانات المستخدمين.
يتم تثبيت الحزمة باستخدام npm. ماذا لو أردت استخدام Yarn أو أداة أخرى لإدارة الحِزم متوافقة مع Node؟
ليس لدينا حاليًا خطط لإتاحة Yarn أو أدوات إدارة الحِزم الأخرى. تعمل عملية تثبيت الحزمة من خلال تنفيذ أوامر npm مباشرةً عند إعداد رمز مصدر الحزمة عند التثبيت لأول مرة.
كحلّ بديل، يمكنك إنشاء دليل مصدر وتثبيت حزمة npm الخاصة بالأداة بنفسك وإعدادها باستخدام عمليات الإنشاء وعمليات التصدير المناسبة. يمكنك الرجوع إلى نماذج index-kit TypeScript في firebase-tools أو الاطّلاع على حزمة مثبَّتة من npm كمثال. بعد ذلك، يمكنك تثبيته مثل حزمة محلية باستخدام --directory بدلاً من --package. من الآن فصاعدًا،
عليك تحديد الحزمة حسب الدليل أو المعرّف، ولكن يمكنك استخدام أوامر الحزمة
لإضافة مثيلات وإزالتها.
تستخدم الإضافة مستودع Docker أو مَعلمات النظام المتقدّمة لمفتاح KMS. كيف يمكنني ضبط ذلك في حِزم الدوال؟
لا يتيح Cloud Functions حاليًا إعداد مستودع Docker أو مفتاح KMS في Firebase. إذا كنت تنقل البيانات من إضافة تم ضبط مَعلمات النظام هذه فيها وأردت الحفاظ على هذه الوظيفة، يمكنك تطبيق المَعلمات على وظائف حزمة تطوير البرامج الجديدة باستخدام gcloud CLI.
المتطلبات الأساسية
- يجب نشر حزمة الدوال في البداية باتّباع أدلة النقل لكي تكون الدوال متاحة في Google Cloud.
حدِّد متغيّرات البيئة في نافذة الأوامر:
export PROJECT_ID="YOUR_PROJECT_ID" export FUNCTION_REGION="YOUR_REGION" # e.g. us-east1 export KIT_NAME="YOUR_KIT_NAME" # e.g. firestore-bigquery-export export SOURCE_DIR="YOUR_KIT_SOURCE_DIR" # e.g. "./function-kits/${KIT_NAME}/source" export REPO_NAME="YOUR_DOCKER_REPO_NAME" export KEY_RING="YOUR_KMS_KEY_RING" export KEY_NAME="YOUR_KMS_KEY_NAME" # Retrieve Project Number automatically export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")أنشئ مسبقًا
.gcloudignoreفي جذر المصدر للحزمة حتى لا يتجاهل.gitignoreملفات الإصدار المجمَّعة:cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore" .gcloudignore .git .gitignore node_modules #!include:.gitignore !lib/** EOFمنح أذونات "إدارة الهوية وإمكانية الوصول" المطلوبة:
بالنسبة إلى مفاتيح KMS (التي تمنح وكلاء الخدمة إذن الوصول إلى فك التشفير):
for SERVICE_ACCOUNT in \ "service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \ "service-${PROJECT_NUMBER}@gcf-admin-robot.iam.gserviceaccount.com" \ "service-${PROJECT_NUMBER}@gcp-sa-artifactregistry.iam.gserviceaccount.com" do gcloud kms keys add-iam-policy-binding "$KEY_NAME" \ --keyring="$KEY_RING" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:${SERVICE_ACCOUNT}" \ --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" doneبالنسبة إلى Artifact Registry (يمنح إذن التعديل إلى Cloud Build وإذن القراءة إلى Cloud Run):
# Grant the Cloud Build / Compute Service Account permission to write images to the repository gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --role="roles/artifactregistry.writer" # Grant Cloud Run permission to pull images from the repository gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \ --location="$FUNCTION_REGION" \ --project="$PROJECT_ID" \ --member="serviceAccount:service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \ --role="roles/artifactregistry.reader"
تطبيق الإعدادات باستخدام gcloud CLI
نفِّذ الأمر gcloud functions deploy لكل دالة في مجموعتك:
gcloud functions deploy FUNCTION_NAME \
--project="$PROJECT_ID" \
--region="$FUNCTION_REGION" \
--source="./function-kits/${KIT_NAME}/source" \
--docker-repository="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/repositories/${REPO_NAME}" \
--kms-key="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/keyRings/${KEY_RING}/cryptoKeys/${KEY_NAME}"
يُرجى العِلم أنّ هذا الحلّ البديل لا يعمل في الحالات التالية:
- مثيلات حزمة جديدة: تؤدي إضافة مثيل في
firebase.jsonإلى إنشاء مورد Cloud Functions v2 جديد يستخدم تلقائيًا مفاتيح تديرها Google وgcf-artifacts. يجب تنفيذgcloudلكل مثيل جديد. - إعادة إنشاء الدالة: يؤدي تغيير نوع المشغّل (على سبيل المثال، من HTTPS إلى مشغّل Cloud Firestore) أو تعديل نقطة الدخول أو إعادة التسمية إلى أن تحذف أداة سطر الأوامر Firebase الدالة القديمة وتنشئ دالة جديدة. تفقد الدالة الجديدة هذه الإعدادات إلى أن تشغّل
gcloudمرة أخرى. - اختلاف الإعدادات: لا تعرض واجهة سطر الأوامر Firebase حالة KMS أو مستودع Docker في
firebase functions:listأو سجلات الاختلاف، ما يصعّب عملية تدقيق البنية الأساسية.
التحقّق من النجاح
للتأكّد من تطبيق المستودع ومفتاح التشفير، شغِّل الأمر التالي:
gcloud functions describe FUNCTION_NAME \
--region="$FUNCTION_REGION" \
--project="$PROJECT_ID" \
--format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"