תהליך ה-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. הוא מפעיל את סביבת העבודה של הבנייה, ומוודא שהרשאות הקובץ הנכונות מוגדרות לספריות שמשמשות בשלבי הבנייה הבאים.

מכין

השלב הזה אחראי לטיפול בלוגיקה שלפני הבנייה. הוא קורא, מנקה וכותב משתני סביבה שהוגדרו על ידי המשתמש. בנוסף, הוא מבטל את ההפניה לכל הסודות שצוינו בקובץ 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:

  1. ‫Runtime Buildpack: מוודא שכל הרכיבים הדרושים להרצה של אפליקציית Node.js בסיסית כלולים ושהתלות מותקנת.
  2. ‫Monorepo Buildpack: מגדיר buildpacks עוקבים לטיפול בתרחישים שונים של monorepo.

  3. ‫Framework Buildpack: מתקין את מתאם המסגרת הנכון (למשל Angular או Next.js) ומכין את חבילות ה-buildpack הבאות.

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

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

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

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

בשלב הסופי הזה, כל המידע שחולץ מקוד המקור של האפליקציה, בתוספת קובץ האימג' של קונטיינר ה-build, נארז ונשלח אל ה-backend של App Hosting. הקצה העורפי של 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) ולפרוס אותה.

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

מידע נוסף

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