דרכים חלופיות לפריסה ב-App Hosting

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

פריסה מקוד המקור

פריסה ממקור מאפשרת להעביר את קוד המקור וההגדרות של האפליקציה ישירות אל App Hosting בלי צורך בחיבור קבוע ל-GitHub.

כשפורסים מקוד מקור, App Hosting מעלה את קוד המקור לקטגוריה של Google Cloud Storage, מריץ את פקודת ה-build של ה-framework ב-Cloud Build ופורס את פריטי המידע שנוצרו בתהליך ה-build ב-Cloud Run וב-Cloud CDN. תהליך ה-build של פריסות מקור מקומיות זהה לזה של פריסות GitHub. אם בפרויקט יש קובץ .gitignore, הקבצים והתיקיות שמופיעים בו לא נכללים בפריסה.

אפשר לפרוס ממקור מקומי באמצעות ה-CLI של Firebase או מסוף Firebase.

הרשאות IAM נדרשות והגדרת התשתית

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

הדרישות המדויקות תלויות בשאלה אם אתם פורסים במיקום (אזור) ספציפי בפעם הראשונה. מידע נוסף על הרשאות זמין בסקירה הכללית של Firebase IAM ובהרשאות ספציפיות של Firebase App Hosting.

הרשאות להגדרה ראשונית (פריסה ראשונה במיקום)

בפעם הראשונה שמתחילים פריסה של מקור מקומי במיקום של פרויקט, App Hosting צריך להקצות קטגוריה של GCS כדי לאחסן את הארכיונים, ולתת לסוכן השירות של App Hosting גישה אליהם. אלה משימות ניהול ברמת הפרויקט, ולכן צריך הרשאות של Project Owner או של אדמין ב-IAM. משתמש עם תפקיד בסיסי של עריכה או צפייה לא יכול לבצע את ההגדרה הראשונית הזו, והוא ייחסם.

ההרשאות הנדרשות להגדרה כוללות:

  • הפעלת Storage API: serviceusage.services.enable
  • יצירת קטגוריית מקור: storage.buckets.create ו-storage.buckets.list
  • הגדרת סוכן השירות: resourcemanager.projects.setIamPolicy כדי לתת ל-App Hosting גישת קריאה (roles/storage.objectViewer) כדי שהוא יוכל לאחזר את הקוד שהועלה במהלך ה-builds.

בפריסה הראשונית, הקטגוריה ב-GCS נוצרת עם מחזור חיים של 30 יום, ואחריו הקטגוריה נמחקת. עם זאת, אתם יכולים לנהל את מסגרת הזמן הזו במסוף Cloud, בקטע Cloud Storage ‏-> Buckets ‏-> Lifecycle ‏-> Rules. ניהול מחזורי החיים של אובייקטים

הרשאות לפריסות הבאות (אחרי שהמיקום מאותחל)

אחרי שמאתחלים את קטגוריית המקור ואת קישורי התפקידים למיקום (באמצעות פריסה ראשונית של CLI או הגדרה במסוף), מפתחים, עורכים או אדמינים של App Hosting יכולים לפרוס עדכונים. לא נדרשות הרשאות אדמין ברמת הפרויקט לפריסות שגרתיות.

הרשאות פריסה פעילות כוללות:

  • אימות הקטגוריה: storage.buckets.list
  • העלאת ארכיון המקור: storage.objects.create
  • הפעלת פיתוח והשקה: הרשאות App Hosting רגילות (apphosting.builds.create ו-apphosting.rollouts.create)

פריסה מקוד המקור באמצעות ה-CLI של Firebase

‫Firebase CLI v14.4.0 ואילך מאפשר להעביר את קוד המקור וההגדרות של האפליקציה ישירות מהמכונה המקומית ל-Firebase. האפשרות הזו נוחה אם אתם כבר מנהלים פריסות אחרות של Firebase (כמו כללי אבטחה או פונקציות) ורוצים לפרוס את אפליקציית האינטרנט ואת שירותי הקצה העורפי ביחד באמצעות פקודת CLI אחת.

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

  • הפרויקטים שלכם צריכים להיות בתוכנית Blaze.
  • צריך להפעיל את firebase-tools מגרסה 14.4.0 ואילך.

שלבי הפריסה

  1. מריצים את firebase init apphosting בספריית הפרויקט המקומית.
  2. כשמוצגת בקשה, בוחרים באפשרות שימוש בפרויקט קיים ובוחרים את פרויקט Firebase היעד.
  3. בוחרים אם לפרוס בקצה עורפי חדש או קיים. בשלב הזה מגדירים פריסות של App Hosting לספרייה המקומית, ומוצגת בקשה להזין את פרטי ההגדרה:
    • המזהה של הקצה העורפי לפריסה
    • האזור לפריסה, אם יוצרים קצה עורפי חדש
    • הנתיב לתיקיית השורש של קוד האפליקציה
    • סביבת זמן הריצה של Node.js שאתם מעדיפים. כשבוחרים סביבת זמן ריצה עם גרסה, עדכונים אוטומטיים של קובץ אימג' בסיסי (ABIU) יכולים להחיל באופן אוטומטי תיקוני אבטחה על הסביבה הבסיסית.
  4. הפקודה App Hosting שומרת את העדפות הפריסה ב-firebase.json, ויוצרת את הקובץ בפרויקט המקומי אם הוא עדיין לא קיים. אחרי שההפעלה מסתיימת, מריצים את firebase deploy כדי לפרוס את קוד המקור.

דוגמה לקובץ firebase.json

{
  "apphosting": [
    {
      "backendId": "my-backend",
      // rootDir specifies the directory containing the app to deploy, but the entire
      // parent directory of firebase.json will be zipped and uploaded to ensure that
      // dependencies outside of the app directory will be available at build time.
      "rootDir": "./my-app",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log",
        "functions"
      ]
    }
  ]
}

פריסה באמצעות מסוף Firebase (העלאת קובץ ZIP)

במסוף Firebase יש ממשק גרפי שמאפשר לפרוס אפליקציות על ידי העלאה ישירה של ארכיון מקור דחוס. התהליך הזה הוא חלופה לתהליך החיבור ל-GitHub, למקרים שבהם אתם מעדיפים לא להשתמש ב-GitHub או מעדיפים הגדרת CI/CD אחרת.

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

פורמטים נתמכים

הכלי להעלאת קבצים במסוף מאמת ומקבל באופן מקורי שני פורמטים של ארכיון דחוס:

  • .zip
  • .tgz

הפורמטים האלה מוצגים באופן מפורש בטקסט התיאור של כלי העלאת הקבצים.

שלבי הפריסה

אפשרות א': במהלך ההגדרה הראשונית של הקצה העורפי
  1. בחירת מקור: באשף היצירה של הקצה העורפי, בוחרים באפשרות העלאת קובץ ZIP בשלב "איך לייבא את האפליקציה?".
  2. הכנה להצטרפות: לחיצה על "הבא" מפעילה את תהליך ההכנה ברקע, שמפעיל את Storage API, מוודא שהתפקידים הנכונים מוגדרים ומעדכן או מוסיף (upsert) את הקטגוריה. בממשק המשתמש מוצג סמל טעינה עם הודעות סטטוס דינמיות: "Enabling API..."‎, "Checking permissions..." ו-"Preparing bucket...".
    • טיפול בשגיאות ומעקות בטיחות: אם אחד משלבי ההכנה נכשל (למשל, אם משתמש שהוא לא Project Owner מקבל את השגיאה 403 PERMISSION_DENIED בגלל הרשאות IAM לא מספיקות), בממשק המשתמש תוצג אזהרה ייעודית עם הוראה לפנות לבעלי הפרויקט. הניווט בשלבים נעול, והלחצן "הבא" והלחצן הסופי "סיום ופריסה" מושבתים עד שהבעיה נפתרת.
  3. העלאת קבצים: אחרי שההכנה מסתיימת, בוחרים או גוררים את קובץ הארכיון לרכיב של מעלה הקבצים.

  4. Configure Settings: מציינים את תיקיית השורש של האפליקציה (ברירת המחדל היא /).

  5. לוחצים על Finish and Deploy: הכפתור Finish לא זמין כשמעלים קובצי ZIP, כי העלאת ארכיון היא פעולה חד-פעמית וצריך לפרוס אותו מיד כדי לוודא שה-backend פועל.

אפשרות ב': השקה ידנית
  1. פתיחת תיבת הדו-שיח: במרכז הבקרה של App Hosting, לוחצים על יצירת השקה.
  2. בחירת מקור: בוחרים באפשרות העלאת קובץ ZIP בתהליך ההעלאה שבתיבת הדו-שיח. אם לקצה העורפי אין חיבור קיים ל-GitHub, האפשרות GitHub מושבתת.
  3. הכנה והעלאה: הבחירה מפעילה את אותו תהליך הכנה ברקע ("הפעלת API…", ‫"Checking permissions...‎" ו-"Preparing bucket...‎"). אחרי שהבדיקה מסתיימת בהצלחה, גוררים או בוחרים את קובץ הארכיון באמצעות כלי ההעלאה, מציינים את תיקיית השורש של האפליקציה ולוחצים על פריסה כדי להפעיל את ה-build וההשקה.

פריסה באמצעות Terraform

אם אתם צריכים שליטה רבה יותר על תהליך ה-build ועל הסביבה שנפרסה, אתם יכולים לפרוס באמצעות Terraform. בעזרת Terraform אתם יכולים להגדיר ולנהל את המשאבים של App Hosting באמצעות קובצי תצורה מוצהרים, ולפרוס קובץ אימג' של קונטיינר שנוצר מראש ישירות ב-App Hosting במקום להסתמך על App Hosting כדי ליצור גרסת build מקוד המקור.

אם אתם משתמשים חדשים ב-Terraform, קראו את המאמר תחילת העבודה עם Terraform ו-Firebase. אם אתם כבר מכירים את Terraform, אתם יכולים להתחיל לעבוד עם קובצי תצורה לדוגמה ומשאבים אחרים של App Hosting.

הגדרת חיבור ל-GitHub בשביל CI/CD

אתם יכולים לקשר מאגר GitHub בכל שלב בכרטיסייה Deployment בהגדרות של קצה העורפי במסוף Firebase. כך תוכלו לפרוס אב טיפוס של אפליקציה מסביבה מקומית, ואז לעבור לפייפליין אוטומטי של CI/CD כשתהיו מוכנים.

פריסה באמצעות כלי AI

אנחנו מוציאים משימוש את Firebase Studio ב-22 במרץ 2027. השינוי לא ישפיע על הקצה העורפי של App Hosting, אבל הלחצן Publish ב-Firebase Studio יוסר. כדי להמשיך לפרסם עדכונים בלי לשנות את כתובת ה-URL, צריך להעביר את הפרויקט. איך מעבירים את הנתונים