App Hosting מטפל בסדרה מורכבת של משימות ברקע כדי לפשט את הפריסה של האפליקציה. בדף הזה מתוארים חלקים מרכזיים בתהליך המשימות, ומפורט מידע על נקודות שבהן כדאי להתאים אישית את התהליך בהתאם לצרכים של האפליקציה.
שילוב מסגרת
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 יש שני תפקידים מרכזיים:
- הם מנתחים את קוד המקור ואת קובצי התצורה הספציפיים למסגרת (כמו
next.config.js) ויוצרים חבילת פלט שאפשר לעבד באמצעות שאר התשתית של אירוח האפליקציות. - הם מריצים את פקודת ה-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. השלבים העיקריים בתהליך הם:
- מקצים ל-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. מכיוון שהן לא מגינות על תשובות שנשמרו במטמון, חשוב להגדיר הוראות בקרה מתאימות לתוכן שאתם מייצרים.