‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים ולממשקי ה-API של Google Cloud , לא צריך להגדיר אימות.
gcloud
1. התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם. אחרי שנכנסתם לחשבון, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:
  gcloud init
  הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.
הגדרת אזור ותחום כברירת מחדל.

REST

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

התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

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

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

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

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

הרשאות

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

זהירות: התפקיד "מבצע משימות תיקון" כולל את ההרשאה 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
לוחצים על יצירת משימת תיקון.
בקטע Target VMs, מציינים את הקריטריונים לבחירת המכונות הווירטואליות שרוצים לתקן.
1. בוחרים את האזור שבו נמצאים המכונות הווירטואליות שרוצים לתקן. אפשר גם לבחור את כל האזורים.
  
  אחרי שבוחרים את האזורים, אפשר לסנן את המכונות הווירטואליות באותו אזור.
  
  הערה: במסוף Google Cloud אפשר לסנן רק לפי קידומת של שם או לפי תווית. אם אתם צריכים להחיל סוגים אחרים של מסנני מכונות, השתמשו ב-Google Cloud CLI או ב-REST.
  
  לדוגמה, כדי לתקן מכונות וירטואליות ספציפיות באזורים שבחרתם, הזינו את מסנני השם והתווית באופן דומה לדוגמה הבאה:
  - תחילית שם: test-
  - תוויות: env=dev ו-app=web
2. בקטע Other options, מציינים את הפרטים הבאים:
  - Allow patching MIG instances: אם בוחרים באפשרות הזו, משימת התיקון פועלת במכונות וירטואליות שהן חלק מקבוצת מופעי מכונה מנוהלים (MIG).
  - Skip unpatchable VMs: אם בוחרים באפשרות הזו, המכונות הווירטואליות שאי אפשר להטמיע בהן תיקונים (למשל, מכונות וירטואליות שפועלות במערכת הפעלה שמותאמת לקונטיינרים) לא ייכללו בהטמעת התיקון. מידע נוסף מופיע במאמר הגדרות למכונות וירטואליות בקבוצות MIG ולמכונות וירטואליות שלא ניתן לתקן.
בקטע Patch configuration, מגדירים את התיקון.
1. מציינים שם לתיקון.
2. בוחרים את העדכונים הנדרשים למערכת ההפעלה. מידע נוסף זמין במאמר הגדרת תיקונים.
בקטע תזמון, מבצעים את הפעולות הבאות:
- בוחרים לוח זמנים. כדי להפעיל את משימת התיקון באופן מיידי, בוחרים באפשרות Start now.
- אופציונלי: מגדירים משך זמן או חלון זמן לתחזוקה.
בקטע Rollout options, מגדירים את אפשרויות ההשקה של התיקון:
- בוחרים אם לתקן אזור אחד בכל פעם או לתקן אזורים בו-זמנית.
- הגדרת תקציב לשיבושים. תקציב ההפרעה הוא המספר או האחוז של המכונות הווירטואליות באזור שאתם רוצים שיופרעו בו-זמנית על ידי תהליך התיקון.
אופציונלי: בקטע Advanced options, אפשר לבצע את המשימות הבאות:
- בוחרים אפשרות הפעלה מחדש.
- מעלים סקריפטים לפני ואחרי התיקון. למידע נוסף על סקריפטים לפני ואחרי תיקון, קראו את המאמר הגדרת סקריפטים לפני ואחרי תיקון.
לוחצים על Deploy.

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 כדי להריץ משימת תיקון חדשה. אתם צריכים להגדיר באופן מפורש את כל שדות התצורה הנדרשים, כמו שמתואר במאמרי העזרה של ה-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 צריך לציין את הזמן בשניות, אז מגדירים את הערך 5400s.
אחרי התקנת העדכונים, צריך להפעיל מחדש את המכונות בהתאם להגדרות המערכת.
במכונות וירטואליות שבהן פועל 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	מסנן 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) או לטרגט מאמרי ידע ספציפיים להחרגה. למידע נוסף על סיווג תיקונים, קראו את מאמרי העזרה של Microsoft.
ב-RHEL, ב-Rocky Linux וב-CentOS, המערכת הבסיסית היא yum.
- בתיקונים שמטרגטים מכונות וירטואליות של RHEL ו-Rocky Linux, אפשר לציין חבילות security ו-minimal.
- במכונות וירטואליות של CentOS, אין מטא-נתונים של security במאגר yum של CentOS. לכן, אין צורך לציין את האפשרות security כשמעדכנים חבילות אבטחה. אם לא מציינים חבילה, משימת התיקון מעדכנת את כל החבילות, כולל אלה עם עדכוני אבטחה.
- אפשר גם להחריג חבילות ספציפיות. מידע נוסף זמין בדפי המדריך של yum.
ב-Debian וב-Ubuntu, המערכת הבסיסית היא apt. בתיקונים שמטרגטים את המכונות הווירטואליות האלה, אפשר לציין את dist-upgrade או שדרוג רגיל. אפשר גם להחריג חבילות ספציפיות. למידע נוסף, אפשר לעיין בדפי המדריך של Debian או בדפי המדריך של Ubuntu.
ב-SuSE, המערכת הבסיסית היא zypper, ובאופן ספציפי משתמשים ב-zypper patches. לתיקונים שמטרגטים את המכונות הווירטואליות האלה, אפשר לציין אפשרויות כמו:
- ‫with update: עדכון כל החבילות שלא נכללות בתיקונים
- ‫with optional: תיקונים אופציונליים מטופלים לפי הצורך
- הקטגוריות או רמות החומרה של התיקונים שצריך להחיל
אפשר גם להחריג תיקונים ספציפיים.

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

דוגמאות

המסוף

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

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 זמין בקטע מגבלות.
‫Skip unpatchable VMs: אם מגדירים את skipUnpatchableVms לערך true, VM Manager מדלג על תיקון של מכונה וירטואלית אם מתקיים אחד מהתנאים הבאים:
- מערכת ההפעלה של המכונה הווירטואלית לא תומכת בתיקונים. לדוגמה, מערכת הפעלה שמותאמת לקונטיינרים. למידע על מערכות הפעלה נתמכות
- המכונה הווירטואלית היא חלק מ-MIG, והערך של migInstancesAllowed מוגדר ל-false.
במשימות תיקון שנוצרו באמצעות מסוף Google Cloud , האפשרות 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.

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

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

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

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

המסוף

מבצעים את השלבים שמפורטים בכרטיסייה של מסוף Google Cloud כדי ליצור הטמעת תיקון או פריסת תיקון.
בקטע Advanced options, לוחצים על Browse גם בקטע pre-patch וגם בקטע post-patch. מוצג דף של אובייקט ב-Cloud Storage.
בדף האובייקט של Cloud Storage, בוחרים את הקטגוריה של Cloud Storage שמכילה את הסקריפט, ואז בוחרים את האובייקט או הקובץ של Cloud Storage.
מבצעים הגדרות נוספות שנדרשות למשימת התיקון או לפריסה.
לוחצים על Deploy.

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 מכונות וירטואליות באזור הבא, משימת התיקון תיפסק.

דוגמאות

המסוף

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

gcloud

דוגמה 1

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

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

התקנת תיקונים בכל המכונות הווירטואליות בפרויקט
תיקון אזורים בו-זמנית
לוודא שלא יותר מ-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"
  }
}

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

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

כשמריצים משימת תיקון במכונות וירטואליות של Windows, כברירת מחדל, הכלי "ניהול תיקונים" מחיל רק את התיקונים של מערכת ההפעלה 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, בדרך כלל המשמעות היא שהשירות שלח בקשה לסוכן להתחיל בתיקון, אבל לא קיבל תשובה מהסוכן. כדאי לבדוק את הסיבות והפתרונות האפשריים הבאים:
- המופע לא פועל. כדי לפתור את הבעיה, צריך להפעיל את המכונה הווירטואלית.
- ההגדרה לא מלאה או לא תקינה. כדי לפתור את הבעיה, צריך לאמת את ההגדרה באמצעות רשימת המשימות לאימות.
- הגדרות הרשת ברשת ה-VPC או במכונה לא אפשרו לסוכן OS Config לתקשר עם OS Config API. כדי לפתור את הבעיה, צריך לבדוק את הגדרות הרשת.
אם פרטי המכונה לא מספקים מספיק מידע, אפשר לבדוק את היומנים של Cloud Logging או את מסוף היציאה הטורית. סוכן OS Config כותב את רשומות היומן שלו בשני המיקומים. ב-Cloud Logging, אתם יכולים לסנן לפי מזהה משימת התיקון כדי לראות את כל הרשומות ביומן שקשורות למשימת התיקון הזו. אפשר גם להפעיל את יומן ניפוי הבאגים על ידי הגדרת ערך המטא-נתונים של osconfig-log-level=debug ברמת המכונה הווירטואלית או ברמת הפרויקט Google Cloud .

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

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

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

המסוף

gcloud

REST

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

הרשאות

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

המסוף

gcloud

REST

מסנני מופעים

מסנני מכונות לדוגמה

הגדרת התיקון

דוגמאות

המסוף

gcloud

REST

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

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

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

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

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

המסוף

gcloud

REST

אפשרויות להשקת תיקונים

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

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

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

דוגמאות

המסוף

gcloud

REST

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

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

PowerShell

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

מה השלב הבא?

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