תהליך ה-build של App Hosting

Firebase App Hosting משתמש ב-Cloud Build כדי להפוך את קוד המקור של האפליקציה לפורמט של קונטיינר שמתאים לפריסה ב-Cloud Run.

תהליך build מתבצע בשלבים העיקריים הבאים:

  1. ubuntu: הפעלה של Workspace.

  2. הכנה: איסוף קוד המקור וההגדרות של האפליקציה.

  3. pre-buildpack: מכין את סביבת ה-buildpack.

  4. build: מתקין את יחסי התלות ובונה את האפליקציה.

  5. המוציא לאור: מסיים את מאגר התגים Cloud Run בסביבת הייצור.

חמשת השלבים האלה תואמים ישירות לשלבי הבנייה שמוצגים ב-Cloud Build במסוף Google Cloud:

צילום מסך של תצוגה של שלבי Cloud Build במסוף Google Cloud

Workspace Initialization

השלב הזה תואם לשלב הבנייה של Ubuntu. הוא מפעיל את סביבת העבודה של ה-build, ומוודא שהרשאות הגישה לקבצים מוגדרות בצורה נכונה בספריות שבהן נעשה שימוש בשלבי ה-build הבאים.

מכין

השלב הזה אחראי לטיפול בלוגיקה שלפני הבנייה. הוא קורא, מנקה וכותב משתני סביבה שהוגדרו על ידי המשתמש. בנוסף, הוא מבטל את ההפניה לכל הסודות שצוינו בקובץ apphosting.yaml ומצמיד אותם.

Pre-buildpack

בשלב הזה מכינים את הסביבה למחזור החיים של Cloud Native Buildpacks. התהליך כולל הפעלה של shim שמתרגם את ההגדרות ואת משתני הסביבה שהוכנו בשלב הקודם לפורמט שנדרש על ידי כלי CNB.

אני רוצה לבנות

זהו ליבת תהליך ה-build, שאחראית ליצירת קובץ אימג' של קונטיינר שאפשר להריץ וקובץ bundle.yaml שמגדיר את תצורת ה-build. הוא משתמש ב-Cloud Native Buildpacks ובקובץ הבינארי של יוצר מחזור החיים כדי לארוז את האפליקציה בצורה יעילה. מידע נוסף על קובץ bundle.yaml זמין ב-GitHub.

ה-buildpacks אחראים להמיר את קוד המקור של האפליקציה לקובצי אימג' בקונטיינרים שמוכנים לייצור. ‫Firebase App Hosting משלב כמה חבילות buildpack כדי להשלים את תהליך ה-build:

  1. Runtime Buildpack: מוודא שכל הרכיבים הדרושים להרצת אפליקציית Node.js בסיסית כלולים ושהתלות מותקנת.
  2. Monorepo Buildpack: מגדיר buildpacks עוקבים לטיפול בתרחישים שונים של monorepo.
  3. Framework Buildpack: מתקין את מתאם המסגרת הנכון (כמו Angular או Next.js) ומכין את ה-buildpacks הבאים.

    מתאמי המסגרת אחראים להפעלת הפקודה ליצירת גרסת ייצור ולמיפוי של ערכי הגדרות רלוונטיים שספציפיים למסגרת לפורמט סטנדרטי שניתן לקריאה על ידי App Hosting.

  4. Package Manager Buildpack: מריץ את ההתקנה של יחסי התלות ובונה את האפליקציה באמצעות npm,‏ yarn או pnpm.

  5. Output Bundle Buildpack: מגדיר את פקודת ההפעלה ומכין את חבילת הפלט להרצה.

בעל תוכן דיגיטלי

בשלב הסופי הזה, כל המידע שחולץ מקוד המקור של האפליקציה, בתוספת קובץ האימג' של קונטיינר הבנייה, נארז ונשלח אל ה-App Hostingbackend. הקצה העורפי של App Hosting משתמש במידע הזה כדי להגדיר את Cloud Run עם ההגדרות המתאימות.

יצירת מדיניות ניקוי

Firebase App Hosting מחיל מדיניות אוטומטית לשמירה ולניקוי של גרסאות build. בהתאם למדיניות הזו, מערכת App Hosting שומרת את הגרסאות המוצלחות שלכם ואת הגרסאות המשויכות שלהןCloud Run מ-14 הימים האחרונים. בנוסף, כדי לוודא שתמיד תהיה לכם גרסה שאפשר לחזור אליה, App Hosting שומר את 5 הגרסאות וההשקות האחרונות שהצליחו, ללא קשר לזמן שעבר מאז.

App Hosting לעולם לא ימחק או יסיר גרסת build שנמצאת כרגע בפיצול התנועה הפעיל שלכם או משויכת להשקה בתהליך.

כשגרסאות ישנות חורגות ממגבלות השמירה האלה, הסטטוס הפנימי שלהן מתעדכן לEXPIRED. אי אפשר לבצע חזרה מיידית לגרסת EXPIRED build, והאפשרות לחזור לגרסאות build האלה תוסר ממסוף Firebase. במקום זאת, תצטרכו ליצור גרסת build חדשה שמטרגטת את אותו מקור (commit ב-Git, מאגר תגים ב-Artifact Registry או קטגוריה ב-Google Cloud Storage) ולפרוס אותה.

דרך אחת לחסוך במשאבי בנייה היא לשלוט בתדירות ההפעלה של פריסות אוטומטיות. איך מנהלים השקות אוטומטיות

מידע נוסף

כל תהליך build של App Hosting הוא קוד פתוח.