הסבר על אירוח אפליקציות ואיך הוא עובד

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

מונחים והגדרות חשובים

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

• קצה עורפי: אוסף של משאבים מנוהלים ש-App Hosting יוצר כדי לבנות ולהפעיל את אפליקציית האינטרנט.
• גרסה: גרסה ספציפית של האפליקציה, בדרך כלל מקושרת ל-git commit. תהליך יצירת ה-build כולל תהליכי משנה רבים, במיוחד ה-build של האפליקציה ב-Cloud Build והפריסה של עדכון (שבתחילה משרת 0% מהתנועה עד להשקה) ב-Cloud Run.
• השקה: התהליך של הגדרת גרסת build להצגת מודעות באופן פעיל. כשמתבצעת הפעלה אוטומטית על ידי git commit, ‏ App Hosting יוצר קודם build באמצעות הענף הפעיל, ואז יוצר פריסה כדי להפנות אליו תנועה בזמן אמת.
• הסתעפות פעילה: ההסתעפות במאגר GitHub שמתבצעת ממנה פריסה לכתובת ה-URL הפעילה. לרוב, זה הענף שאליו ממזגים ענפי תכונות או ענפי פיתוח.

‫Google Cloud וארכיטקטורת App Hosting

‫App Hosting מארגן קבוצה של מוצרי Google Cloud כדי שתוכלו לפרוס, להציג ולנטר את אפליקציית האינטרנט שלכם. האפליקציות בנויות באמצעות Cloud Build, מוצגות ב-Cloud Run ומאוחסנות במטמון ב-Cloud CDN. שירותים משולבים כמו Cloud Secret Manager שומרים על מפתחות ה-API שלכם.

1. כששולחים קומיט לענף הפעיל, Google Cloud Developer Connect שולח אירוע אל Firebase App Hosting.
2. בתגובה לאירוע הזה, Firebase App Hosting יוצרת גרסת build חדשה עבור הקצה העורפי שמחובר למאגר.
   1. קודם, Firebase App Hosting יוצרת גרסת build חדשה של Cloud Build בשביל הקומיט. בג'וב הזה, Google Cloud buildpacks קובעים באיזו מסגרת משתמשים באפליקציה כדי ליצור קונטיינר והגדרות (כולל משתני סביבה, סודות, מספר מינימלי או מקסימלי של מופעים, זיכרון מקביל, מעבד והגדרות VPC) שמתאימים לאפליקציה. מידע נוסף זמין במאמר בנושא תהליך ה-build של App Hosting.
   2. כשהפעולה Cloud Build מסתיימת, הקונטיינר נשמר במאגר Artifact Registry שמוקדש ל-Firebase App Hosting. ‫Firebase App Hosting מוסיף גרסת Cloud Run Revision חדשה לשירות Cloud Run באמצעות קובץ האימג' וההגדרה שלכם.
3. אחרי שגרסת Cloud Run תושלם ותאומת כגרסה תקינה, Firebase App Hosting ישנה את הגדרות התנועה שלה כך שכל הבקשות החדשות יופנו לגרסת Cloud Run החדשה. בשלב הזה, ההשקה הושלמה.
4. כשבקשה נשלחת לאתר שמתארח ב-Firebase App Hosting, הבקשה מטופלת על ידי מאזן העומסים של Google Cloud עם Cloud CDN מופעל. בקשות שלא נשמרו במטמון נשלחות לשירות Cloud Run. הנחיות לאופטימיזציה של הביצועים באמצעות Cloud CDN מופיעות במאמר בנושא שמירת תוכן האפליקציה במטמון.

שילוב של מסגרת

‫App Hosting מספק תמיכה מוגדרת מראש בבנייה ובפריסה של אפליקציות אינטרנט שפותחו במסגרות העבודה האלה:

• ‫Next.js 13.5.x ואילך
• ‫Angular 18.2.x ומעלה

בלוחות הזמנים של התמיכה מפורטים פרטים על גרסאות ספציפיות ורמות תמיכה.

בנוסף ל-Next.js ול-Angular, ‏ App Hosting תומך גם בכל מסגרת אינטרנט שיכולה לספק פלט של build שתואם למפרט של חבילת הפלט שלנו. מידע נוסף על מסגרות, מתאמי מסגרות וכלים קשורים שנתמכים על ידי App Hosting זמין במאמר Frameworks and tooling for App Hosting.

איך פועל השילוב של מאגר App Hosting

החיבור החשוב בין המאגר שלכם ב-GitHub לבין App Hostingהקצה העורפי מטופל על ידי Developer Connect, פלטפורמת הקישוריות של Google Cloud לכלים חיצוניים של DevOps. כשמגדירים את הקישור הזה (בדרך כלל במהלך יצירה של קצה עורפי App Hosting), תהליך העבודה בממשק המשתמש של Developer Connect מנחה אתכם בהתקנה של אפליקציית Firebase GitHub. השלבים העיקריים בתהליך הזה הם:

1. אתם מעניקים ל-Developer Connect את התפקיד אדמין של Secret Manager. כך המערכת יכולה לאחסן את פרטי הכניסה באופן מאובטח כ'סודות' ב-Cloud Secret Manager.
2. אתם מאשרים לאפליקציית Firebase GitHub גישה למאגר שלכם ב-GitHub. יכול להיות שתצטרכו הרשאות נוספות ב-GitHub כדי לגשת למאגר הנכון.
3. ‫Developer Connect מאחסן אסימון הרשאה ייעודי של GitHub במאגר של מנהל הסודות בפרויקט. אל תשנו או תמחקו את האסימון הזה.

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

שילוב עם Firebase ושירותים אחרים של Google

‫App Hosting מגדיר את סביבות ה-build וזמן הריצה, כך שתוכלו לאתחל את SDK של Firebase לאדמינים באמצעות Application Default Credentials. כך, ה-backend יכול לתקשר עם מוצרי Firebase אחרים בזמן הבנייה ובזמן הריצה. מידע נוסף על הפעלת האפליקציה ועל נושאים אחרים שקשורים ל-Firebase SDK זמין במאמר בנושא שילוב של Firebase SDK באפליקציית אינטרנט.

App Hosting מיקומים

‫App Hosting יוצר משאבי backend במיקום ספציפי שנקרא האזור הראשי. ‫App Hosting משתלב עם רשת CDN גלובלית כדי לספק תוכן במהירות, אבל תוכן שלא נשמר במטמון מוגש מהאזור הראשי של האפליקציה. הגמישות הזו במיקום של אפליקציית האינטרנט מניבה יתרונות חשובים:

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

אתם יכולים לבחור כל אחד מהאזורים האלה כשאתם יוצרים App Hosting backend ממסוף Firebase או מ-CLI Firebase:

• us-central1 (איווה)
• us-east4 (N. וירג'יניה)
• us-east5 (Columbus)
• asia-east1 (טייוואן)
• asia-southeast1 (סינגפור)
• europe-west4 (הולנד)

חשבון השירות של שירות לקצה העורפי App Hosting

במהלך הבנייה ובזמן הריצה, ה-Backend של App Hosting מאומת מול שירותים אחרים של Google באמצעות חשבון שירות. חשבון שירות שמוגדר כברירת מחדל למטרות האלה נוצר בפעם הראשונה שמפעילים את App Hosting בפרויקט Firebase:

firebase-app-hosting-compute@PROJECT ID.iam.gserviceaccount.com

חשבון השירות הזה חל על כל השרתים העורפיים כברירת מחדל, ויש לו קבוצה מינימלית של הרשאות שמאפשרות לכם ליצור, להריץ ולנטר את האפליקציה. יש לו גם הרשאה לאמת את SDK לאדמינים באמצעות Application Default Credentials‏ (ADC), כדי לבצע פעולות כמו טעינת נתונים מ-Cloud Firestore. מידע נוסף זמין במאמר בנושא תפקידים ב-Firebase App Hosting.

אם האפליקציה שלכם צריכה לבצע אינטראקציה עם שירותים נוספים של Google בזמן הבנייה או משרת עורפי שפועל, אתם יכולים להתאים אישית את חשבון השירות שמוגדר כברירת מחדל על ידי הוספת תפקידים. לדוגמה, אם האפליקציה שלכם דורשת הרשאות ל-Vertex AI, יכול להיות שתצטרכו להוסיף את roles/aiplatform.user או תפקיד קשור אחר.