App Hosting מטפל בסדרה מורכבת של משימות ברקע כדי לפשט את פריסת האפליקציה. בדף הזה מתוארים החלקים העיקריים של תהליך המשימות, ומוצג מידע על נקודות שבהן אולי תרצו להתאים אישית את התהליך בהתאם לצורכי האפליקציה.
מונחים והגדרות מרכזיים
כדי להבין את הפרטים של תהליך App Hosting, כדאי להגדיר חלק מהמונחים באופן ספציפי מאוד. הנה המונחים הבסיסיים:
- קצה עורפי: אוסף המשאבים המנוהלים ש-App Hosting יוצר כדי לבנות ולהפעיל את אפליקציית האינטרנט.
- גרסה (Build): גרסה ספציפית של האפליקציה, שבדרך כלל מקושרת ל-git commit. תהליך היצירה של build כולל כמה תהליכי משנה, בעיקר בניית האפליקציה ב-Cloud Build ופריסת גרסה (שמשרתת בהתחלה 0% מהתנועה עד להשקה) ב-Cloud Run.
- השקה: התהליך שבו מגדירים גרסה כך שתציג תנועה באופן פעיל. כש-App Hosting מופעל באופן אוטומטי על ידי git commit, הוא קודם יוצר גרסה באמצעות ההסתעפות הפעילה, ואז יוצר השקה כדי להפנות אליה את התנועה הפעילה.
- הסתעפות פעילה: ההסתעפות של המאגר ב-GitHub שנפרסת בכתובת ה-URL הפעילה. לרוב, זהו הענף שאליו מתמזגים ענפי התכונות או ענפי הפיתוח.
ארכיטקטורה של Google Cloud ו-App Hosting
App Hosting מתזמר קבוצה של מוצרי Google Cloud כדי שתוכלו לפרוס את אפליקציית האינטרנט, להציג אותה ולעקוב אחריה. האפליקציות נוצרות באמצעות Cloud Build, מוצגות ב-Cloud Run ונשמרות במטמון ב-Cloud CDN. שירותים משולבים כמו Cloud Secret Manager שומרים על אבטחת מפתחות ה-API.
- כשמבצעים commit ב-live branch, Google Cloud Developer Connect שולח אירוע אל Firebase App Hosting.
- בתגובה לאירוע הזה, Firebase App Hosting יוצר גרסת build חדשה לקצה העורפי שמחובר למאגר.
- קודם כל, Firebase App Hosting יוצר גרסת build חדשה של Cloud Build ל-commit. במשימה הזו, חבילות ה-build של Google Cloud קובעות באיזו מסגרת משתמשים באפליקציה כדי ליצור קונטיינר והגדרות אישיות (כולל משתני סביבה, סודות, מספר מינימלי או מקסימלי של מכונות, בו-זמניות, זיכרון, מעבד והגדרות VPC) שמתאימים לאפליקציה. מידע נוסף זמין במאמר תהליך ה-build של App Hosting.
- בסיום המשימה של Cloud Build, הקונטיינר מאוחסן במאגר של Artifact Registry שמיועד ל-Firebase App Hosting. לאחר מכן, Firebase App Hosting מוסיף גרסה חדשה של Cloud Run לשירות Cloud Run באמצעות קובץ האימג' וההגדרות שלכם.
- אחרי שהגרסה של Cloud Run הושלמה ואומתה כתקינה, Firebase App Hosting משנה את הגדרות התעבורה כדי להפנות את כל הבקשות החדשות לגרסה החדשה של Cloud Run. בשלב הזה, ההשקה הושלמה.
- כשנשלחת בקשה לאתר שמתארח ב-Firebase App Hosting, הבקשה מטופלת על ידי מאזן העומסים של Google Cloud עם Cloud CDN מופעל. בקשות שלא נשמרו במטמון נשלחות לשירות Cloud Run. במאמר שמירת תוכן של אפליקציות במטמון מוסבר איך לשפר את הביצועים באמצעות Cloud CDN.
שילוב עם Framework
App Hosting מספק תמיכה מוגדרת מראש בבנייה ובפריסה של אפליקציות אינטרנט שפותחו במסגרות הבאות:
- Next.js מגרסה 13.5.x ואילך
- Angular 18.2.x ואילך
בלוחות הזמנים של התמיכה מפורטים פרטים על גרסאות ספציפיות ורמות תמיכה.
בנוסף ל-Next.js ול-Angular, App Hosting תומך גם בכל framework לאינטרנט שיכולה לספק פלט build שתואם למפרט של חבילת הפלט שלנו. במאמר מסגרות וכלים ל-App Hosting מפורט מידע נוסף על מסגרות, מתאמי מסגרות וכלים קשורים שנתמכים על ידי App Hosting.
איך פועל השילוב של מאגר App Hosting
הקישור החשוב בין המאגר ב-GitHub לבין הקצה העורפי של App Hosting מטופל על ידי Developer Connect, פלטפורמת הקישוריות של Google Cloud לכלי DevOps חיצוניים. כשמגדירים את החיבור הזה (בדרך כלל במהלך היצירה של קצה עורפי של App Hosting), תהליך העבודה בממשק המשתמש של Developer Connect מדריך אתכם בהתקנה של אפליקציית Firebase GitHub. השלבים העיקריים בתהליך הזה הם:
- מקצים ל-Developer Connect את התפקיד אדמין של Secret Manager. כך המערכת יכולה לאחסן את פרטי הכניסה באופן מאובטח כ "סודות" ב-Cloud Secret Manager.
- אתם נותנים לאפליקציית Firebase GitHub הרשאה לגשת למאגר שלכם ב-GitHub. יכול להיות שתצטרכו הרשאות נוספות ב-GitHub כדי לגשת למאגר הנכון.
- Developer Connect שומר אסימון הרשאה ייעודי של GitHub במאגר של Secret Manager בפרויקט. אל תשנו או תמחקו את האסימון הזה.
בנוסף, App Hosting משתלב עם ה-API של בדיקות GitHub כדי לספק בדיקה להשקות. הבדיקה הזו מאפשרת לכם לראות את סטטוס ההשקה ב-GitHub ולנפות באגים בתהליך הפריסה אם יש שגיאות.
שילוב עם Firebase ושירותים אחרים של Google
App Hosting מגדיר גם את סביבת ה-build וגם את סביבת זמן הריצה, כדי שתוכלו להפעיל את ה-SDK של Firebase לאדמינים באמצעות Application Default Credentials. כך, הקצה העורפי יכול לתקשר עם מוצרי Firebase אחרים גם בזמן הפיתוח וגם בזמן הריצה. במאמר שילוב ערכות Firebase SDK באפליקציית האינטרנט מוסבר איך להפעיל את האפליקציה ונושאים קשורים אחרים שקשורים לערכות Firebase SDK.
App Hosting מיקומים
App Hosting יוצר את משאבי הקצה העורפי במיקום ספציפי, שנקרא האזור הראשי. App Hosting משתלב עם רשת CDN גלובלית כדי לספק תוכן במהירות, אבל תוכן שלא נשמר במטמון מועבר מהאזור הראשי של האפליקציה. לגמישות הזו במיקום של אפליקציית האינטרנט יש יתרונות חשובים:
- שיפור הביצועים וצמצום זמן האחזור על ידי קירוב הנתונים מבחינה גיאוגרפית למשתמשים.
- כשל קטסטרופלי ב-App Hosting באזור אחד לא ישפיע על אפליקציות אינטרנט שנפרסו באזורים אחרים.
אפשר לבחור כל אחד מהאזורים האלה כשיוצרים קצה עורפי של App Hosting ממסוף Firebase או מ-CLI של Firebase:
-
us-central1(איווה) us-east4(צפ' וירג'יניה)us-east5(קולומבוס)asia-east1(טייוואן)asia-southeast1(סינגפור)europe-west4(הולנד)
חשבון השירות לקצה העורפי של App Hosting
במהלך ה-build ובזמן הריצה, הקצה העורפי של App Hosting מאמת את עצמו מול שירותי Google אחרים באמצעות חשבון שירות. חשבון שירות שמוגדר כברירת מחדל למטרות האלה נוצר בפעם הראשונה שמפעילים את App Hosting בפרויקט ב-Firebase:
firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com
חשבון השירות הזה חל על כל ה-backends כברירת מחדל, ויש לו קבוצה מינימלית של הרשאות שמאפשרות לכם ליצור, להריץ ולנטר את האפליקציה. יש לו גם הרשאה לאמת את ה-SDK לאדמינים באמצעות Application Default Credentials, כדי לבצע פעולות כמו טעינת נתונים מ-Cloud Firestore. תפקידים ב-Firebase App Hosting
אם האפליקציה צריכה לקיים אינטראקציה עם שירותים נוספים של Google בזמן ה-build או מ-backend שפועל, אתם יכולים להתאים אישית את חשבון השירות שמוגדר כברירת מחדל על ידי הוספת תפקידים. לדוגמה, אם האפליקציה דורשת הרשאות ל-Vertex AI, יכול להיות שתצטרכו להוסיף את התפקיד roles/aiplatform.user או תפקיד קשור אחר.