Firebase App Hosting משתמש ב-Cloud Build כדי להפוך את קוד המקור של האפליקציה לפורמט בקונטיינר שמתאים לפריסה ב-Cloud Run.
תהליך build מתבצע בשלבים העיקריים הבאים:
ubuntu: הפעלה של Workspace.
preparer: אוסף את קוד המקור וההגדרות של האפליקציה.
pre-buildpack: מכין את סביבת ה-buildpack.
build: מתקין את יחסי התלות ובונה את האפליקציה.
המוציא לאור: מסיים את מאגר התגים Cloud Run בסביבת הייצור.
חמשת השלבים האלה תואמים ישירות לשלבי הבנייה שמוצגים ב-Cloud Build במסוף Google Cloud:
הפעלה ראשונית של Workspace
השלב הזה תואם לשלב הבנייה של Ubuntu. היא מאתחלת את סביבת העבודה של ה-build, ומוודאת שהרשאות הקובץ הנכונות מוגדרות לספריות שבהן נעשה שימוש בשלבי ה-build הבאים.
מכין
השלב הזה אחראי לטיפול בלוגיקה שלפני הבנייה. הוא קורא, מנקה וכותב משתני סביבה שהוגדרו על ידי המשתמש. בנוסף, הוא מבטל את ההפניה לכל הסודות שצוינו בקובץ 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 משלב כמה חבילות buildpack כדי להשלים את תהליך ה-build:
- Runtime Buildpack: מוודא שכל הרכיבים הדרושים להרצת אפליקציית Node.js בסיסית כלולים ושהתלות מותקנת.
- Monorepo Buildpack: מגדיר buildpacks עוקבים לטיפול בתרחישים שונים של monorepo.
Framework Buildpack: מתקין את מתאם המסגרת הנכון (למשל Angular או Next.js) ומכין את ה-buildpacks הבאים.
מתאמי המסגרת אחראים להפעלת הפקודה לבניית גרסת הייצור ולמיפוי של ערכי הגדרות רלוונטיים שספציפיים למסגרת לפורמט סטנדרטי שניתן לקריאה על ידי App Hosting.
Package Manager Buildpack: מריץ את ההתקנה של יחסי התלות ובונה את האפליקציה באמצעות npm, yarn או pnpm.
Output Bundle Buildpack: מגדיר את פקודת ההפעלה ומכין את חבילת הפלט להרצה.
בעל תוכן דיגיטלי
בשלב הסופי הזה, כל המידע שחולץ מקוד המקור של האפליקציה, בתוספת קובץ האימג' של הקונטיינר, נארז ונשלח אל ה-Backend של App Hosting. הקצה העורפי של App Hosting משתמש במידע הזה כדי להגדיר את Cloud Run עם ההגדרות המתאימות.
יצירת מדיניות ניקוי
Firebase App Hosting מחיל מדיניות אוטומטית לשמירה ולניקוי של גרסאות build. בהתאם למדיניות הזו, מערכת App Hosting שומרת את הגרסאות המוצלחות שלכם ואת הגרסאות המשויכות שלהן מ-14 הימים האחרונים.Cloud Run בנוסף, כדי לוודא שתמיד תהיה לכם גרסה שאפשר לחזור אליה, App Hosting שומר את 5 הגרסאות וההשקות האחרונות שהצליחו, ללא קשר לזמן שעבר מאז.
App Hosting לעולם לא ימחק או יסיר גרסת build שנמצאת כרגע בפיצול התנועה הפעיל שלכם או משויכת להשקה בתהליך.
כשגרסאות build ישנות חורגות ממגבלות השמירה האלה, הסטטוס הפנימי שלהן מתעדכן ל-EXPIRED. אי אפשר לבצע חזרה מיידית לגרסת build, והאפשרות לחזור לגרסאות build האלה תוסר מהמסוף Firebase.EXPIRED במקום זאת, תצטרכו ליצור גרסת build חדשה שמכוונת לאותו מקור (commit ב-git, מאגר תגים ב-Artifact Registry או קטגוריה ב-Google Cloud Storage) ולפרוס אותה.
דרך אחת לחסוך במשאבי בנייה היא לשלוט בתדירות ההפעלה של פריסות אוטומטיות. איך מנהלים השקות אוטומטיות
מידע נוסף
תהליך ה-build של App Hosting הוא קוד פתוח.
- קוד ה-buildpack נמצא במאגר ה-buildpacks של Google Cloud
- הקוד של מתאמי המסגרות נמצא במאגר firebase-framework-tools
- מידע נוסף על Cloud Native buildpacks ועל Cloud Build