הכנת הסביבה

Linux

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

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

• שליחת בקשה להצטרפות
• הפעלת ממשקי Cloud API נדרשים
• הגדרת חשבון השירות של Image Builder
• הגדרה של מדיניות הארגון בנושא קובצי אימג' מהימנים
• הגדרת רשת VPC ודרישות גישה
• הגדרת Artifact Registry

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

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

  צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:

  המסוף

  כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

  gcloud

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

     gcloud init

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

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

REST

כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

התקינו את ה-CLI של Google Cloud.

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

מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להכנת הסביבה, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

• אדמין Service Usage (roles/serviceusage.serviceUsageAdmin)
• אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin) או אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)
• אדמין של Artifact Registry (roles/artifactregistry.admin)

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

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

בקשה להצטרפות

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

חשבונות שירות שכלולים ברשימת ההיתרים

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

• חשבונות שירות בניהול המשתמשים שאתם יוצרים בפרויקט.
• חשבונות שירות שמוגדרים כברירת מחדל ש- Google Cloud יוצר בפרויקט, כמו חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine‏ ([e-mail]).

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

• סוכני שירות, כמו [e-mail].
• חשבון השירות מדור קודם של Cloud Build ([e-mail]), שנמצא בבעלות של Google ומנוהל על ידה.

מידע נוסף על הסוגים האלה של חשבונות שירות זמין במאמר סוגים של חשבונות שירות.

אם ה-build פועל כחשבון שירות בבעלות Google, ה-build לא יכול לקרוא את קובצי האימג' של קונטיינר Image Builder ב-Artifact Registry. כתוצאה מכך, צינור עיבוד הנתונים נכשל עם שגיאה מסוג permission-denied. כדי למנוע את הכשל הזה, מריצים את צינורות האספקה כחשבון שירות בניהול המשתמשים שיוצרים בפרויקט, ומציינים את חשבון השירות הזה כששולחים את הבנייה. מידע נוסף זמין במאמרים בנושא הגדרת חשבון שירות של Image Builder וחשבון שירות ברירת המחדל של Cloud Build.

הפעלת ממשקי ה-API

כדי להשתמש ב-Image Builder, צריך להפעיל את ממשקי ה-API של Compute Engine, ‏ Cloud Build, ‏ Artifact Registry, ‏ Service Usage ומנהל המשאבים. כדי להפעיל את ממשקי ה-API באמצעות מסוף Google Cloud או Google Cloud CLI, בוחרים באחת מהכרטיסיות הבאות:

המסוף

מפעילים את ממשקי ה-API של Compute Engine,‏ Cloud Build,‏ Artifact Registry,‏ Service Usage ו-Cloud Resource Manager, אם אחד מהם לא מופעל.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

הפעלת ממשקי ה-API

gcloud

מפעילים את ממשקי ה-API של Compute Engine,‏ Cloud Build,‏ Artifact Registry,‏ Service Usage ו-Cloud Resource Manager, אם אחד מהם עדיין לא מופעל:

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

gcloud services enable compute.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com serviceusage.googleapis.com cloudresourcemanager.googleapis.com

הגדרת חשבון השירות של Image Builder

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

• אדמין Compute (roles/compute.admin): ניהול של מופעים של מכונות וירטואליות, דיסקים לאחסון מתמיד ותמונות של מערכות הפעלה אורחות.
• משתמש בחשבון שירות (roles/iam.serviceAccountUser): מאפשר ל-Cloud Build לצרף את חשבון השירות למכונות וירטואליות זמניות של עובדים ומכונות וירטואליות לבדיקה.
• ‫Storage Admin (roles/storage.admin): קורא וכותב יומנים וארטיפקטים זמניים של בנייה בקטגוריית ההכנה (staging) של Cloud Storage‏ workdir.
• ‫Logging Log Writer (roles/logging.logWriter): כתיבת יומני ביצוע אל Cloud Logging.
• צפייה בשימוש בשירות (roles/serviceusage.serviceUsageViewer): בודק את מצבי השירות בפרויקט במהלך ההפעלה של צינור עיבוד הנתונים.
• Cloud Build Editor (roles/cloudbuild.builds.editor): מפעיל ומריץ משימות של Cloud Build ומייצא תמונות.
• (אופציונלי) אדמין של Artifact Registry (roles/artifactregistry.admin): העלאה של קובצי tar של תמונות מערכת הפעלה שנוצרו אל Artifact Registry.

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

כדי ליצור חשבון שירות ייעודי חדש ולהעניק את התפקידים הנדרשים באמצעות מסוף Google Cloud או ה-CLI של gcloud, בוחרים באחת מהכרטיסיות הבאות:

המסוף

מוודאים שיש לכם את תפקיד ה-IAM 'יצירת חשבונות שירות' (roles/iam.serviceAccountCreator) ואת התפקיד 'אדמין IAM בפרויקט' (roles/resourcemanager.projectIamAdmin). איך מקצים תפקידים

1. במסוף Google Cloud , נכנסים לדף יצירת חשבון שירות.

   כניסה לדף Create service account
2. בוחרים את הפרויקט הרצוי.

3. כותבים שם בשדה Service account name. השדה Service account ID במסוף Google Cloud יאוכלס בהתאם לשם הזה.

   כותבים תיאור בשדה Service account description. לדוגמה: Service account for quickstart.

4. לוחצים על Create and continue.

5. נותנים לחשבון השירות את התפקידים הבאים: Compute Engine > Compute Admin, Service Accounts > Service Account User, Cloud Storage > Storage Admin, Cloud Logging > Logs Writer, Service Usage > Service Usage Viewer, Cloud Build > Cloud Build Editor, Artifact Registry > Artifact Registry Admin.

   כדי להקצות תפקיד, בוחרים תפקיד מהרשימה Select a role.

   כדי להקצות עוד תפקידים, לוחצים על Add another role ומוסיפים את כולם.

   הערה: השדה Role קובע לאילו משאבים בפרויקט לחשבון השירות תהיה גישה. אתם יכולים לבטל את התפקידים האלה או להוסיף עוד תפקידים מאוחר יותר.
6. לוחצים על Continue.

7. בשדה Service account users role, מזינים את המזהה של חשבון המשתמש שיצרף את חשבון השירות למשאבים אחרים, כמו מכונות של Compute Engine.

   בדרך כלל מזהה המשתמש הוא כתובת האימייל של חשבון Google.

8. לוחצים על Done כדי לסיים ליצור את חשבון השירות.

gcloud

1. יוצרים חשבון שירות לצינור עיבוד הנתונים לבנייה:

   gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
       --display-name="Image Builder Service Account"
   

2. מקצים לחשבון השירות את התפקידים הנדרשים (roles/compute.admin, ‏roles/iam.serviceAccountUser, ‏roles/storage.admin, ‏roles/logging.logWriter, ‏roles/serviceusage.serviceUsageViewer ו-roles/cloudbuild.builds.editor):

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/compute.admin"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/iam.serviceAccountUser"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/storage.admin"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/logging.logWriter"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/serviceusage.serviceUsageViewer"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/cloudbuild.builds.editor"
   

3. אופציונלי: מקצים את התפקיד האופציונלי (roles/artifactregistry.admin) לחשבון השירות:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role="roles/artifactregistry.admin"
   

מחליפים את מה שכתוב בשדות הבאים:

• ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות של ה-build שרוצים ליצור. לדוגמה, custom-builder-sa.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות שלכם לבנייה.

הגדרת מדיניות ארגונית בנושא קובצי אימג' מהימנים

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

• projects/compute-image-import

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

כדי לעדכן את מדיניות הארגון:

1. במדיניות הארגון שלכם לגבי האילוץ compute.trustedImageProjects, מוסיפים את projects/compute-image-import לרשימת המוציאים לאור המורשים.
2. הוראות מפורטות להגדרת אילוצים של מדיניות הארגון זמינות במאמרים הגדרת מדיניות תמונות מהימנה וייצוא תמונה בהתאמה אישית ל-Cloud Storage.

הגדרת רשת VPC ודרישות גישה

במהלך שלבי הפיתוח והאימות, Image Builder מקצה מכונות וירטואליות זמניות של עובדים ובדיקות ב Google Cloud פרויקט. כברירת מחדל, Image Builder מחבר מכונות לרשת ה-VPC ‏default ומקצה כתובות IP חיצוניות ארעיות.

אם מציינים network או subnetwork מותאמים אישית, או מגדירים externalIP: none בקובץ המתכון imagebuilder.yaml:

• גישה פרטית ל-Google ו-Cloud NAT: אם מכונות וירטואליות של worker או של בדיקות מוגדרות עם externalIP: none (ללא כתובת IP חיצונית), צריך להפעיל גישה פרטית ל-Google ברשת המשנה של ה-VPC, כדי שהמכונות יוכלו לגשת ל-Google APIs ולשירותים של Google (כמו Cloud Storage ו-Artifact Registry). אם בשלבי ההתאמה האישית מורידים חבילות של מערכת הפעלה או תלויות ממאגרי מידע חיצוניים באינטרנט, צריך גם להגדיר Cloud NAT ברשת המשנה.
• כללים של חומת האש: מוודאים שהכללים של חומת האש ב-VPC מאפשרים תעבורת נתונים יוצאת אל ממשקי Google API ומאגרי תוכנה נדרשים. אם אתם מתכננים להתחבר למכונות וירטואליות פעילות של Worker כדי לבצע ניפוי באגים אינטראקטיבי (debug: true), ודאו שכללי חומת האש מאפשרים תעבורת נתונים נכנסת (ingress) ביציאה 22 ב-TCP. אם למכונות וירטואליות אין כתובת IP חיצונית, צריך לאפשר תעבורת נתונים נכנסת מטווח כתובות ה-IP של שרת Proxy לאימות זהויות (IAP) ‏35.235.240.0/20 להעברת TCP.

הגדרת Artifact Registry

כדי לאחסן ולנהל את קובצי האימג' של מערכת ההפעלה בהתאמה אישית, מטא-נתונים של אבטחה ואישורי המקור של Build של SLSA, צריך להגדיר מאגר גנרי ב-Artifact Registry. אחסון התמונות ב-Artifact Registry מאפשר לכם לשמור רשומה מאובטחת וקבועה של תמונות שפורסמו.

כשמגדירים יעד ב-Artifact Registry,‏ Image Builder מבצע את הפעולות הבאות:

• מייצאים את דיסק האתחול הסופי של ה-VM כקובץ tar רגיל (.tar.gz).
• העלאת קובץ ה-tar למאגר הכללי שלכם ב-Artifact Registry.
• יוצר וחותם על אישורי המקור של Build של SLSA עבור הארטיפקט כדי לקשר אותו למטא-נתונים של המקור.
• רושמים את תמונת Compute Engine שמוכנה לייצור ב-Compute Engine באמצעות ה-URI של קובץ ה-tar ב-Artifact Registry כמקור התבנית.

כדי להגדיר Artifact Registry גנרי, מבצעים את המשימות הבאות:

1. מוודאים שלחשבון השירות שמשמש להפעלת צינור עיבוד הנתונים של Image Builder יש את התפקיד Artifact Registry Admin ‏(roles/artifactregistry.admin) ברמת המאגר או הפרויקט. הוראות מפורטות זמינות במאמר הגדרת חשבון שירות של Image Builder.

2. יוצרים מאגר בפורמט generic. כדי ליצור את המאגר, מריצים את הפקודה gcloud artifacts repositories create:

   gcloud artifacts repositories create REPOSITORY_NAME \
       --repository-format=generic \
       --location=REPOSITORY_LOCATION
   

   מחליפים את ה-placeholders הבאים:

   • ‫REPOSITORY_NAME: שם למאגר הכללי. לדוגמה, custom-os-images.
   • ‫REPOSITORY_LOCATION: אזור נתמך. לדוגמה, us-central1.

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

• יצירה וניהול של צינורות באמצעות מסוף Google Cloud
• יצירה וניהול של צינורות באופן פרוגרמטי.
• איך מגדירים מתכוני התאמה אישית בסכימה של מתכוני התאמה אישית
• בודקים את המבנה של קובץ תצורת build (cloudbuild.yaml).