App Hosting מטפל בסדרה מורכבת של משימות ברקע כדי לפשט את הפריסה של האפליקציה. בדף הזה מתוארים חלקים מרכזיים בתהליך המשימות, ומפורט מידע על נקודות שבהן כדאי להתאים אישית את התהליך בהתאם לצרכים של האפליקציה.
תמיכה ב-framework
ב-App Hosting יש תמיכה ב-build ובפריסה ללא צורך בהגדרה של אפליקציות אינטרנט שפותחו ב-frameworks הבאות:
- Next.js 13 ואילך
- Angular 17.2+
App Hosting מזהה באיזו framework אתם משתמשים על ידי בדיקת הקובץ package-lock.json או קובץ נעילה אחר במאגר. אם תנסו לפרוס אפליקציית Node.js שחסר בה קובץ נעילה, תהליך היצירה וההפעלה של האפליקציה App Hosting ייכשל. אפשר ליצור את package-lock.json על ידי הרצה של npm
install בתיקיית השורש.
למתאמי המסגרת של App Hosting יש שני תפקידים מרכזיים:
- התכונה הזו מנתחת את קוד המקור ואת כל קובצי התצורה הספציפיים ל-framework (כמו
next.config.js) כדי להבין את ההתנהגות של האפליקציה שהוגדרה. - הם מריצים את פקודת ה-build של האפליקציה כדי ליצור נכסים סטטיים וליצור גרסה מותאמת של האפליקציה לסביבת הייצור.
מתאמי המסגרות יוצרים את אפליקציית Node.js באמצעות npm run build, והם פועלים בצורה הטובה ביותר עם סקריפטים ברירת המחדל ל-build לכל מסגרת: next build ל-Next.js ו-ng build ל-Angular. App Hosting ינסה לבצע גרסאות build באמצעות פקודות build בהתאמה אישית, אבל לא ניתן להבטיח שהן יעבדו.
איך פועל השילוב של המאגר של 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.
- Developer Connect מאחסן אסימון הרשאה ייעודי של GitHub במאגר המנהלים הסודי של הפרויקט. אל תשנו או תמחקו את האסימון הזה.
בנוסף, App Hosting משתלב עם GitHub checks API כדי לספק בדיקה של השקות. הבדיקה הזו מאפשרת לכם לראות את סטטוס ההשקה ב-GitHub ולפתור באגים בתהליך הפריסה במקרה של שגיאות.
שילוב עם Firebase ושירותים אחרים של Google
App Hosting מגדיר גם את סביבות ה-build ואת סביבת זמן הריצה, כדי שתוכלו לאתחל את Firebase Admin SDK באמצעות Google Application Default Credentials. כך הקצה העורפי יוכל לתקשר עם מוצרי Firebase אחרים גם במהלך ה-build וגם במהלך הפריסה.
App Hosting מיקומים
פריסת App Hosting יוצרת את משאבי הקצה העורפי במיקום ספציפי. לגמישות הזו במיקום של אפליקציית האינטרנט יש יתרונות מרכזיים:
- שיפור הביצועים והקטנת זמן האחזור על ידי הצבת הנתונים קרוב יותר מבחינה גיאוגרפית למשתמשים.
- כשל קטסטרופלי ב-App Hosting באזור אחד לא ישפיע על אפליקציות אינטרנט שנפרסו באזורים אחרים.
אפשר לבחור כל אחד מהאזורים האלה כשיוצרים קצה עורפי של App Hosting מהמסוף או מ-CLI של Firebase:
us-central1(איווה)asia-east1(טייוואן)
חשבון השירות לקצה העורפי 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. למידע נוסף על תפקידים ב-Firebase בנושא App Hosting
אם האפליקציה שלכם צריכה לתקשר עם שירותי Google נוספים בזמן הפיתוח או באמצעות קצה עורפי פעיל, אפשר להוסיף תפקידים כדי להתאים אישית את חשבון השירות שמשמש כברירת המחדל. לדוגמה, אם לאפליקציה שלכם נדרשות הרשאות ל-Vertex AI, יכול להיות שתצטרכו להוסיף roles/aiplatform.user או תפקיד קשור כלשהו.
מונחי מפתח והגדרות
- הקצה העורפי: אוסף המשאבים המנוהלים שנוצר על ידי App Hosting כדי לבנות ולהפעיל את אפליקציית האינטרנט.
- השקה: גרסה ספציפית של האפליקציה הפעילה, שמקושרת ל-commit ב-Git.
- הסתעפות פעילה: ההסתעפות של מאגר GitHub שמופיעה בכתובת ה-URL הפעילה. לרוב, זהו ההסתעפות שאליה מיזגו את ההסתעפויות של התכונות או ההסתעפויות של הפיתוח.
בעיות ומגבלות ידועות
לתצוגה המקדימה של App Hosting יש כמה מגבלות ידועות:
- מחיקת הקצוות העורפיים לא פועלת.
- במקרים מסוימים, הקצה העורפי App Hosting עשוי להחזיר
Intermittent connection errorהודעות בכתובת ה-URL של האפליקציה. תיקון יהיה זמין בגרסה מאוחרת יותר. - הכותרות של Cache-Control משתנות כדי להגביל את המטמון של CDN ל-60 שניות. בעתיד, כש-App Hosting יוכל למחוק באופן סופי את המטמון במהירות במהלך הפריסה, המגבלה הזו תוסר.
- האופטימיזציה של התמונות מתבצעת ב-Cloud Run כברירת מחדל, והתמונות שעברו אופטימיזציה לא נשמרות. מומלץ להשבית את האופטימיזציה של התמונות או לציין כלי טעינה באופן ידני עד שיהיה פתרון טוב יותר.
- קבצים סטטיים שלא נשמרו במטמון מוצגים מתוך Cloud Run. בגרסה מאוחרת יותר הם יישמרו ויוצגו מהמקור App Hosting כדי לשפר את הביצועים.
- יכול להיות שמק"טים של App Hosting לא יוצגו בדף השימוש בקצה העורפי במסוף Firebase. הן יהיו זמינות במהדורה מאוחרת יותר.
- יכול להיות שמדי פעם תופיע במסוף Firebase השגיאה "build לא נמצא והוא לא חוקי" כשיוצרים קצה עורפי.
- נכון לעכשיו, לכל הקצוות העורפיים באותו פרויקט יש ארגון או חשבון GitHub. אפשר לקשר אותם למאגרים שונים באותו ארגון או חשבון. כדי ליצור קצוות עורפיים שמחוברים לחשבונות GitHub שונים, צריך לשים אותם בפרויקטים נפרדים.
- שכבת הביניים, הכתיבה מחדש וההפניות האוטומטיות של Next.js פועלות ב-Cloud Run, מאחורי ה-CDN. המפתחות האלה לא יגנו על התגובות שנשמרו במטמון, ולכן חשוב להגדיר הוראות בקרה מתאימות לתוכן שאתם מעבדים.