Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

יצירת תיקונים

אפשר להשתמש ב-Patch כדי להחיל תיקוני מערכת הפעלה על קבוצה של מכונות וירטואליות (VM).

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

הגדרת מכונה וירטואלית.
הפעלת עבודת תיקון

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

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

כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API, לא צריך להגדיר אימות. Google Cloud
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 .

הגדרת מכונה וירטואלית

כדי להשתמש בתכונת התיקון, מבצעים את השלבים הבאים:

בכל המכונות הווירטואליות, מגדירים את VM Manager.
במכונות וירטואליות של Windows, Google ממליצה להשבית את העדכונים האוטומטיים במכונות הווירטואליות. כך מצמצמים את העימותים בין העדכונים האוטומטיים של Windows לבין שירות התיקונים.

הרשאות

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

זהירות: התפקיד Patch Job Executor (הפעלת עבודות תיקון) כולל את ההרשאה osconfig.patchJobs.exec שמאפשרת גישה לניהול חבילות תוכנה במכונות וירטואליות. אם תעניקו את התפקיד הזה, אתם מסתכנים במתן גישה לא מכוונת למשתמשים להפעלת קוד במכונות וירטואליות. כדי לצמצם את הסיכון הזה, מומלץ לפעול לפי עקרון ההרשאות המינימליות ולתת לכל משתמש רק את הגישה הנדרשת, וגם לעקוב אחרי השימוש של המשתמשים בהרשאת ה-IAM הזו.

‫roles/osconfig.patchJobExecutor: מכיל הרשאות להפעלה, לביטול, לקבלת רשימה ולרישום של משימות תיקון. ההרשאה כוללת גם את האפשרות לראות את פרטי המופע של עבודת תיקון.
‫roles/osconfig.patchJobViewer: מכיל הרשאות לגישה לקריאה בלבד כדי לקבל ולרשום משימות תיקון. ההרשאה כוללת גם הרשאות לצפייה בפרטי מופע של עבודת תיקון.

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

gcloud projects add-iam-policy-binding project-id \
    --member user:user-id@gmail.com \
    --role roles/osconfig.patchJobExecutor

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

‫project-id: מזהה הפרויקט.
user-id: שם המשתמש של המשתמש ב-Google Workspace.

הפעלת משימות תיקון

אפשר להריץ עבודת תיקון באמצעות Google Cloud המסוף,‏ Google Cloud CLI או REST.

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

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

המסוף

במסוף Google Cloud , עוברים לדף Compute Engine > VM Manager > Patch.
כניסה לדף Patch
לוחצים על Create patch job (יצירת עבודת תיקון).
בקטע Target VMs (מכונות וירטואליות לטירגוט), מציינים את הקריטריונים לבחירת מכונות וירטואליות להחלת תיקון.
1. בוחרים את האזור שמכיל את המכונות הווירטואליות שרוצים להחיל עליהן תיקון. אפשר גם לבחור את כל האזורים.
  
  אחרי שבוחרים את האזורים, אפשר לסנן עוד יותר את מכונות ה-VM באזור הזה.
  
  הערה: במסוף Google Cloud , אפשר לסנן רק לפי קידומת שם או תווית. אם אתם צריכים להחיל סוגים אחרים של מסנני מכונות, אתם יכולים להשתמש ב-Google Cloud CLI או ב-REST.
  
  לדוגמה, כדי להחיל תיקון על מכונות וירטואליות ספציפיות באזורים שבחרתם, מזינים את שם המסנן ואת מסנני התוויות באופן דומה לזה:
  - קידומת שם: test-
  - תוויות: env=dev ו-app=web
2. בקטע Other options (אפשרויות אחרות), מציינים את הפרטים הבאים:
  - התרת תיקון של מופעי MIG: אם בוחרים באפשרות הזו, עבודת הטלאים מופעלת במכונות וירטואליות שמשתייכות לקבוצת מופעי מכונה מנוהלים (MIG).
  - דילוג על מכונות וירטואליות שלא ניתן להחיל עליהן תיקון: אם בוחרים באפשרות הזו, עבודת התיקון מדלגת על כל מכונה וירטואלית שלא ניתן להחיל עליה תיקון (לדוגמה, מכונות וירטואליות שמופעלת בהן מערכת הפעלה שמותאמת לקונטיינרים). מידע נוסף זמין במאמר בנושא הגדרות למכונות וירטואליות בקבוצות של מכונות מנוהלות (MIG) ולמכונות וירטואליות שלא ניתן לתקן.
בקטע Patch configuration (הגדרת תיקון), מגדירים את התיקון.
1. מציינים שם לתיקון.
2. בוחרים את העדכונים הנדרשים למערכת ההפעלה. מידע נוסף זמין במאמר בנושא הגדרת תיקון.
בקטע Scheduling (תזמון), מבצעים את הפעולות הבאות:
- בוחרים לוח זמנים. כדי להריץ את עבודת הטלאי באופן מיידי, בוחרים באפשרות התחלה עכשיו.
- אופציונלי: מגדירים משך או חלון זמן לתחזוקה.
בקטע Rollout options (אפשרויות הפצה), מגדירים את אפשרויות ההפצה של תיקון האבטחה:
- בוחרים אם להחיל תיקון על אזור אחד בכל פעם או על כמה אזורים בו-זמנית.
- מגדירים תקציב שיבושים. תקציב ההפרעות הוא מספר או אחוז המכונות הווירטואליות באזור שרוצים להפריע להן בו-זמנית בתהליך תיקון הבאגים.
אופציונלי: בקטע אפשרויות מתקדמות, אפשר לבצע את הפעולות הבאות:
- בוחרים אפשרות להפעלה מחדש.
- מעלים סקריפטים לפני התיקון ואחרי התיקון. מידע נוסף על סקריפטים לפני ואחרי תיקון זמין במאמר בנושא הגדרת סקריפטים לפני ואחרי תיקון.
לוחצים על פריסה.

gcloud

משתמשים בפקודה os-config patch-jobs execute כדי להריץ משימת תיקון. מחליפים את instance-filter במסנן המכונות הרצוי. למידע נוסף על מסנני מופעים, ראו מסנני מופעים.

gcloud compute os-config patch-jobs execute instance-filter

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

דוגמאות

דוגמה 1 כדי להריץ משימת תיקון עם ההגדרות הבאות:

שם המופע: instance-1
אזור: us-east1-b
תיאור: patch for instance-1

מריצים את הפקודה הבאה:

gcloud compute os-config patch-jobs execute \
    --instance-filter-names="zones/us-east1-b/instances/instance-1" \
    --description "patch for instance-1"

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

צריך להריץ את התיקון בכל המקרים בפרויקט.
משימת הטמעת התיקון צריכה להגיע לזמן קצוב לתפוגה ולעצור אחרי שעה ו-30 דקות.
אחרי התקנת העדכונים, המחשבים צריכים להפעיל מחדש את המערכת בהתאם להגדרות המערכת.
במכונות וירטואליות שמופעלת בהן Apt, תיקון הפרצות מתבצע באמצעות apt dist-upgrade.
במכונות וירטואליות שמופעל בהן Windows, צריך להחיל תיקונים רק על העדכון KB4339284.
במכונות וירטואליות שמופעלת בהן Yum, התיקון מתבצע באמצעות כלי השירות yum update-minimal --security.

מריצים את הפקודה הבאה:

gcloud compute os-config patch-jobs execute \
    --instance-filter-all \
    --duration="1h30m" --reboot-config="DEFAULT" \
    --apt-dist --windows-exclusive-patches=4339284 \
    --yum-minimal --yum-security \
    --async

REST

ב-API, יוצרים POST בקשה להפעלת משימת תיקון חדשה. צריך להגדיר באופן מפורש את כל שדות ההגדרה הנדרשים, כפי שמתואר ב<High Priority Term: מאמרי העזרה של ה-API>‏ patchJobs.execute.

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

לדוגמה, משימת תיקון שכוללת רק את שדות החובה נראית כך.

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter": instance-filter
}

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

‫project-id: מזהה הפרויקט.
‫instance-filter: פרמטרי הסינון הרצויים. למידע נוסף על מסננים של מופעים, ראו מסננים של מופעים.

דוגמאות

דוגמה 1 נניח שרוצים להריץ עבודת תיקון במכונה בשם instance1 שנמצאת ב-us-east1-b. בדוגמה הזו, אנחנו מוסיפים תיאור ומציינים שהעבודה תפעל למשך שעה ו-30 דקות. מחליפים את project-id במזהה הפרויקט.

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "description":"patch instance1 in us-east1-b",
  "duration":"5400s",
  "instanceFilter":{
    "instances":[
      "zones/us-east1-b/instances/instance1"
    ]
  }
}

דוגמה 2 משימת הטלאים הבאה בוחרת מכונות וירטואליות עם ההגדרות הבאות:

כוללים את התוויות env=dev ו-app=web.
הם בasia-east1-b או בasia-east1-c.
מתחילים בקידומת test-.

בפקודה הבאה, מחליפים את project-id במזהה הפרויקט.

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter":{
    "groupLabels":[
      {
        "labels":{
          "env":"dev",
          "app":"web"
        }
      }
    ],
    "instanceNamePrefixes":[
      "test-"
    ],
    "zones":[
      "asia-east1-b",
      "asia-east1-c"
    ]
  }
}

דוגמה 3

נניח שרוצים להריץ משימת תיקון עם ההגדרות הבאות:

צריך להריץ את התיקון בכל המקרים בפרויקט.
משימת הטמעת התיקון צריכה להגיע לזמן קצוב לתפוגה ולעצור אחרי שעה ו-30 דקות. ה-API דורש שהזמן יצוין בשניות, ולכן צריך להגדיר את הערך הזה כ-5,400 שניות.
אחרי התקנת העדכונים, המחשבים צריכים להפעיל מחדש את המערכת בהתאם להגדרות המערכת.
במכונות וירטואליות שמופעלת בהן Apt, תיקון הפרצות מתבצע באמצעות apt dist-upgrade.
במכונות וירטואליות שמופעל בהן Windows, צריך להחיל תיקונים רק על העדכון KB4339284.
במכונות וירטואליות שמופעלת בהן Yum, התיקון מתבצע באמצעות כלי השירות yum update-minimal --security.

תצטרכו ליצור את הבקשה הבאה:

בפקודה הבאה, מחליפים את project-id במזהה הפרויקט.

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
 "duration":"5400s",
 "instanceFilter":{
   "all":true
 },
 "patchConfig":{
   "rebootConfig":"DEFAULT",
   "apt":{
     "type":"DIST"
   },
   "yum":{
     "security":true,
     "minimal":true
   },
   "windowsUpdate":{
     "exclusivePatches":"4339284"
   }
 }
}

מסנני מכונות

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

סינון לפי שם: הגבלת הטמעת תיקון למכונות עם שמות ספציפיים. צריך לציין את שמות המופעים באמצעות ה-URI המלא. הפורמטים הנתמכים של URI כוללים את האפשרויות הבאות:
- ```
zones/zone/instances/instance-name
```
- ```
projects/project-id/zones/zone/instances/instance-name
```
- ```
https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/instance-name
```
סינון לפי קידומת שם: הגבלת הטמעת תיקון למכונות עם קידומת ספציפית בשם.
סינון לפי אזור: הגבלת הטמעת תיקון למכונות באזור ספציפי.
סינון לפי תווית: הגבלת הטמעת תיקון למכונות עם תוויות ספציפיות.

אפשר גם להריץ עבודות של תיקון על כל המופעים ב Google Cloud פרויקט על ידי הגדרת השדה all ב-instanceFilter ל-true. מידע נוסף זמין במאמר בנושא דוגמאות למסנני מופעים.

דוגמאות למסננים של מופעים

תרחיש	gcloud filter	מסנן API
כל המכונות בפרויקט ב- Google Cloud	--instance-filter-all	{ "instanceFilter":{ "all":"true" } }
מכונה בשם `instance1` שנמצאת בתחום `us-east1-b`.	--instance-filter-names="zones/us-east1-b/instances/instance1"	{ "instanceFilter":{ "instances":[ "zones/us-east1-b/instances/instance1" ] } }
מופעים עם הקידומת `app-`	--instance-filter-name-prefixes="app-"	{ "instanceFilter":{ "instanceNamePrefixes":[ "app-" ] } }
מופעים באזורים `us-east1-b` או `us-east1-c`	--instance-filter-zones="us-east1-b","us-east1-c"	{ "instanceFilter":{ "zones":[ "us-east1-b", "us-east1-c" ] } }
מופעים עם שילוב התווית `env=dev` ו-`app=web`, וגם מופעים עם `env=dev` ו-`app=worker`.	--instance-filter-group-labels="env=dev,app=web" --instance-filter-group-labels="env=dev,app=worker"	{ "instanceFilter":{ "groupLabels":[ { "labels":{ "env":"dev", "app":"web" } }, { "labels":{ "env":"dev", "app":"worker" } } ] } }

שילוב של מסנני מופעים

אפשר גם לשלב בין מסננים של מופעים. לדוגמה, כדי להריץ משימת תיקון למופעים עם הקידומת test-, שנמצאים באזור us-east1-c ושיש להם את התוויות env=dev ו-app=web, מריצים את הפקודה הבאה:

gcloud compute os-config patch-jobs execute \
    --instance-filter-name-prefixes="test-" \
    --instance-filter-zones="us-east1-c" \
    --instance-filter-group-labels="env=prod,app=web"

הגדרת תיקון

כשמריצים עבודת תיקון, אפשר לציין פרמטרים כדי לשלוט בתיקונים שמוחלים על המכונה הווירטואלית. פרמטרי ההגדרה של תיקון האבטחה תלויים בפלטפורמה ולעתים קרובות מועברים לכלים הבסיסיים לעדכון המערכת. התיקונים בפועל מגיעים ממאגרי החבילות (Linux) או משרת Windows Update (Windows) שהוגדר במכונה הווירטואלית.

אפשר לציין את הגדרות הטלאי הבאות למכונות הווירטואליות:

ב-Windows, מציינים את הסיווג של הטלאים להחלה (לדוגמה. Security ו-Critical) או לטרגט בסיסי ידע ספציפיים כדי להחריג אותם. מידע נוסף על סיווג תיקונים זמין במאמרי התמיכה של מיקרוסופט.
ב-RHEL, ב-Rocky Linux וב-CentOS, המערכת הבסיסית היא yum.
- לתיקונים שמופנים למכונות וירטואליות של RHEL ו-Rocky Linux, אפשר לציין חבילות security ו-minimal.
- במכונות וירטואליות של CentOS, אין מטא-נתונים של security במאגר של CentOS yum. לכן, אין צורך לציין את האפשרות security כשמעדכנים חבילות אבטחה. אם לא מציינים חבילה, הטמעת התיקון מעדכנת את כל החבילות, כולל אלה עם עדכוני אבטחה.
- אפשר גם להחריג חבילות ספציפיות. מידע נוסף זמין בדפי ההסבר של yum.
ב-Debian וב-Ubuntu, המערכת הבסיסית היא apt. לתיקונים שמיועדים למכונות הווירטואליות האלה, אפשר לציין dist-upgrade או שדרוג רגיל. אפשר גם להחריג חבילות ספציפיות. מידע נוסף זמין במדריך המפורט של Debian או במדריך המפורט של Ubuntu.
ב-SuSE, המערכת הבסיסית היא zypper, ובאופן ספציפי נעשה שימוש ב-zypper patches. לתיקוני אבטחה שמיועדים למכונות הווירטואליות האלה, אפשר לציין אפשרויות כמו:
- ‫with update: עדכון כל החבילות שלא נכללות בתיקונים
- ‫with optional: תיקונים אופציונליים נחשבים כנדרשים
- הקטגוריות או רמות החומרה של התיקונים שרוצים להחיל
אפשר גם להחריג טלאים ספציפיים.

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

דוגמאות

המסוף

פועלים לפי השלבים שמופיעים בכרטיסייה במסוף כדי ליצור משימת תיקון או פריסת תיקון.
בקטע Patch configuration (הגדרת תיקון), בוחרים את הפרמטרים של עבודת התיקון.
מבצעים את ההגדרות הנוספות שנדרשות להטמעת התיקון או לפריסה.
לוחצים על פריסה.

gcloud

לדוגמה, כדי להריץ עבודת תיקון בכל המופעים באזור northamerica-northeast1-a עם הגדרות תיקון ספציפיות למערכות הפעלה שונות, מריצים את הפקודה gcloud compute os-config patch-jobs execute:

gcloud compute os-config patch-jobs execute \
    --instance-filter-zones="northamerica-northeast1-a" \
    --apt-dist \
    --yum-security \
    --yum-minimal \
    --zypper-categories=security \
    --windows-classifications=critical,security \
    --reboot-config=default \
    --skip-unpatchable-vms

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

gcloud compute os-config patch-jobs execute --help

REST

לדוגמה, כדי להריץ עבודת תיקון בכל המכונות באזור northamerica-northeast1-a עם הגדרות תיקון ספציפיות למערכות הפעלה שונות, מריצים את הפקודה הבאה:

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute
{
    "instanceFilter":{
        "zones":[
            "northamerica-northeast1-a"
        ]
    },
    "patchConfig":{
        "apt": {
            "type": "dist-upgrade"
        },
        "yum": {
            "security": true,
            "minimal": true
        },
        "zypper": {
            "categories": ["security"]
        },
        "windowsUpdate": {
            "classifications": ["CRITICAL", "SECURITY"]
        },
        "rebootConfig": "DEFAULT"
    },
    "skipUnpatchableVms": true
}

מידע נוסף על הפרמטרים הנתמכים זמין במסמכי התיעוד של PatchConfig API.

הגדרות למכונות וירטואליות בקבוצות של מכונות מנוהלות (MIG) ולמכונות וירטואליות שלא ניתן להחיל עליהן תיקון

כדי לציין איך VM Manager מטפל במכונות וירטואליות ששייכות לקבוצת מופעי מכונה מנוהלים (MIG) או במכונות וירטואליות שמריצות מערכות הפעלה שלא תומכות בתיקון, משתמשים באפשרויות הבוליאניות הבאות בהגדרת התיקון:

הפעלת תיקון של מופעי MIG: כברירת מחדל, VM Manager לא מתקן מכונות וירטואליות שהן חלק מ-MIG. אם רוצים להחיל תיקוני אבטחה על מכונות וירטואליות בקבוצות MIG, צריך להגדיר את migInstancesAllowed ל-true. מידע נוסף על מגבלות בנושא תיקון מכונות וירטואליות ב-MIG זמין במאמר מגבלות.
דילוג על מכונות וירטואליות שלא ניתן להחיל עליהן תיקון: אם מגדירים את skipUnpatchableVms לערך true, VM Manager מדלג על תיקון של מכונה וירטואלית אם מתקיימים אחד מהתנאים הבאים:
- מערכת ההפעלה של המכונה הווירטואלית לא תומכת בתיקון. לדוגמה, מערכת הפעלה שמותאמת לקונטיינרים. מערכות הפעלה נתמכות
- המכונה הווירטואלית היא חלק מקבוצת MIG, והערך של migInstancesAllowed מוגדר ל-false.
במשימות תיקון שנוצרו באמצעות Google Cloud console, האפשרות Skip unpatchable VMs (דילוג על מכונות וירטואליות שלא ניתן לתקן) נבחרת כברירת מחדל.

אם הערך של skipUnpatchableVms הוא true, משימת התיקון מדווחת על סטטוס התיקון של מכונות וירטואליות שלא ניתן לתקן כ-SKIPPED. בנוסף, אם לא מתרחשות שגיאות אחרות, במשימת תיקון מדווח על מצב COMPLETED_WITH_INACTIVE_VMS במקום COMPLETED_WITH_ERRORS למכונות וירטואליות לא פעילות.

חלון זמן לתחזוקה

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

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

אפשרויות להפעלה מחדש

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

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

סקריפטים לפני ואחרי תיקון

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

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

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

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

אחסון סקריפטים של תיקוני אבטחה בקטגוריות של Cloud Storage

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

אם האובייקט ב-Cloud Storage לא ניתן לקריאה על ידי הציבור, צריך לוודא שלחשבון השירות שמצורף למופע יש את הרשאות ה-IAM הנדרשות לקריאת האובייקטים ב-Cloud Storage. כדי לוודא שיש לכם את ההרשאות הנכונות, צריך לבדוק את הגדרות ההרשאות באובייקט Cloud Storage.
כשבוחרים סקריפט מ-Cloud Storage באמצעותGoogle Cloud המסוף, המערכת משתמשת כברירת מחדל בגרסה האחרונה של האובייקט שצוין ב-Cloud Storage.
אם בארגון שלכם נאכף האילוץ Resource Location Restriction, אתם צריכים לאחסן את הסקריפטים בקטגוריות של Cloud Storage באזורים ובאזורי זמינות שמותרים לפי מדיניות הארגון.

המסוף

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

gcloud

לדוגמה, כדי להריץ עבודת תיקון על כל המכונות באזור northamerica-northeast1-a עם סקריפט לפני התיקון ואחרי התיקון למכונות Linux ו-Windows, מריצים את הפקודה הבאה:

gcloud compute os-config patch-jobs execute \
    --instance-filter-zones="northamerica-northeast1-a" \
    --async \
    --pre-patch-linux-executable="/tmp/pre_patch_script.sh" \
    --post-patch-linux-executable="gs://my-patch-scripts/linux/post_patch_script#1523477886880" \
    --pre-patch-windows-executable="C:\\Users\\user\\pre-patch-script.cmd" \
    --post-patch-windows-executable="gs://my-patch-scripts/windows/post_patch_script.ps1#135920493447"

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

gcloud compute os-config patch-jobs execute --help

REST

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter":{
    "zones":[
      "northamerica-northeast1-a"
    ]
  },
  "patchConfig":{
    "preStep":{
      "linuxExecStepConfig":{
        "localPath":"/tmp/pre_patch_script.sh"
      },
      "windowsExecStepConfig":{
        "interpreter":"SHELL",
        "localPath":"C:\\Users\\user\\pre-patch-script.cmd"
      }
    },
    "postStep":{
      "linuxExecStepConfig":{
        "gcsObject":{
          "bucket":"my-patch-scripts",
          "generationNumber":"1523477886880",
          "object":"linux/post_patch_script"
        }
      },
      "windowsExecStepConfig":{
        "gcsObject":{
          "bucket":"my-patch-scripts",
          "generationNumber":"135920493447",
          "object":"windows/post_patch_script.ps1"
        },
        "interpreter":"POWERSHELL"
      }
    }
  }
}

מידע נוסף על פורמטים מקובלים של קבצים מופיע בקטע ExecStepConfig במאמרי העזרה של PatchConfig API.

אפשרויות להפצת תיקון

אתם יכולים לבחור לתקן מכונות וירטואליות באזור אחד בכל פעם (אזור אחר אזור), או לתקן את כל האזורים בו-זמנית (אזורים מקבילים).

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

תקציב לשיבוש אזור

תקציב שיבושים הוא המספר המקסימלי (או האחוז המקסימלי) של מכונות וירטואליות לכל אזור שאפשר לשבש בכל רגע נתון.

מה נחשב למכונה וירטואלית שהופרעה?

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

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

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

איך פועלים תקציבים לשיבושים

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

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

דוגמאות

המסוף

פועלים לפי השלבים שמופיעים בכרטיסייה במסוף כדי ליצור משימת תיקון או פריסת תיקון.
בקטע Rollout options (אפשרויות השקה), מגדירים את אפשרויות ההשקה:
- בוחרים אם לתקן אזור אחד בכל פעם או לתקן את כל האזורים בו-זמנית.
- מגדירים את תקציב ההפרעות. תקציב ההפרעות הוא מספר או אחוז המכונות הווירטואליות באזור שרוצים להפריע להן בו-זמנית בתהליך תיקון הבאגים.
מבצעים את ההגדרות הנוספות שנדרשות להטמעת התיקון או לפריסה.
לוחצים על פריסה.

gcloud

דוגמה 1

בדוגמה הזו מוצגת הפקודה os-config patch-jobs execute להרצת עבודת תיקון עם המפרטים הבאים:

החלת תיקון על כל מכונות ה-VM בפרויקט
החלת תיקוני אבטחה על מכונות וירטואליות לפי אזור
לוודא שלא יותר מ-10 מכונות וירטואליות באותו אזור יופרעו בזמן נתון

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=zone-by-zone \
   --rollout-disruption-budget=10

דוגמה 2

בדוגמה הזו מוצגת הפקודה os-config patch-jobs execute להרצת עבודת תיקון עם המפרטים הבאים:

החלת תיקון על כל מכונות ה-VM בפרויקט
החלת תיקונים באזורים בו-זמנית
לוודא שבכל זמן נתון, לא יותר מ-50% מהמכונות הווירטואליות באותו אזור יופרעו

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=concurrent-zones \
   --rollout-disruption-budget-percent=50

REST

בדוגמה הזו מוצגת השיטה patchJobs.execute להפעלת עבודת תיקון עם המפרט הבא:

החלת תיקון על כל המכונות הווירטואליות באזורים us-central1-a,‏ us-central1-c ו-us-central1-f
החלת תיקונים באזורים בו-זמנית
לוודא שבכל רגע נתון, לא יותר מ-25% מהמופעים באותו אזור מופרעים

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter":{
    "zones":[
      "us-central1-a",
      "us-central1-c",
      "us-central1-f"
    ]
  },
  "rollout": {
    "disruptionBudget": {
      "percent": 25
    },
    "mode": "CONCURRENT_ZONES"
  }
}

מידע נוסף על הפצת תיקונים זמין בPatchRolloutמאמרי העזרה של ה-API.

הפעלת תיקון תוכנות של מיקרוסופט במכונות וירטואליות של Windows

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

כשמריצים משימת תיקון, אפשר להחיל עדכונים על תוכנות של מיקרוסופט, כמו Microsoft SQL Server,‏ SharePoint Server או .NET framework שפועלות במכונות הווירטואליות של Windows. כברירת מחדל, תיקון האפליקציות האלה מושבת כדי למנוע שיבושים בשירות וכדי להפריד בין עדכונים מתוכננים של התוכנות האלה. כדי להפעיל תיקון אוטומטי של תוכנות של מיקרוסופט, אפשר להשתמש בממשק המשתמש של Windows או ב-PowerShell.

ממשק המשתמש של Windows

בתפריט התחל של Windows, בוחרים באפשרות הגדרות > עדכון ואבטחה > Windows Update.
בקטע אפשרויות מתקדמות, מעבירים את המתג של קבלת עדכונים למוצרי Microsoft אחרים כשמעדכנים את Windows למצב מופעל.

PowerShell

 $service_manager = New-Object -ComObject 'Microsoft.Update.ServiceManager'
 $service_manager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")

ניפוי באגים של הטמעת תיקון

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

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

אם תיקון נכשל עם הסטטוס NO_AGENT_DETECTED או TIMED_OUT, בדרך כלל המשמעות היא שהשירות שלח בקשה לסוכן להתחיל בתיקון, אבל לא קיבל ממנו תשובה. כדאי לבדוק את הסיבות האפשריות הבאות ואת הפתרונות:
- המופע לא פועל. כדי לפתור את הבעיה, מפעילים את מופע ה-VM.
- כדי לוודא שההגדרה נכונה, משתמשים ברשימת הבדיקה לאימות.
- הגדרות הרשת ברשת ה-VPC או במופע לא אפשרו לסוכן OS Config לתקשר עם OS Config API. כדי לפתור את הבעיה, צריך לבדוק את הגדרות הרשת.
אם פרטי המופע לא מספקים מספיק מידע, כדאי לעיין ביומנים של Cloud Logging או במסוף היציאה הטורית. הסוכן של OS Config כותב את רשומות היומן שלו בשני המיקומים. ב-Cloud Logging, אפשר לסנן לפי מזהה עבודת התיקון כדי לראות את כל הרשומות ביומן שקשורות לעבודת התיקון הזו. אפשר גם להפעיל רישום ביומן לצורך ניפוי באגים על ידי הגדרת osconfig-log-level=debug ערך המטא-נתונים ברמת המכונה הווירטואלית או ברמת הפרויקט. Google Cloud

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

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

המסוף

gcloud

REST

הגדרת מכונה וירטואלית

הרשאות

הפעלת משימות תיקון

המסוף

gcloud

REST

מסנני מכונות

דוגמאות למסננים של מופעים

הגדרת תיקון

דוגמאות

המסוף

gcloud

REST

הגדרות למכונות וירטואליות בקבוצות של מכונות מנוהלות (MIG) ולמכונות וירטואליות שלא ניתן להחיל עליהן תיקון

חלון זמן לתחזוקה

אפשרויות להפעלה מחדש

סקריפטים לפני ואחרי תיקון

אחסון סקריפטים של תיקוני אבטחה בקטגוריות של Cloud Storage

המסוף

gcloud

REST

אפשרויות להפצת תיקון

תקציב לשיבוש אזור

מה נחשב למכונה וירטואלית שהופרעה?

איך פועלים תקציבים לשיבושים

דוגמאות

המסוף

gcloud

REST

הפעלת תיקון תוכנות של מיקרוסופט במכונות וירטואליות של Windows

ממשק המשתמש של Windows

PowerShell

ניפוי באגים של הטמעת תיקון

מה השלב הבא?

יצירת תיקונים