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

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

במדריך הזה תלמדו איך ליצור צינור נתונים אוטומטי שיעזור לכם לוודא שאתם כוללים עדכוני אבטחה ותיקוני באגים בתמונות של תחנות העבודה המותאמות אישית שלכם.

מטרות

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

1. יוצרים מאגר ב-Artifact Registry כדי לאחסן את התמונה המותאמת אישית ולסרוק אותה.
2. מגדירים את GitHub עם Google Cloud כדי לאחסן את הגדרות התמונות.
3. יוצרים טריגר לפיתוח גרסת Build של Cloud Build כדי לבצע אוטומציה של יצירה ופריסה של תמונות בהתאמה אישית ב-Artifact Registry.
4. הגדרת Cloud Scheduler כדי ליזום בנייה על בסיס קבוע.
5. בודקים את התוצאות של התהליכים האוטומטיים.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Cloud Build
• Cloud Scheduler
• Container Scanning
• Artifact Registry

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

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

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

כדי לאתחל את gcloud CLI, מריצים את הפקודה הבאה:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

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

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

כדי לאתחל את gcloud CLI, מריצים את הפקודה הבאה:

gcloud init

הכנת הסביבה

לפני שממשיכים, צריך להגדיר את משתני הסביבה הבאים.

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

   PROJECT_ID=$PROJECT_ID
   

2. מגדירים את שם המשתמש ב-GitHub שבו מתכננים לאחסן את המאגר:

   GITHUB_USER=$GITHUB_ID
   

3. מגדירים את המשתנים PROJECT_NUMBER ו-REGION לשימוש בתהליך:

   PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
       --format='value(projectNumber)')
   
   REGION=$REGION
   

   בדוגמה הקודמת, מחליפים את $REGION בשם האזור שבו רוצים להשתמש – לדוגמה, us-central1.

   מידע נוסף על האזורים הזמינים מופיע במאמר מיקומים של Cloud Workstations.

יצירת מאגר Artifact Registry

במדריך הזה משתמשים ב-Artifact Registry כדי לאחסן ולסרוק את התמונות.

1. יוצרים מאגר באמצעות הפקודה הבאה:

   gcloud artifacts repositories create custom-images \
         --repository-format=docker \
         --location=$REGION \
         --description="Docker repository"
   

   מחליפים את $REGION בשם האזור שבו אתם מתכננים להשתמש.

2. מגדירים את Docker כך שישתמש בפרטי הכניסה שלכם ב-gcloud CLI כשניגשים ל-Artifact Registry.

   gcloud auth configure-docker $REGION-docker.pkg.dev
   

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

   כדי להשבית את Artifact Analysis, מריצים את הפקודה הבאה:

   gcloud services disable containerscanning.googleapis.com
   

הגדרת מאגר ב-GitHub

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

חיבור מאגר לדוגמה

כדי ליצור עותק (fork) של מאגר לדוגמה שמספק הגדרות של מאגרי תמונות, פועלים לפי השלבים הבאים:

1. לוחצים על הקישור הזה כדי ליצור העתק חדש של מאגר software-delivery-workshop.
2. אם מתבקשים, נכנסים לחשבון GitHub.
3. בוחרים את שם המשתמש ב-GitHub כבעלים. שם המאגר מופיע כ-software-delivery-workshop.
4. לוחצים על יצירת הסתעפות וממתינים כמה שניות עד שהתהליך יסתיים.

חיבור Cloud Build ל-GitHub

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

• חיבור Cloud Build למאגר GitHub

אם אתם משתמשים בפתרון אחר למאגרי Git, תוכלו גם לפעול לפי ההוראות לחיבור Cloud Build ל-GitLab או ל-Bitbucket.

יצירת טריגר לפיתוח גרסת Build ב-Cloud

מאגר הדוגמה מכיל הגדרת קונטיינר ותצורת Cloud Build שמשמשת ליצירת קובץ אימג' של קונטיינר. בשלב הזה יוצרים טריגר לפיתוח גרסת Build של Cloud Build שמריץ את ההוראות בקובץ cloudbuild.yaml שנמצא בתיקייה labs/cloudbuild-scheduled-jobs/code-oss-java.

gcloud builds triggers create manual \
    --name=custom-image-trigger \
    --repo=$GITHUB_USER/software-delivery-workshop \
    --repo-type=GITHUB \
    --branch=main \
    --build-config=labs/cloudbuild-scheduled-jobs/code-oss-java/cloudbuild.yaml \
    --substitutions=_REGION=$REGION,_AR_REPO_NAME=custom-images,_AR_IMAGE_NAME=code-oss-java,_IMAGE_DIR=labs/cloudbuild-scheduled-jobs/code-oss-java

TRIGGER_ID=$(gcloud builds triggers list \
    --filter=name="custom-image-trigger" --format="value(id)")

בדוגמה הזו מוגדרות ההגדרות הבאות:

• הפקודה gcloud ב-CLI יוצרת טריגר ידני ב-Cloud Build בשם custom-image-trigger, כפי שמצוין בדגל name בשורה השנייה.
• שלוש השורות הבאות מכילות דגלים שקשורים למאגר המקור ב-GitHub:
  • הנתיב למאגר
  • סוג המאגר
  • הסתעפות Git לבנייה
• הדגל build-config מציין את הנתיב לקובץ Cloud Build במאגר Git.

• כדי להפוך את העבודה לדינמית, משתמשים בדגל substitutions. במקרה של המשרה הזו, הפקודה מעבירה את המשתנים הבאים:

  • אזור, $_REGION
  • שם מאגר Artifact Registry, ‏ $_AR_REPO_NAME
  • שם קובץ האימג' של הקונטיינר, $_AR_IMAGE_NAME
  • המיקום של קובץ ה-Dockerfile לבנייה, $_IMAGE_DIR

  כדי לראות איך המשתנים האלה משמשים בתהליך, אפשר לעיין בקובץ cloudbuild.yaml.

• אחרי יצירת הטריגר, השם הייחודי של הטריגר מאוחזר ונשמר במשתנה הסביבה $TRIGGER_ID לשימוש עתידי.

הגדרת Cloud Scheduler

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

1. מקצים תפקיד נדרש לחשבון השירות שמוגדר כברירת מחדל כדי להפעיל טריגר לפיתוח גרסת Build של Cloud Build:

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:$[e-mail]" \
       --role="roles/cloudbuild.builds.editor"
   

2. מקצים לחשבון השירות ב-Cloud Build את התפקיד הנדרש כדי להעלות תמונות ל-Artifact Registry:

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member=serviceAccount:$[e-mail] \
       --role="roles/artifactregistry.admin"
   

3. יוצרים את המשימה של Cloud Scheduler באמצעות הפקודה הבאה:

   gcloud scheduler jobs create http run-build \
       --schedule='0 1 * * *' \
       --uri=https://cloudbuild.googleapis.com/v1/projects/$PROJECT_ID/locations/global/triggers/$TRIGGER_ID:run \
       --location=us-central1 \
       --oauth-service-account-email=$[e-mail] \
       --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform
   

4. המשימה מוגדרת להפעלה פעם ביום, אבל כדי לבדוק את התכונה באופן מיידי, מפעילים את המשימה באופן ידני מ-Cloud Scheduler:

   כניסה ל-Cloud Scheduler

   1. בדף Cloud Scheduler, מחפשים את הרשומה שיצרתם שנקראת run-build.
   2. בעמודה 'פעולות', לוחצים על סמל האפשרויות הנוספות more_vert
   3. כדי לבדוק את המערכת באופן ידני, לוחצים על Force a job run (הפעלת משימה בכוח).

   4. אחרי שהפקודה תופעל בהצלחה, עוברים לדף ההיסטוריה של Cloud Build כדי לבדוק את ההתקדמות:

      כניסה להיסטוריית Cloud Build

עיון בתוצאות

הפעלתם את Container Scanning API כחלק מתהליך ההגדרה, ולכן Artifact Registry סורק באופן אוטומטי את התמונות כדי לזהות נקודות חולשה באבטחה.

כדי לבדוק את נקודות החולשה:

1. פותחים את הדף Artifact Registry Repositories (מאגרי Artifact Registry):

   מעבר אל Artifact Registry Repositories

2. ברשימת המאגרים, לוחצים על מאגר.

3. לוחצים על שם התמונה. הסכומים הכוללים של נקודות החולשה לכל תקציר תמונה מופיעים בעמודה Vulnerabilities.

   

4. כדי לראות את רשימת נקודות החולשה בתמונה, לוחצים על הקישור בעמודה Vulnerabilities (נקודות חולשה). ברשימת נקודות החולשה מוצגים חומרת נקודת החולשה, הזמינות של תיקון והשם של החבילה שמכילה את נקודת החולשה.

   

הסרת המשאבים

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

כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם בדף הזה, חשוב לזכור למחוק משאבים שכבר אין לכם צורך בהם.

כדי למחוק פרויקט Google Cloud ממסוף Google Cloud או מ-gcloudCLI:

המסוף

זהירות: כשמוחקים פרויקט:

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

gcloud

זהירות: כשמוחקים פרויקט:

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

כדי למחוק Google Cloud פרויקט:

gcloud projects delete PROJECT_ID

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

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

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