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

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

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

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

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

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

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

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

הרשאות

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

  • ‫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.

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

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

המסוף

  1. במסוף Google Cloud , נכנסים לדף Compute Engine > VM Manager > Patch.

    כניסה לדף Patch

  2. לוחצים על Create patch job (יצירת עבודת תיקון).

  3. בקטע Target VMs (מכונות וירטואליות ליעד), מציינים את הקריטריונים לבחירת מכונות וירטואליות להחלת תיקון.

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

      אחרי שבוחרים את האזורים, אפשר לסנן עוד את מכונות ה-VM באזור הזה.

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

      • תחילית שם: test-
      • תוויות: env=dev ו-app=web

    2. בקטע אפשרויות אחרות, מציינים את הפרטים הבאים:

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

  4. בקטע Patch configuration (הגדרת תיקון), מגדירים את התיקון.

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

  5. בקטע Scheduling (תזמון), מבצעים את הפעולות הבאות:

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

  6. בקטע Rollout options (אפשרויות הפצה), מגדירים את אפשרויות ההפצה של הטלאי:

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

  7. אופציונלי: בקטע אפשרויות מתקדמות, אפשר לבצע את הפעולות הבאות:

  8. לוחצים על פריסה.

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

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

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

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

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

  • ב-Debian וב-Ubuntu, המערכת הבסיסית היא apt. לתיקונים שמיועדים למכונות הווירטואליות האלה, אפשר לציין dist-upgrade או שדרוג רגיל. אפשר גם להחריג חבילות ספציפיות. מידע נוסף זמין במדריכים המפורטים של Debian או במדריכים המפורטים של Ubuntu.

  • ב-SuSE, המערכת הבסיסית היא zypper, ונעשה שימוש ספציפי ב-zypper patches. לתיקונים שמיועדים למכונות הווירטואליות האלה, אפשר לציין אפשרויות כמו:

    • ‫with update: עדכון כל החבילות שלא נכללות בתיקונים
    • ‫with optional: תיקונים אופציונליים נחשבים כנדרשים
    • הקטגוריות או רמות החומרה של התיקונים שרוצים להחיל

    אפשר גם להחריג טלאים ספציפיים.

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

דוגמאות

המסוף

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

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

    אם 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 באזורים ובאזורי זמינות שמדיניות הארגון מאפשרת.

המסוף

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

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

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

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

דוגמאות

המסוף

  1. פועלים לפי השלבים שמופיעים בכרטיסייה של המסוף כדי ליצור משימת תיקון או פריסת תיקון.
  2. בקטע אפשרויות הפריסה, מגדירים את אפשרויות הפריסה:
    • בוחרים אם להחיל את התיקון על אזור אחד בכל פעם או על כל האזורים בו-זמנית.
    • מגדירים את תקציב ההפרעות. תקציב ההפרעות הוא מספר או אחוז המכונות הווירטואליות באזור שרוצים להפריע להן בו-זמנית בתהליך הטלאים.
  3. מבצעים את כל ההגדרות הנוספות שנדרשות להטמעת תיקון או לפריסה.
  4. לוחצים על פריסה.

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"
  }
}

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

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

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

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

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

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

PowerShell 

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

ניפוי באגים בעבודת תיקון

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

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

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

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

מה השלב הבא?