שאלות נפוצות בנושא הוצאה משימוש של תוספים ל-Firebase

למה אנחנו מוציאים משימוש את Firebase Extensions?

עקב שינויים וביטולים קרובים בתשתית הבסיסית של Google Cloud, נסגור את שירות Firebase Extensions המנוהל.

האם תוספים קיימים שנפרסו יפסיקו לפעול אחרי 31 במרץ 2027?

לא. תוספים שכבר נפרסו פועלים ישירות בתשתית סטנדרטית של Google Cloud (כמו Cloud Functions, Eventarc, Cloud Run ו-Cloud Tasks) וימשיכו לפעול ללא הגבלת זמן.

עם זאת, אחרי 31 במרץ 2027, לא תוכלו יותר לעדכן, להגדיר מחדש או להסיר את התוספים האלה דרך מסוף Firebase או ה-CLI. בנוסף, לא תוכלו יותר להוריד את הגדרות התוספים הקיימות שלכם כדי לעזור לכם לעבור לערכת פונקציות. מומלץ מאוד להעביר או לייצא את הגדרות התוספים עד 31 במרץ 2027.

מה קורה אם משתמש לא עושה כלום?

אם המשתמש לא יבצע פעולה כלשהי, הפונקציות הקיימות שהופעלו ימשיכו לפעול כנכסים רגילים. אבל אחרי 31 במרץ 2027:

1. הם לא יכולים לשנות פרמטרים של הגדרות או לעדכן משתני סביבה.
2. הם לא יכולים להחיל תיקוני באגים, תיקוני אבטחה או שדרוגים של יחסי תלות.
3. הם לא יכולים להוריד את הגדרת התוסף כדי להגדיר באופן זהה ערכת פונקציות חלופית.
4. רוב התוספים מבוססים כרגע על Cloud Functions SDK v1 מדור קודם, שקשור לסביבות זמן ריצה ישנות יותר של Node.js. אחרי ש-Google Cloud יוציא את סביבות זמן הריצה האלה משימוש באופן סופי, יכול להיות שהפונקציות יפסיקו לפעול או יושבתו. תמיכה בזמן ריצה

האם יש משהו שיחליף את תוספים ל-Firebase?

הוספנו הרבה תכונות ל-Cloud Functions כדי שיהיה אפשר להשתמש בהן במקום בתוספים. בעיקר ערכות פונקציות שאפשר להפיץ באמצעות npm, ומאפשרות לפרוס כמה מופעים של פונקציות, בדומה לאופן שבו אפשר להתקין תוספים כמה פעמים בפרויקט יחיד.

עם זאת, כל מפרסם של תוסף יכול להחליט אם הוא רוצה לפרסם ב-npm ערכת פונקציות רשמית חלופית. מכיוון שתוספים הם קוד פתוח, אם בעל התוסף לא רוצה ליצור תחליף רשמי, כל מפתח יכול ליצור עותק שלו כדי ליצור תחליף לא רשמי באמצעות Cloud Functions ממשקי ה-API מהדור השני ב-Node SDK.

בעלי תוכן דיגיטלי שרוצים לבצע החלפה צריכים לפעול לפי ההוראות שבמדריך ההעברה לבעלי תוכן דיגיטלי.

משתמשים שרוצים להשתמש בחבילות החלפה רשמיות או ליצור חבילות החלפה משלהם יכולים לפעול לפי ההוראות במדריך ההעברה למשתמשים.

מה צריך לעשות אם משתמשים בתוסף?

אם אתם משתמשים בתוספים ולא משתמשים יותר בתוספים שהתקנתם, כדאי להסיר אותם לפני 31 במרץ 2027.

אחרי ההוצאה משימוש, הלחצן 'הסרה' במסוף Firebase ופקודות ה-CLI התואמות יוסרו. צריך למחוק באופן ידני את כל המשאבים המשויכים ל-Google Cloud, כולל Cloud Functions, סודות Secret Manager, Cloud Tasks תורים וחשבונות שירות מותאמים אישית של IAM, באמצעות מסוף Google Cloud.

עם זאת, אם אתם משתמשים באופן פעיל בתוספים המותקנים, מומלץ מאוד לעבור לערכות פונקציות. כדי לעבור לערכות פונקציות, אפשר להיעזר בהוראות שבמדריך ההעברה למשתמשים.

אתם יכולים לבחור שלא לבצע מיגרציה לערכות פונקציות. במקרה כזה, מומלץ מאוד לעדכן את כל התוספים לגרסאות העדכניות שלהם, להקפיד שהם יהיו מעודכנים ולייצא את ההגדרות הקיימות של התוספים למקרה שתרצו לבצע מיגרציה בהמשך.

מה צריך לעשות אם אתם מפרסמים תוספים?

מומלץ להעביר את התוספים שפרסמתם לערכות פונקציות שפורסמו ב-npm. כדי להתחיל, אפשר להעביר את התוסף לפונקציות מהדור השני, שזה תנאי מוקדם ליצירת ערכת פונקציות. התהליך כולל אריזה של לוגיקת התוסף באמצעות Cloud Functions v2 SDK. עדכנו את Cloud Functions v2 SDK עם תמיכה בתכונות כמו אבטחה הצהרתית ואירועים במחזור החיים. עכשיו אפשר להעביר את קוד התוסף הקיים לפונקציה מהדור השני עם שינויים מינימליים בלוגיקה העסקית המרכזית. אפשר לפרסם את הפונקציות האלה באמצעות חבילת npm. פרטים נוספים זמינים במדריך להעברת נתונים לבעלי תוכן דיגיטלי.

מה עושים אם יש עוד שאלות?

משתמשים שיש להם שאלות יכולים להיעזר במדריך להעברת משתמשים. אם יש לכם שאלות נוספות אחרי השימוש במדריך, אתם יכולים לפנות אל התמיכה של Firebase.

בעלי תוכן דיגיטלי שרוצים לדעת איך לבצע את המעבר Firebase Extensions יכולים להיעזר במדריך למעבר לבעלי תוכן דיגיטלי. במדריך הזה מוסבר איך אפשר להתעדכן בעדכונים ולקבל עזרה בהצעת חלופה לתוספים שפורסמו.

מהם נתיבי ההעברה העיקריים שזמינים?

החל מספטמבר 2026, Firebase תומך באופן רשמי בשתי דרכי העברה עיקריות:

1. מעבר לפונקציה משותפת ב-NPM (חבילת פונקציות): מומלץ לסטרימינג של Firestore ל-BigQuery ולכל חבילות פונקציות אחרות שזמינות ב-NPM. הלוגיקה המרכזית ארוזה כספריית NPM רגילה באמצעות Cloud Functions SDK בגרסה 2. המשתמשים מאתחלים בסיס קוד Cloud Functions סטנדרטי, מתקינים את החבילה, מייצאים מחדש את הפונקציות ופורסים אותן באופן עצמאי באמצעות ה-CLI.
2. Fork and Self-Manage (פיצול וניהול עצמי): מומלץ לכל התוספים שאין להם ערכת פונקציות זמינה ב-npm. המשתמשים מעתיקים או יוצרים עותק של קוד המקור של התוסף בקוד פתוח, משנים את המבנה של הטריגרים ל-Firebase Functions v2 רגילות באמצעות כישורי מיגרציה של AI או מדריכים ידניים, ומקבלים בעלות מלאה על בסיס הקוד והתחזוקה השוטפת שלו.

אילו תוספים מועברים לערכות פונקציות?

התוסף Stream Firestore to BigQuery הועבר לחבילת פונקציות שזמינה כחבילת npm‏ @firebase-function-kits/firestore-bigquery-export.

למה המיגרציה מחייבת שדרוג מגרסה 1 של Cloud Functions לגרסה 2?

התמיכה הסטנדרטית ב-Cloud Functions v1 מסתיימת עם סביבת זמן הריצה Node.js 22. כדי למנוע "העברה כפולה" שבה מפתחים מעבירים את האפליקציות שלהם מ-Firebase Extensions רק כדי להיאלץ לבצע שינוי מבנה ידני שני כשהפעלת סביבות זמן הריצה מדור קודם תופסק, Firebase ממליצה מאוד לשדרג את כל הפונקציות שהועברו ל-SDK בגרסה 2 באופן מיידי במהלך המעבר הזה, והשדרוג נדרש לערכות פונקציות.

משתמשים בתוספים יכולים גם ליצור ערכות פונקציות משלהם באמצעות מדריך העברת המשתמשים.

האם מעבר ל-Cloud Functions בניהול עצמי ישנה את החיוב של הלקוח?

בדרך כלל לא. תוספים שמוטמעים כבר מחייבים את הלקוחות על משאבי הבסיס Google Cloud שהם צורכים, כמו Cloud Functions הפעלות, Cloud Storage, או BigQuery אחסון ושאילתות. עם זאת, במהלך חלון ההעברה, יכול להיות שהלקוחות יחויבו בעלות נוספת קטנה וזמנית אם הם יפעילו במקביל את Firebase Extensions מהגרסה הקודמת ואת הפונקציה החדשה שהם פרסו במקומה, כדי להבטיח מעבר בטוח.

איך מתבצע החיוב בחשבונות Mandiant או בחשבונות עסקיים מיוחדים אחרים?

הוצאת התכונה משימוש היא שינוי שחל בכל הפלטפורמה ומשפיע על כל הפרויקטים של Firebase ושל Google Cloud. הסדרי החיוב והמינויים הרגילים לא מושפעים. אם לקוחות מבקשים זיכויים בהתאם להסכם רמת השירות (SLA) בגלל השבתה של מוצר שיצא משימוש או בגלל חריגים מורכבים בחיוב, צריך להעביר את הבקשה לטיפול ברמה גבוהה יותר ישירות דרך ערוצי התמיכה הרגילים בנושאי חיוב.

מה הסיכון לאובדן נתונים או להשבתת השירות במהלך ההעברה?

המעבר של משאבים מנוהלים לבסיסי קוד בניהול עצמי כרוך בסיכון קל של שיבוש בשירות או אובדן אירועים.

• שיבוש הטריגרים: אם מוחקים טריגרים ישנים לפני שהטריגרים החדשים מופעלים, נוצר פער שבו המערכת לא מזהה אירועים (למשל, כתיבה של מסמך Cloud Firestore) והם אובדים לצמיתות. כדי למנוע אובדן נתונים, מומלץ לפרוס את ערכת ההחלפה ולאמת אותה לפני שמסירים את התוסף.
• פעולות שדורשות הרשאה: אם בבסיס הקוד החדש שפרסתם חסרות הרשאות IAM שנדרשות לפעולות כמו כתיבה ל-BigQuery, הפעולות ייכשלו בלי שתקבלו על כך הודעה או שהן יגרמו לקריסה בזמן הריצה. הוספנו אבטחה הצהרתית לפונקציות, כך שהפריסה הראשונה של ערכת הכלים שבוצעה על ידי חשבון שיכול לשלוח שאילתות ולהגדיר תפקידים וליצור חשבון שירות, אמורה לצמצם את הבעיה הזו.

איך אפשר למנוע אובדן נתונים בתוסף הייצוא החשוב Cloud Firestore-to-BigQuery?

כדי לבצע מעבר בטוח ללא אובדן נתונים, צוות התמיכה צריך להמליץ למשתמשים לבצע מעבר מבוסס חפיפה ולא מעבר מבוסס פער. זוהי ברירת המחדל בהעברה לחבילות:

1. פורסים את ערכת הפונקציות החלופית בזמן שהתוסף עדיין מותקן ופועל. מחכים כמה דקות עד שהקצאת המשאבים של Eventarc תושלם.
2. כותבים מסמך בדיקה לאוסף Cloud Firestore שבמעקב ומוודאים שהפונקציה החדשה בניהול עצמי כותבת בהצלחה שורה תואמת לטבלת יומן השינויים BigQuery (עם מזהה אירוע חדש).
3. אחרי שמוודאים שהפריסה החדשה פועלת, צריך להסיר או להשבית מיד את התוסף הקודם כדי להפסיק את התנהגות הכתיבה הכפולה.
4. כדי למזער את הסיכוי לשורות כפולות ביומן השינויים הגולמי BigQuery, מומלץ להגדיר את חלון החפיפה קצר ככל האפשר.

5. כתיבה כפולה במהלך חלון ההעברה תגרום להוספה של שתי שורות בטבלת יומן השינויים הגולמי (*_raw_changelog) עם אותם נתוני מסמך וחותמת זמן של Cloud Firestore. עם זאת, התצוגה העדכנית של הטבלה (*_raw_latest) תהיה נכונה.

מידע נוסף על העברת התוסף הזה ועל שחזור נתונים שאבדו מפורט בקובץ README.md של ערכת הכלים.

מה צריך לעשות אם שלב הקצאת ההרשאות במהלך מחזור החיים נכשל?

במסגרת השירות המנוהל, משימות ההגדרה (כמו יצירה של BigQuery מערכי נתונים, טבלאות ותצוגות) טופלו באופן אוטומטי. במודל NPM בניהול עצמי, הטריגרים האלה מופעלים באמצעות פונקציית תור משימות של מחזור חיים. לדוגמה, ב-firestore-bigquery-export הפונקציה נקראת initBigQuerySync.

אם השלב הזה נכשל או לא מופעל באופן אוטומטי:

1. מוודאים שחשבון השירות של זמן הריצה Cloud Functions קיבל את תפקידי ה-IAM הנדרשים. לדוגמה, עבור firestore-bigquery-export זה כולל:

   • כדי ליצור משאבים ולהוסיף שורות: roles/bigquery.dataEditor
   • כדי להריץ משימות וליצור תצוגות: roles/bigquery.user
   • כדי להוסיף את משימת ההקצאה לתור: roles/cloudtasks.enqueuer

2. מוודאים שלפונקציית הקריאה החוזרת (caller) יש הרשאות מסוג roles/cloudtasks.enqueuer.

3. מריצים מחדש באופן ידני את פקודת האתחול של מחזור החיים באמצעות ה-CLI:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. כדי לאבחן שגיאות בהרשאות או בהגדרות, צריך לבדוק את היומנים של Cloud Logging גם עבור פונקציית הטריגר וגם עבור הביצוע של תור המשימות.

איך מועברים פרטי הכניסה של Secret Manager?

במודל המנוהל, משאבי Secret Manager קושרו אוטומטית למופעי התוסף. כשמשתמשים בפקודות ext:migrate או ext:export --mode functions כדי לייצא את הגדרות התוספים ל-Function Kit, אנחנו מפסיקים את ניהול הסודות האלה על ידי התוספים כדי שהם יישארו בפרויקט אחרי הסרת התוסף. אם רוצים להסיר את הסודות האלה בעתיד, צריך לעשות זאת באופן ידני במסוף Google Cloud.

מה קורה אם משתמש רוצה להפעיל כמה מופעים של תוסף שהועבר?

השקנו ערכות פונקציות כדי לתמוך בכמה מופעים של פונקציה, בדומה לאופן שבו אפשר להשתמש בכמה גרסאות של תוסף. לכל ערכה יוקצה מזהה ייחודי של מופע הערכה, שדומה לבסיס קוד ואפשר להשתמש בו במקום בבסיסי קוד בפקודות של CLI. כשפורסים את כל הפונקציות במופע של ערכת כלים, הן יקבלו את הקידומת kit-<instance-id>- כדי להבטיח שלכל פונקציה יהיה שם ייחודי, בדומה לקידומת ext-<extension-instance-id>- בתוספים. מידע נוסף על השימוש בערכות פונקציות כחלק מההעברה מופיע במדריך להעברת משתמשים.

ההתקנה של ערכת הכלים מתבצעת באמצעות npm. מה קורה אם אני רוצה להשתמש ב-Yarn או במנהל חבילות אחר שתואם ל-Node?

בשלב הזה אין לנו תוכניות לתמוך ב-Yarn או במנהלי חבילות אחרים. ההתקנה של ערכת הכלים מתבצעת על ידי הפעלה ישירה של פקודות npm כשמגדירים את קוד המקור של ערכת הכלים בהתקנה הראשונה.

לחלופין, אתם יכולים ליצור תיקיית מקור, להתקין בעצמכם את חבילת npm של ערכת הכלים ולהגדיר אותה עם build וייצוא מתאימים. אפשר לעיין בתבניות TypeScript index-kit בכתובת firebase-tools או לבדוק ערכת כלים שהותקנה באמצעות npm כדוגמה. אחרי שתעשו את זה, תוכלו להתקין אותו כמו ערכה מקומית באמצעות --directory במקום --package. מעכשיו, תצטרכו לזהות את ערכת הכלים לפי ספרייה או מזהה, אבל תוכלו להשתמש בפקודות של ערכת הכלים כדי להוסיף ולהסיר מופעים.

התוסף שלי משתמש בפרמטרים מתקדמים של מערכת מאגר Docker או מפתח KMS. איך אפשר להגדיר את זה בערכות פונקציות?

בשלב הזה, אין תמיכה בהגדרת מאגר Docker או מפתח KMS ב-Cloud Functions עבור Firebase. אם אתם מבצעים מיגרציה מתוסף עם הפרמטרים האלה של המערכת ורוצים לשמור על הפונקציונליות הזו, אתם יכולים להחיל את הפרמטרים על הפונקציות של ערכת הכלים החדשה באמצעות gcloud CLI.

דרישות מוקדמות

1. פורסים את ערכת הפונקציות בהתאם למדריכי ההעברה, כדי שהפונקציות יופיעו ב-Google Cloud.

2. מגדירים את משתני הסביבה במסוף:

   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)")
   

3. יוצרים מראש את .gcloudignore בתיקיית השורש של המקור של ערכת הכלים, כדי ש-.gitignore לא יתעלם מקובצי build שעברו קומפילציה:

   cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore"
   .gcloudignore
   .git
   .gitignore
   
   node_modules
   #!include:.gitignore
   !lib/**
   EOF
   

4. מעניקים את הרשאות ה-IAM הנדרשות:

   • למפתחות 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}"

שימו לב שהפתרון העקיף הזה לא פועל בתנאים הבאים:

1. מופעים חדשים של ערכת כלים: הוספת מופע ב-firebase.json יוצרת משאב חדש של Cloud Functions v2 שמוגדר כברירת מחדל עם מפתחות שמנוהלים על ידי Google ו-gcf-artifacts. צריך להריץ את הפקודה gcloud לכל מופע חדש.
2. יצירה מחדש של פונקציה: שינוי סוג הטריגר (לדוגמה, מ-HTTPS לטריגר Cloud Firestore), שינוי נקודת הכניסה או שינוי השם גורמים לממשק Firebase CLI למחוק את הפונקציה הישנה וליצור פונקציה חדשה. ההגדרות האלה יאבדו בפונקציה החדשה עד שתריצו שוב את gcloud.
3. שינויים לא רצויים בתצורה: ‏Firebase CLI לא מציג את הסטטוס של KMS או של מאגר Docker ב-firebase functions:list או ביומני השוואה, ולכן קשה לבצע ביקורת על התשתית.

איך מוודאים שההטמעה מבוצעת בהצלחה

כדי לוודא שהמאגר ומפתח ההצפנה הוחלו, מריצים את הפקודה הבאה:

gcloud functions describe FUNCTION_NAME \
  --region="$FUNCTION_REGION" \
  --project="$PROJECT_ID" \
  --format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"