אפשרויות אחסון של יומני בנייה

כשמריצים גרסאות build, ‏ Cloud Build אוסף ושומר את יומני ה-build שלכם בקטגוריית יומנים. על סמך ההגדרות בקובץ התצורה של ה-build, יומני ה-build מאוחסנים בקטגוריות של Cloud Logging, בקטגוריות של Cloud Storage או בשני המיקומים. אפשר גם להגדיר את הסוג של קטגוריית Cloud Storage או של Cloud Logging שמכילה את היומנים. המיקום והסוג של ה-bucket משפיעים על היכולת שלכם לנתח את יומני הבנייה ועל מידת השליטה שלכם בהגדרות ה-bucket.

סקירה כללית

כשמגדירים את קובץ התצורה של ה-build, כדאי לקחת בחשבון את הנקודות הבאות:

  • אם רוצים לשלוט בתקופת השמירה של יומני הבנייה המאוחסנים, צריך לשלוח אותם אל Logging. בנוסף, כלי הצפייה ביומנים ב-Logging מספק יותר אפשרויות לחיפוש יומני בנייה ספציפיים בקטגוריה בהשוואה ל-Cloud Storage. עם זאת, כשמשתמשים ב-Logging, יכול להיות שיהיה עיכוב בין הרגע שבו נוצר יומן הרישום של build לבין הרגע שבו הוא מתקבל ב-Logging.

  • אם רוצים לקצר את זמן האחזור בין הרגע שבו נוצר יומן build לבין הרגע שבו הוא מתקבל ב-Logging, צריך לשלוח את יומני ה-build לקטגוריה ב-Cloud Storage.

הבעלות על הדלי משפיעה גם על האופן שבו אפשר לבצע אינטראקציה עם יומני הבנייה המאוחסנים. לדוגמה, קטגוריה בבעלות משתמש מאפשרת לכם להגדיר את ההגדרות של הקטגוריה, בעוד שקטגוריות בבעלות Google Cloudנוצרות על ידי Google Cloudומשתמשים לא יכולים לשנות אותן. Google Cloudב-Logging וב-Cloud Storage יש כמה אפשרויות להגדרת סוג הקטגוריה שמקבלת את יומני הבנייה.

מיקומי קטגוריות

מגדירים את השדה logging בקובץ הגדרות ה-build כדי לקבוע לאן יישלחו יומני ה-build:

  • ‫GCS_ONLY: יומני Build נשלחים לקטגוריות של Cloud Storage.
  • ‫CLOUD_LOGGING_ONLY: יומני הבנייה נשלחים לקטגוריות ביומן ב-Logging.
  • ‫LEGACY: יומני הבנייה נשלחים לקטגוריות בשני המיקומים. אם הערך של logging לא מוגדר, Cloud Build משתמש בערך הזה.
  • ‫NONE: יומני הבנייה לא נשמרים.

אם אתם שולחים את יומני ה-build ל-Logging, תוכלו לקרוא מידע על אפשרויות של קטגוריות ב-Logging במאמר הגדרת ניתוב ב-Cloud Logging. אם אתם שולחים את יומני הבנייה ל-Cloud Storage, בסעיף הבא מופיע מידע על הקטגוריות הזמינות ב-Cloud Storage. בקטע שיקולים לגבי בעלות על קטגוריה מפורטים היתרונות והשיקולים לגבי קטגוריות על סמך הבעלות עליהן, ללא קשר למיקום שלהן.

אפשרויות של קטגוריות ב-Cloud Storage

אם יומני ה-build נשלחים ל-Cloud Storage, ‏ Cloud Build מעריך את השדות logsBucket ו-defaultLogsBucketBehavior בקובץ ההגדרות של ה-build כדי לקבוע את סוג הקטגוריה ב-Cloud Storage שמקבלת את יומני ה-build.

השדה logsBucket יכול להכיל כל סוג של קבוצת משנה. אם מוגדר logsBucket, היומנים תמיד נשלחים לקטגוריה הזו ב-Cloud Storage, בלי קשר לערך של defaultLogsBucketBehavior. אם logsBucket לא מוגדר, המערכת משתמשת בערך של defaultLogsBucketBehavior באופן הבא:

  • ‫REGIONAL_USER_OWNED_BUCKET: יומני Build נשלחים לקטגוריה שנוצרה על ידי Cloud Build ונמצאת בבעלות המשתמש ב-Cloud Storage. הקטגוריה הזו נמצאת בפרויקט של המשתמש ומשתמשת באותו אזור כמו הבנייה.
  • ‫LEGACY_BUCKET: יומני ה-Build נשלחים לקטגוריה שנוצרה על ידי Cloud Build ושנמצאת בבעלות של Google Cloudבפרויקט שנמצא בבעלות של Google Cloud. הערך הזה זהה למצב שבו השדה הזה לא מוגדר.

אחסון יומנים כשיוצרים מ-Dockerfiles

כדי להגדיר אחסון של יומן ה-build כשמבצעים build מ-Dockerfile, צריך לכלול אחד מערכי הדגל default-buckets-behavior כשמריצים את הפקודה gcloud builds submit:

  • ‫regional-user-owned-bucket: יומני Build נשלחים לקטגוריה שנוצרה על ידי Cloud Build ונמצאת בבעלות המשתמש ב-Cloud Storage. הקטגוריה הזו נמצאת בפרויקט של המשתמש ומשתמשת באותו אזור כמו הבנייה.
  • ‫legacy-bucket: יומני ה-Build נשלחים לקטגוריה שנוצרה על ידי Cloud Build ושנמצאת בבעלות של Google Cloudבפרויקט שנמצא בבעלות של Google Cloud. הערך הזה זהה למצב שבו השדה הזה לא מוגדר.

שיקולים לגבי בעלות על קטגוריה

בין אם אתם משתמשים ב-Cloud Storage או ב-Logging, מומלץ לשלוח את יומני הבנייה לקטגוריה שנמצאת בבעלות המשתמש. יכול להיות שזו קטגוריה שנוצרה על ידי משתמש (לדוגמה, אם הגדרתם את logsBucket לקטגוריה שיצרתם), או קטגוריה שנוצרה על ידי Cloud Build אבל נמצאת בבעלות המשתמש (לדוגמה, אם הגדרתם הגדרות לקטגוריה אזורית שנמצאת בבעלות המשתמש). כך תוכלו לערוך מאפיינים מסוימים של מאגר הנתונים ולצפות ביומנים במאגר הנתונים בכל שלב. מאחר שמאגרי מידע בבעלות Google Cloudנמצאים בפרויקטים בבעלותGoogle Cloud, אי אפשר לראות או לערוך את מאגרי המידע האלה, ואפשר לראות את יומני הבנייה שלהם רק בקטע Build log בדף Build details.

באופן כללי, דליים שנוצרו על ידי משתמשים מספקים את הגמישות הגדולה ביותר מבחינת הגדרת ההגדרות של הדלי, גם במהלך יצירת הדלי וגם אחרי היצירה. עם זאת, במקרה הזה, תמיד צריך לוודא שהקטגוריה שיצרתם תואמת לצרכים של הגרסה. במקרים מסוימים, כמו ניהול אזורים של קטגוריות, שימוש בקטגוריה שנוצרה על ידי Cloud Build ובבעלות המשתמש מאפשר לשלוח יומני build לקטגוריה שזמינה ב-Cloud Storage כברירת מחדל ותמיד באותו אזור כמו ה-build. בקטע הבא מוסבר בהרחבה על תרחיש השימוש הזה:

שיקולים לגבי אזורים של קטגוריות

מומלץ להגדיר את מאגר ה-build כך שיתאים לאזור ה-build, כי ההגדרה הזו עשויה לעזור לכם לעמוד בדרישות של שמירת נתונים. אם רוצים ליישר את האזורים בדרך הזו, כדאי לשים לב לנקודות הבאות:

  • קטגוריות שמשתמשים יוצרים ב-Logging וב-Cloud Storage משתמשות באזור שמוגדר במהלך יצירת הקטגוריה. אם הגדרתם קטגוריה שנוצרה על ידי משתמש כערך logging של ה-build, אתם צריכים לוודא שהאזור שלה תואם לאזור ה-build.

  • אם הגדרתם את יומן הבנייה לשימוש בקטגוריות אזוריות בבעלות המשתמש ב-Cloud Storage, יומני הבנייה תמיד יישלחו לקטגוריה באותו אזור של הבנייה.

  • ‫Buckets בבעלותGoogle Cloudמוגדרים לאזור שמוגדר על ידי Google Cloud. כתוצאה מכך, יכול להיות שהאזור הזה לא תמיד יתאים לאזור של הגרסה.

הוספת defaultLogsBucketBehavior לקובצי תצורת build קיימים

אם אתם מוסיפים את האפשרות defaultLogsBucketBehavior לקובץ build.config קיים שבו הגדרתם בעבר את logging או logsBucket, מומלץ לבדוק את כל הגדרות האחסון של היומנים כדי לוודא שהיומנים מאוחסנים כמו שרציתם. ‫Cloud Build מתעלם מ- defaultLogsBucketBehavior אם מתקיים אחד מהתנאים הבאים:

  • הערך של logging הוא CLOUD_LOGGING_ONLY או NONE.
  • הערך של logging הוא GCS_ONLY או LEGACY, והמאפיין logsBucket מוגדר.

אם מריצים build בלי להגדיר שדות לאחסון יומנים בקובץ ההגדרות של ה-build,‏ Cloud Build מגדיר את logging ל-LEGACY.

המאמרים הבאים