Firebase App Hosting משתמש ב-Cloud Build כדי להפוך את קוד המקור של האפליקציה לפורמט בקונטיינר שמתאים לפריסה ב-Cloud Run.
תהליך build פועל בשלבים המרכזיים הבאים:
ubuntu: הפעלה של Workspace.
preparer: אוסף את קוד המקור וההגדרות של האפליקציה.
pre-buildpack: מכין את סביבת ה-buildpack.
build: מתקין את יחסי התלות ובונה את האפליקציה.
בעל האתר: מסיים את מאגר התגים Cloud Run בסביבת הייצור.
חמשת השלבים האלה תואמים ישירות לשלבי הבנייה שמוצגים ב-Cloud Build במסוף Google Cloud:
אתחול של Workspace
השלב הזה תואם לשלב הבנייה של Ubuntu. הוא מאתחל את סביבת העבודה של הבנייה, ומוודא שהרשאות הקובץ הנכונות מוגדרות לספריות שבהן נעשה שימוש בשלבי הבנייה הבאים.
מכין
השלב הזה אחראי לטיפול בלוגיקה שלפני הבנייה. הוא קורא, מנקה וכותב משתני סביבה שהוגדרו על ידי המשתמש. בנוסף, הוא מבטל את ההפניה לכל הסודות שצוינו בקובץ apphosting.yaml ומצמיד אותם.
Pre-buildpack
בשלב הזה מכינים את הסביבה למחזור החיים של Cloud Native Buildpacks. התהליך כולל הפעלה של shim שמתרגם את ההגדרות ואת משתני הסביבה שהוכנו בשלב הקודם לפורמט שנדרש על ידי כלי CNB.
אני רוצה לבנות
זהו ליבת תהליך ה-build, שאחראית ליצירת קובץ אימג' של קונטיינר שאפשר להריץ וקובץ bundle.yaml שמגדיר את תצורת ה-build.
הוא משתמש ב-Cloud Native Buildpacks ובקובץ הבינארי של lifecycle creator כדי לארוז את האפליקציה בצורה יעילה. מידע נוסף על קובץ bundle.yaml זמין ב-GitHub.
ה-buildpacks אחראים להמיר את קוד המקור של האפליקציה לקובצי אימג' בקונטיינרים שמוכנים לייצור. Firebase App Hosting משלב כמה buildpacks כדי להשלים את תהליך build:
- Runtime Buildpack: מוודא שכל הרכיבים הדרושים להפעלת אפליקציית Node.js בסיסית כלולים ושהתלות מותקנת.
- Monorepo Buildpack: מגדיר buildpacks עוקבים לטיפול בתרחישים שונים של monorepo.
Framework Buildpack: מתקין את מתאם המסגרת הנכון (למשל Angular או Next.js) ומכין את ה-buildpacks הבאים.
מתאמי המסגרת אחראים להרצת פקודת ה-build של גרסת הייצור ולמיפוי של ערכי הגדרה רלוונטיים שספציפיים למסגרת לפורמט סטנדרטי שניתן לקריאה על ידי App Hosting.
Package Manager Buildpack: מריץ את ההתקנה של יחסי התלות ובונה את האפליקציה באמצעות npm, yarn או pnpm.
Output Bundle Buildpack: מגדיר את פקודת ההפעלה ומכין את חבילת הפלט להרצה.
בעל תוכן דיגיטלי
בשלב הסופי הזה, כל המידע שחולץ מקוד המקור של האפליקציה, בתוספת קובץ האימג' של קונטיינר ה-build, נארז ונשלח אל ה-backend של App Hosting. הקצה העורפי (backend) של App Hosting משתמש במידע הזה כדי להגדיר את Cloud Run עם ההגדרות המתאימות.
יצירת מדיניות ניקוי
Firebase App Hosting מחיל מדיניות אוטומטית לשמירה ולניקוי של גרסאות build. בהתאם למדיניות הזו, מערכת App Hosting שומרת את הבנייה המוצלחת שלכם ואת הגרסאות המשויכות שלה מ-Cloud Run הימים האחרונים. בנוסף, כדי לוודא שתמיד תהיה לכם גרסה שאפשר לחזור אליה, App Hosting שומר את 5 הגרסאות וההשקות המוצלחות האחרונות שלכם, ללא קשר לזמן שעבר מאז ההשקה.
App Hosting לעולם לא ימחק או יסיר גרסת Build שנמצאת כרגע בפיצול תנועה פעיל או משויכת להשקה בתהליך.
כשגרסאות ישנות חורגות ממגבלות השמירה האלה, הסטטוס הפנימי שלהן מתעדכן לEXPIRED. אי אפשר לבצע חזרה מיידית לגרסה קודמת ב-EXPIREDbuild, והאפשרות לחזור לגרסאות האלה תוסר ממסוף Firebase. במקום זאת, תצטרכו ליצור גרסת build חדשה שמטרגטת את אותו מקור (commit ב-Git, מאגר תגים ב-Artifact Registry או קטגוריה ב-Google Cloud Storage) ולפרוס אותה.
אחת הדרכים לחסוך במשאבי בנייה היא לשלוט בתדירות ההפעלה של פריסות אוטומטיות. איך מנהלים השקות אוטומטיות
מידע נוסף
כל תהליך build של App Hosting הוא קוד פתוח.
- קוד ה-buildpack נמצא במאגר buildpacks של Google Cloud
- הקוד של מתאמי המסגרות נמצא במאגר firebase-framework-tools
- מידע נוסף על Cloud Native buildpacks ועל Cloud Build