פתרון בעיות שקשורות לכשלים בצינורות עיבוד נתונים

Linux

הערה: Image Builder זמין לכולם, אבל כדי להשתמש בו צריך להוסיף את הפרויקט לרשימת ההיתרים. כדי לבקש גישה, צריך לשלוח את טופס בקשת הגישה או לפנות לצוות ניהול החשבון. Google Cloudרשימת ההיתרים כוללת רק את חשבונות השירות בפרויקט, ולא כוללת חשבונות שירות בבעלות Google. מידע נוסף מופיע במאמר חשבונות שירות שנכללים ברשימת ההיתרים.

אם פייפליין Image Builder נכשל במהלך שלב ההתאמה האישית, כדאי לעיין בקובצי היומן, להגדיר את דגל הניפוי האינטראקטיבי ב-worker VM או לנתח תמונות ביניים של ניפוי באגים כדי לזהות שגיאות בזמן ההידור או שגיאות בסקריפט.

לפני שמתחילים

• אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

  1. התקינו את ה-CLI של Google Cloud. אחר כך, מאתחלים את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

     gcloud init

     אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

     הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.
  2. הגדרת אזור ותחום כברירת מחדל

בדיקת ערוצי רישום ביומן

כדי לעזור לכם לאבחן כשלים ברמות שונות של הערימה, Image Builder כותב יומנים לכמה מיקומים:

• יומני Cloud Build orchestrator: הצגת השלבים ברמה גבוהה של ה-builder במסוף Cloud Build. אם שלב מסוים נכשל, מוצג קישור לספריית workdir המתאימה ב-Cloud Storage.
• יומנים של סוכן ההתאמה האישית של מכונה וירטואלית: סוכן ההתאמה האישית מתעד את הפלט הרגיל (stdout) ואת השגיאה הרגילה (stderr) של שלבי ההתאמה האישית. הכלי לארגון תהליכי עבודה מבצע סקר של הרשומות האלה ומזרים אותן ישירות ליומני המעקב של Cloud Build. אם היומן נחתך או שאתם צריכים לבדוק אותו במלואו, עוברים לקטגוריה _GCS_WORKDIR שמתאימה למזהה הבנייה.
• יומני קונסולה טורית: אם מערכת ההפעלה של האורח לא מצליחה לבצע אתחול, סוכן ההתאמה האישית לא יכול להתחיל. במקרים כאלה, כדאי לבדוק את היומנים של הקונסולה הטורית. הכלי לניהול תהליכים משדר את הפלט של היציאה הטורית של מכונת ה-VM של העובד ישירות לקטגוריית workdir של Cloud Storage. קישור לקובץ היומן הסדרתי מודפס בסוף המעקב של Cloud Build שנכשל.
• יומני רישום של מערכת ההפעלה האורחת: כדי לפתור בעיות מפורטות ברמת המערכת ב-Linux, סוכן ההתאמה האישית מעלה עותק מלא של יומן הרישום של המערכת journal לקטגוריית workdir של Cloud Storage בסוף ההרצה.

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

כברירת מחדל, אם שלב ההתאמה האישית נכשל, Image Builder מפסיק את ההרצה ומוחק מיד את ה-worker VM כדי לשלוט בעלויות.

כדי לנפות באגים בסקריפטים באופן אינטראקטיבי, אפשר להפעיל את הדגל debug. כך המכונה הווירטואלית נשארת פעילה, ואפשר להתחבר ישירות למערכת האורחת הפעילה באמצעות SSH.

הפעלת דגל ניפוי הבאגים

בקובץ imagebuilder.yaml, מגדירים את debug: true בקטע infrastructureConfig:

infrastructureConfig:
  machineType: e2-standard-4
  zone: us-central1-a
  # Enable interactive debugging
  debug: true
  instanceDurationHours: 1.5

מפעילים את הבנייה ומחכים לכשל

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

1. הכלי לניהול סוכנים משהה את ביצוע הבנייה.
2. הכלי ליצירת תמונות לא מוחק את מכונת ה-VM של העובד. הוא ימשיך לפעול בפרויקט.
3. המכונה הווירטואלית נשארת פעילה למשך הזמן שצוין במאפיין instanceDurationHours לפני שהיא מסתיימת באופן אוטומטי.

התחברות ל-worker VM כדי לבצע ניפוי באגים

בודקים את הפלט של מסוף Cloud Build כדי לאחזר את השם של מכונת ה-VM הפעילה של העובד. פותחים טרמינל ומתחברים למכונת העובד הווירטואלית באמצעות gcloud compute ssh:

gcloud compute ssh WORKER_VM_NAME \
    --zone=BUILD_ZONE \
    --project=PROJECT_ID

אם קובץ imagebuilder.yaml מגדיר את externalIP: none, מה שמוביל לכך שאין כתובת IP חיצונית, צריך לכלול את הדגל --tunnel-through-iap כדי להתחבר באמצעות העברת TCP של שרת proxy לאימות זהויות (IAP):

gcloud compute ssh WORKER_VM_NAME \
    --zone=BUILD_ZONE \
    --project=PROJECT_ID \
    --tunnel-through-iap

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

ניתוח תמונות ביניים לניפוי באגים

במקום להשאיר את worker VM פעילה באמצעות הדגל debug, אפשר לנתח את מצב הדיסק באמצעות תמונת הניפוי באגים שנוצרת אוטומטית:

1. בכל פעם ש-build נכשל עם debug: false (ברירת המחדל), כלי התזמור מייצא את דיסק האתחול המותאם אישית באופן חלקי כאימג' של Compute Engine.
2. השם של תמונת הניפוי באגים הוא image-builder-debug-image-BUILD_ID והיא משויכת למשפחת התמונות image-builder-debug-images.

3. כדי לבדוק את מערכת הקבצים, יוצרים מכונה וירטואלית זמנית באמצעות תמונת הדיסק הזו לניפוי באגים כדיסק האתחול:

   gcloud compute instances create temp-debug-vm \
       --image-family=image-builder-debug-images \
       --zone=ZONE \
       --project=PROJECT_ID
   

4. מתחברים למופע temp-debug-vm כדי לבדוק את הדיסק ולמצוא את הסיבה לכך שההתאמה האישית נכשלה.

פתרון בעיות שקשורות לפסק זמן ב-Cloud Build

אם הרצת צינור עיבוד נתונים של Image Builder נמשכת יותר זמן מהצפוי, המשימה ב-Cloud Build נעצרת ונכשלת עם הסטטוס TIMEOUT.

זמני הבנייה יכולים להשתנות, ובדרך כלל הם ארוכים יותר עבור סוגי מכונות גדולים יותר. לכן, כדאי להגדיר את הזמן הקצוב לתפוגה כך שיהיה מספיק זמן להשלמת הבנייה. אם לא מגדירים את הזמן הקצוב לתפוגה, ברירת המחדל של Cloud Build היא שעה אחת (3600s).

כדי להגדיר זמן קצוב לתפוגה ארוך יותר, מגדירים את השדה timeout ברמת השורש של הקובץ cloudbuild.yaml:

options:
  automapSubstitutions: true
  requestedVerifyOption: VERIFIED
  substitutionOption: ALLOW_LOOSE
  dynamicSubstitutions: true
  logging: CLOUD_LOGGING_ONLY

# Increase the overall build timeout (for example, 2 hours)
timeout: '7200s'

אחרי עדכון ערך הזמן הקצוב לתפוגה, מריצים מחדש את הבנייה ומוודאים שצינור הנתונים של Image Builder יכול לפעול עד הסיום.

מידע נוסף על הפרמטר timeout זמין במאמרי העזרה בנושא timeout ב-Cloud Build.