App Hosting מטפל בסדרה מורכבת של משימות ברקע כדי לפשט את הפריסה של האפליקציה. בדף הזה מתוארים חלקים מרכזיים בתהליך המשימות, ומפורט מידע על נקודות שבהן כדאי להתאים אישית את התהליך בהתאם לצרכים של האפליקציה.
תמיכה ב-Framework
App Hosting מספק תמיכה ב-build ובפריסה של אפליקציות אינטרנט שפותחו בפלטפורמות הבאות, ללא צורך בהגדרות:
- Next.js 13 ואילך
- Angular בגרסה 17.2 ומעלה
App Hosting מזהה את המסגרת שבה אתם משתמשים על ידי בדיקה של הקובץ package-lock.json או של קובץ נעילה אחר במאגר. אם תנסו לפרוס אפליקציית Node.js שחסר בה קובץ נעילה, תהליך היצירה וההפעלה של האפליקציה App Hosting ייכשל. אפשר ליצור את package-lock.json על ידי הרצה של npm
install בתיקיית השורש.
למתאמי המסגרת של App Hosting יש שני תפקידים מרכזיים:
- הם מנתחים את קוד המקור ואת קובצי התצורה הספציפיים למסגרת (כמו
next.config.js) כדי להבין את ההתנהגות המוגדרת של האפליקציה. - הם מריצים את פקודת ה-build של האפליקציה כדי ליצור נכסים סטטיים וליצור גרסה אופטימיזציה של האפליקציה לסביבת הייצור.
המתאמי framework יוצרים את אפליקציית Node.js באמצעות npm run build, והם פועלים בצורה הטובה ביותר עם הסקריפטים של ה-build שמוגדרים כברירת מחדל לכל framework: next build ל-Next.js ו-ng build ל-Agular. 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.
- אסימון הרשאה ייעודי של 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 הפעילה. לרוב, זהו ההסתעפות שאליה מיזגו את ההסתעפויות של התכונות או ההסתעפויות של הפיתוח.
בעיות מוכרות ומגבלות
לתצוגה המקדימה של 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. מכיוון שהן לא מגינות על תשובות שנשמרו במטמון, חשוב להגדיר הוראות בקרה מתאימות לתוכן שאתם מייצרים.