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

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

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

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

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

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

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

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

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

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

כשמפעילים פריסה של מקור מקומי במיקום של פרויקט בפעם הראשונה, צריך להקצות קטגוריה של GCS ב-App Hosting כדי לאחסן את הארכיונים, ולתת לסוכן השירות של 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 בגרסה 14.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...".
    • טיפול בשגיאות ומעקות בטיחות: אם אחד משלבי ההכנה נכשל (למשל, אם משתמש שאינו בעלים מקבל את השגיאה 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...‎"). אחרי שההתחברות תצליח, גוררים או בוחרים את קובץ הארכיון באמצעות כלי ההעלאה, מציינים את תיקיית השורש של האפליקציה ולוחצים על Deploy כדי להפעיל את ה-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, צריך להעביר את הפרויקט. איך מעבירים את הנתונים