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

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

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

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

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

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

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

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

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

הרשאות להצטרפות ראשונית (הפריסה הראשונה למיקום)

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

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

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

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

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

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

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

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

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

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

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

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

שלבי הפריסה

  1. מריצים את הפקודה firebase init apphosting בספריית הפרויקט המקומית.
  2. כשמופיעה ההודעה, בוחרים באפשרות שימוש בפרויקט קיים ובוחרים את פרויקט Firebase הרצוי.
  3. בוחרים בשרת קצה עורפי חדש או קיים לפריסה. בשלב הזה מוגדרות פריסות של Hosting בספרייה המקומית, ומוצגת בקשה להזנת פרטי הגדרה:
    • המזהה של העורף שאליו רוצים לפרוס
    • האזור שבו רוצים לפרוס את ה-Backend, אם יוצרים Backend חדש
    • הנתיב לספריית הבסיס של קוד האפליקציה
    • סביבת זמן הריצה המועדפת של 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 אחרת.

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

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

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

  • .zip
  • .tgz

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

שלבי הפריסה

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

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

  5. לוחצים על סיום ופריסה: לחצן ה'סיום' העצמאי מושבת בהעלאות של קובצי ZIP, כי העלאה של ארכיון היא פעולה חד-פעמית שצריכה להיות מלווה מיד בפריסה כדי להבטיח שהקצה העורפי יפעל.

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

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

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

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

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

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

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

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