סקירה כללית של Image Builder

‫Image Builder הוא כלי הצהרתי להתאמה אישית של קובצי אימג' של מערכת הפעלה (OS), שפועל בפרויקט Google Cloudבאמצעות Cloud Build. השירות מאפשר לבנות, להתאים אישית ולאמת תמונות דיסק של מערכת הפעלה באופן אוטומטי, כדי לוודא שהן מופעלות בצורה תקינה ועומדות בדרישות ההגדרה שלכם לפני שאתם מפרסמים אותן לעומסי עבודה של ייצור.

יתרונות מרכזיים

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

  • אוטומציה של יצירת תמונות של מערכת הפעלה: אפשר ליצור ולתחזק תמונות של מערכת הפעלה בהתאמה אישית באמצעות מתכוני YAML דקלרטיביים ותהליכי עבודה אוטומטיים של Cloud Build, בלי צורך בסקריפטים בהתאמה אישית או בכלים חיצוניים. מכיוון ש-Image Builder פועל בתוך Cloud Build, אפשר להשתמש בטריגרים של Cloud Build כדי להפעיל אוטומטית יצירת תמונות באירועים של מאגר (כמו Git push או תג), להגדיר לוחות זמנים חוזרים (למשל, יצירת תמונות שבועית לתיקוני אבטחה) או להגיב להודעות Pub/Sub (כדי להפעיל יצירת תמונות באופן פרוגרמטי מתהליכי עבודה חיצוניים או מ-webhook).
  • אימות תמונות לפני פרסום: חשוב לאמת את התמונות לפני שמפרסמים אותן. בדיקות שסופקו על ידי Google מאמתות שהתמונות הביניים מופעלות, תומכות בהפעלה מאובטחת (כשזה רלוונטי), טוענות את מנהלי ההתקנים הנדרשים ברשת ומריצות סוכן אורח תקין.
  • מעקב אחרי הרצת סקריפט: מעקב אחרי הקוד שמופעל במהלך צינור עיבוד הנתונים של ה-build. כדי לשמור על נתיב ביקורת, Image Builder מתעד באופן אוטומטי את גיבוב SHA-256 הקריפטוגרפי של סקריפטים מותאמים אישית מוטבעים בתוך יומני הבנייה.
  • משלמים רק על המשאבים שבהם נעשה שימוש: שירות Image Builder זמין ללא עלות נוספת. תחויבו רק על משאבי החישוב, האחסון והבנייה הבסיסיים שנצרכים בזמן הפעלת צינורות הנתונים.

איך פועל Image Builder

‫Image Builder פועל בתוך הפרויקט Google Cloud באמצעות קונטיינר של Cloud Build לתזמור. תהליך ה-build של התמונה כולל את השלבים הבאים:

  1. אימות והכנה: קובץ ה-YAML נבדק על ידי קונטיינר התיזמור כדי לוודא שהתחביר שלו תקין, שכל ממשקי ה-API הנדרשים מופעלים ושהרשאות האבטחה של ניהול הזהויות והרשאות הגישה (IAM) פעילות.
  2. הכנת סביבת העבודה והדיסק: קונטיינר האורקסטרטור מארכב את ספריית סביבת העבודה של Cloud Build ‏ (/workspace) שמכילה את קוד המקור וההגדרות שלכם לקובץ tar דחוס (.tar.gz) ומעלה את קובץ ה-tar הזה לקטגוריית workdir ב-Cloud Storage שצוינה בהגדרות ה-build. לאחר מכן, קובץ המערכת של ספק ההקצאה של ההתאמה האישית, שעבר קומפילציה סטטית, משמש את קונטיינר Orchestrator כדי ליצור תמונה זמנית של Compute Engine, שמגדירה את דיסק הנתונים המשני שמצורף למכונת ה-VM של העובד.
  3. הפעלת worker VM: קונטיינר האורקסטרטור מפעיל מכונת VM ארעית של Worker באמצעות תמונת המקור שצוינה כדיסק האתחול, ומצרף את דיסק הנתונים המשני שמכיל את כלי ההקצאה של ההתאמה האישית. מאפייני החומרה של המכונה הווירטואלית של העובד, רשת ה-VPC, רשת המשנה והקצאת כתובת IP חיצונית – כתובת IP ציבורית ארעית או ללא כתובת IP חיצונית – נקבעים לפי הגדרות infrastructureConfig בקובץ imagebuilder.yaml.
  4. התאמה אישית: סקריפט לטעינה בזמן ההפעלה מטעין את דיסק הנתונים ומתחיל את מנהל ההקצאות (provisioner) של ההתאמה האישית ב-worker VM. כלי ההקצאה מוריד את ארכיון סביבת העבודה ומחיל את ההתאמות האישיות שהצהרתם עליהן, כמו הפעלת סקריפטים של מעטפת, העתקת קבצים או קומפילציה של מנהלי התקנים. הוא גם מבצע מעבר של ניקוי אבטחה כדי לנקות מפתחות SSH, מזהי מכונה ייחודיים והיסטוריית יומנים. לאחר מכן, המערכת מכבה את המופע.
  5. אימות (בדיקה): קונטיינר האורקסטרטור יוצר תמונת מערכת הפעלה זמנית לבדיקה מדיסק האתחול המותאם אישית, ומקצה מכונות וירטואליות זמניות לבדיקה באמצעות הגדרות הרשת והתשתית בקובץ imagebuilder.yaml, כדי להריץ את בדיקות האימות הבאות שמוגדרות על ידי המערכת:
    • אימות של דרייבר Intel IDPF: מוודא שמופעים נתמכים טוענים את דרייבר הרשת של פונקציית נתיב הנתונים של תשתית Intel ‏ (idpf) ולא דרייברים כלליים של תצוגה או דרייברים חלופיים.
    • אימות של רשתות ונציג אורח: מאשר שהשירות של נציג האורח פעיל, שיש לפחות ממשק רשת אחד שאינו מסוג loopback, ושמות הרשתות תואמים למוסכמות (eth* או en*).
    • אימות של הפעלה מאובטחת: מוודא שההפעלה המאובטחת של UEFI פעילה ושהמערכת אוכפת אימות של ליבת האורח.
    • השהיה או חידוש של האימות: השהיית מכונת ה-VM לבדיקה באמצעות Compute Engine API ואימות שחיבור הרשת שוחזר אחרי החידוש ללא הפעלה מחדש של המערכת.
  6. הפצה: אם כל בדיקות האימות עוברות בהצלחה, קונטיינר התיזמור מכין את התמונה הסופית:
    • אם Artifact Registry מוגדר: קונטיינר האורקסטרטור מייצא את דיסק האתחול המותאם אישית כקובץ tar למאגר כללי של Artifact Registry, ויוצר את תמונת הייצור הסופית של Compute Engine באמצעות ה-URI של Artifact Registry כמקור.
    • אם Artifact Registry לא מוגדר: קונטיינר של כלי התזמור יוצר את תמונת Compute Engine ישירות בפרויקט באמצעות דיסק האתחול המותאם אישית.

שיקולי תמחור ומכסות

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

  • ‫Compute Engine: חיובים על מכונות וירטואליות של עובדים, מכונות וירטואליות לבדיקה ודיסקים לאחסון מתמיד שמצורפים.
  • ‫Cloud Build: חיובים על דקות זמן ריצה של קונטיינר של כלי התזמור.
  • ‫Cloud Storage: חיובים על ארכיונים של Workspace, ייצוא יומנים ונכסים זמניים.
  • ‫Artifact Registry: חיובים על אחסון קובצי tar של תמונות שיוצאו, אם הוגדר.
  • תמונות בהתאמה אישית: חיובים על אחסון של תמונות ביניים לבדיקה, לניפוי באגים ולייצור.

למידע מפורט על עלויות משאבים, אפשר לעיין במאמרי התמחור של Compute Engine,‏ Cloud Build,‏ Cloud Storage,‏ Artifact Registry ואחסון תמונות בהתאמה אישית.

דרישות מכסה

מוודאים שלפרויקט יש מכסות מספיקות של מעבד (CPU) ב-Compute Engine ושל דיסק מתמשך באזור שבו מריצים את הבנייה. המכסה לא מספיקה באזור היעד, ולכן הצינור נכשל במהלך הקצאת מכונות וירטואליות.

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