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

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

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 מתחילה השקה חדשה לכל קצה עורפי שמחובר למאגר.
  3. Firebase App Hosting יוצר build חדש של Cloud Build עבור ההוספה שלכם. במשימה הזו, buildpacks של Google Cloud קובעים באיזו מסגרת נעשה שימוש באפליקציה כדי ליצור קונטיינר והגדרות (כולל משתני סביבה, סודות, מכונות מינימום או מקסימום, זיכרון בו-זמני, מעבד והגדרות VPC) שמתאימים לאפליקציה.
  4. בסיום המשימה Cloud Build, הקונטיינר נשמר במאגר Artifact Registry שמיועד ל-Firebase App Hosting. Firebase App Hosting מוסיף גרסה חדשה של Cloud Run לשירות Cloud Run באמצעות קובץ האימג' וההגדרות שלכם. אחרי שתאומת שהגרסה של Cloud Run תקינה, Firebase App Hosting ישנה את הגדרת התנועה שלו כך שכל הבקשות החדשות יפנו לגרסה החדשה של Cloud Run. בשלב הזה ההשקה הושלמה.
  5. כשנשלחת בקשה לאתר שמתארח ב-Firebase App Hosting, היא מטופלת על ידי Google Cloud Load Balancer עם Cloud CDN מופעל. בקשות שלא שמורות במטמון נשלחות לשירות Cloud Run.

שילוב מסגרת

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

  • Next.js 13 ומעלה
  • Angular בגרסה 17.2 ומעלה

App Hosting מזהה את המסגרת שבה אתם משתמשים על ידי בדיקה של הקובץ package-lock.json או של קובץ נעילה אחר במאגר. אם תנסו לפרוס אפליקציית Node.js ללא קובץ נעילת (lock) App Hosting לא יצליח ליצור ולרוץ את האפליקציה. אפשר ליצור את package-lock.json על ידי הפעלת npm install בתיקיית השורש.

מתאמי Framework

למתאמי המסגרת של App Hosting יש שני תפקידים מרכזיים:

  1. הם מנתחים את קוד המקור ואת קובצי התצורה הספציפיים למסגרת (כמו next.config.js) ויוצרים חבילת פלט שאפשר לעבד באמצעות שאר התשתית של אירוח האפליקציות.
  2. הם מריצים את פקודת ה-build של האפליקציה כדי ליצור נכסים סטטיים וליצור גרסה אופטימיזציה של האפליקציה לסביבת הייצור.

מתאמי המסגרות יוצרים את אפליקציית Node.js באמצעות npm run build, והם פועלים בצורה הטובה ביותר עם סקריפטים ברירת המחדל ל-build של כל מסגרת: next build ל-Next.js ו-ng build ל-Angular. App Hosting ינסה לבצע גרסאות build באמצעות פקודות build בהתאמה אישית, אבל לא ניתן להבטיח שהן יעבדו.

המקור למתאמים של Next.js ו-Angular זמין ב-firebase-framework-tools.

מסגרות אחרות

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

אם אתם רוצים להוסיף תמיכה בפלטפורמות נוספות, תוכלו ליצור מתאם או לפנות למנהלי הפלטפורמה כדי להמיר את הפלט של ה-build לפורמט של App Hosting. מתאמי Nextjs ו-Angular הם דוגמאות טובות לכל מי שיוצר מתאם.

אפשר למצוא את המסגרות הנתמכות ב-Firebase Open Source.

איך פועל השילוב עם המאגר 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.
  3. אסימון הרשאה ייעודי של GitHub נשמר ב-Developer Connect במאגר של מנהל הסודות של הפרויקט. אל תשנו או תמחקו את האסימון הזה.

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

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

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

App Hosting מיקומים

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

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

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

  • us-central1 (איווה)
  • asia-east1 (טייוואן)
  • europe-west4 (הולנד)

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

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

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

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

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

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

  • קצה עורפי: האוסף של המשאבים המנוהלים שנוצרים על ידי App Hosting כדי לפתח ולהפעיל את אפליקציית האינטרנט.
  • השקה: גרסה ספציפית של האפליקציה הפעילה, שמקושרת ל-commit ב-Git.
  • הסתעפות פעילה: ההסתעפות של מאגר GitHub שמופיעה בכתובת ה-URL הפעילה. לרוב, זהו ההסתעפות שאליה מיזגו את ההסתעפויות של התכונות או ההסתעפויות של הפיתוח.

בעיות ידועות ומגבלות

לגרסת ה-preview של App Hosting יש כמה מגבלות ידועות:

  • במקרים מסוימים, קצה עורפי של App Hosting עשוי להחזיר הודעות Intermittent connection error בכתובת ה-URL של האפליקציה. תיקון יהיה זמין בגרסה מאוחרת יותר.
  • כותרות Cache-Control משתנות כדי להגביל את המטמון של CDN ל-60 שניות. בעתיד, כשApp Hosting תהיה מסוגלת לנקות במהירות את המטמון בזמן הפריסה, המגבלה הזו תוסר.
  • אופטימיזציית התמונות מתבצעת ב-Cloud Run כברירת מחדל, והתמונות שעברו אופטימיזציה לא נשמרות. מומלץ להשבית את אופטימיזציית התמונות או לציין באופן ידני מעבד עד שיהיה פתרון טוב יותר.
  • נתיבי כתובות URL שמכילים תווים עם קידוד באחוזים מפוענחים על ידי Cloud Run. כתוצאה מכך, יכולות להיות בעיות בתכונות שמצפות רק לנתיבי כתובות URL מקודדים, כמו ניתוב מקביל ב-Next.js.
  • קבצים סטטיים שלא שמורים במטמון מוצגים מ-Cloud Run. בגרסה שתפורסם בהמשך, הם יישמרו ויוצגו מהמקור App Hosting כדי לשפר את הביצועים.
  • יכול להיות שמק"טים של App Hosting לא יוצגו בדף השימוש בקצה העורפי במסוף Firebase. הן יהיו זמינות במהדורה מאוחרת יותר.
  • יכול להיות שבמסוף Firebase תוצג מדי פעם השגיאה 'לא נמצא build והוא לא תקין' בזמן יצירת הקצה העורפי.
  • כל הקצוות העורפי באותו פרויקט משתפים ארגון או חשבון ב-GitHub. אפשר לקשר אותם למאגרים שונים באותה חשבון/ארגון. כדי ליצור קצוות עורפיים שמחוברים לחשבונות GitHub שונים, צריך להציב אותם בפרויקטים נפרדים.
  • שכבת הביניים, הכתיבה מחדש וההפניות האוטומטיות של Next.js מתבצעות ב-Cloud Run, מאחורי ה-CDN. מכיוון שהן לא מגינות על תשובות שנשמרו במטמון, חשוב להגדיר הוראות בקרה מתאימות לתוכן שאתם מייצרים.