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

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

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

מטרות

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

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

עלויות

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

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

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

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

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

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

1. 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

2. Verify that billing is enabled for your Google Cloud project.

3. Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs, if any are not already enabled.

   Roles required to enable APIs

   To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

   Enable the APIs

4. Install the Google Cloud CLI.

5. Configure the gcloud CLI to use your federated identity.

   For more information, see Sign in to the gcloud CLI with your federated identity.

6. To initialize the gcloud CLI, run the following command:

   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 כך שישתמש בפרטי הכניסה של ה-CLI של gcloud כשניגשים ל-Artifact Registry.

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

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

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

   gcloud services disable containerscanning.googleapis.com
   

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

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

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

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

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

חיבור של 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
  • המיקום של קובץ ה-Docker שרוצים ליצור, $_IMAGE_DIR

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

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

הגדרת Cloud Scheduler

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

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

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member="serviceAccount:$PROJECT_NUMBER-compute@" \
       --role="roles/cloudbuild.builds.editor"
   

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

   gcloud projects add-iam-policy-binding $PROJECT_ID \
       --member=serviceAccount:$PROJECT_NUMBER@cloudbuild. \
       --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=$PROJECT_NUMBER-compute@ \
       --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform
   

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

   כניסה ל-Cloud Scheduler

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

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

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

עיון בתוצאות

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

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

1. פותחים את הדף Artifact Registry Repositories:

   כניסה לדף Artifact Registry Repositories

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

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

   

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

   

הסרת המשאבים

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

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

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

המסוף

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

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-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.