כללי מדיניות גלובליים בנושא תוספים מאפשרים לכם לנהל תוספים בכמה אזורים ומיקומים בפרויקט. כשמחילים מדיניות גלובלית, VM Extension Manager מוודא שהתוספים שצוינו מותקנים ופועלים במכונות וירטואליות בכל אזור או תחום (zone) שתואמים לקריטריונים של המדיניות.
בתרשים הבא מוצג אופן השימוש במדיניות גלובלית של תוספים כדי להחיל תוספים על מכונות וירטואליות באזורים שונים בפרויקט:
כפי שמוצג בתרשים הקודם, אפשר להגדיר מדיניות גלובלית לתוספים ברמת הפרויקט. VM Extension Manager מחיל את המדיניות הזו על כל מכונות ה-VM שתואמות לקריטריונים שבחרתם. לדוגמה, אם בוחרים מכונות וירטואליות עם התווית env=prod בכל האזורים והאזורים הגיאוגרפיים בפרויקט, VM Extension Manager מחיל את התוספים שצוינו, כמו סוכן תפעול ו-Extension for SAP, רק על המכונות הווירטואליות האלה.
תוכניות השקה של כללי מדיניות גלובליים
מדיניות גלובלית משתמשת בתוכניות השקה כדי לנהל את הפריסה של תוספים באזורים ובאזורים מרובים. תוכנית השקה מאפשרת לכם לשלוט בפריסה של תוספים, וכך לצמצם את הסיכון לבעיות נרחבות. בעזרת תוכנית הפצה, אתם יכולים להגדיר את הסדר והתזמון של העדכונים כדי להבטיח הפצה הדרגתית ומבוקרת.
כשיוצרים או מעדכנים מדיניות גלובלית, אפשר לציין אחת מתוכניות ההשקה הבאות:
- השקה הדרגתית. במסגרת ההשקה הזו, התוספים נפרסים בהדרגה באזורים שונים לאורך תקופה. תקופת ברירת המחדל להשקה הזו היא חמישה ימים. הגישה הזו מומלצת כי היא מאפשרת לכם לזהות ולטפל בבעיות פוטנציאליות בהשקות מוקדמות לפני שהן משפיעות על כל הציוד.
- השקה מהירה. בפריסה הזו, התוספים נפרסים באופן מיידי בכל מכונות ה-VM המטורגטות בכל האזורים והתחומים. הגישה הזו שימושית במצבים שבהם צריך לפרוס תוסף או תיקון במהירות בסביבות שאינן סביבות ייצור.
אפשר גם להגדיר תוכניות פריסה מותאמות אישית כדי לציין את גלי הפריסה על סמך אזורים, ואת הזמן להמתנה בין הגלים. מידע נוסף זמין במאמר בנושא השיטה rolloutPlans.insert.
התנהגות במקרה של התנגשות בהשקה
כשיוצרים או מעדכנים מדיניות גלובלית לתוספים, יכול להיות שיהיה קונפליקט במצבים הבאים:
- כשיוצרים מדיניות גלובלית. מתרחש ניגוד בשם המדיניות אם כבר קיימת באזור מדיניות אזורית עם אותו שם כמו המדיניות הגלובלית.
- כשמעדכנים מדיניות גלובלית. מתרחש ניגוד בתוכן המדיניות אם מדיניות אזורית קיימת שונתה באופן עצמאי בלי קשר להשקת המדיניות הגלובלית. לדוגמה, אם משנים מדיניות אזורית באמצעות קריאה אזורית ל-API, ואחר כך מנסים לשנות את אותה מדיניות אזורית באמצעות השקה של מדיניות גלובלית, מתרחש קונפליקט.
כדי למנוע את העימותים האלה, אפשר לציין התנהגות במקרה של עימות בהשקה, שתקבע אם המדיניות הגלובלית תדרוס מדיניות אזורית שמתנגשת איתה במהלך ההשקה. אפשר לציין אחת מההתנהגויות הבאות:
- לא לדרוס (ברירת מחדל). אם לא מציינים התנהגות במקרה של קונפליקט, פריסת המדיניות הגלובלית לא דורסת מדיניות אזורית שסותרת אותה. ההגדרה של המדיניות האזורית מקבלת עדיפות באזור הזה.
- החלפה. אם מגדירים את התנהגות המדיניות במקרה של קונפליקט לערך
overwrite, המדיניות הגלובלית דורסת את המדיניות האזורית שמתנגשת איתה, וההגדרה של המדיניות הגלובלית חלה באזור הזה.
הפצת עדכונים בהדרגה ועדיפות מדיניות הן תכונות נפרדות שפועלות באופן עצמאי. מידע נוסף על עדיפות המדיניות זמין במאמר עדיפות המדיניות ופתרון קונפליקטים.
מידע נוסף על התנגשות בהשקה זמין בפרמטר conflictBehavior בשיטה globalVmExtensionPolicies.insert.
ניסיון חוזר להשקה
כשמעדכנים או מוחקים מדיניות גלובלית של תוסף, VM Extension Manager מתחיל פריסה חדשה כדי להחיל את השינויים בהתאם לתוכנית הפריסה. אם הפריסה נקטעת או אם נוספים אזורים חדשים, אפשר לנסות שוב את הפעולה על ידי הפעלת פריסה חדשה לאותה מדיניות.
ניסיון חוזר להפעלת מדיניות עדכון
הרשימה הבאה מתארת תרחישים שבהם יכול להיות שתצטרכו לנסות שוב את הפריסה של מדיניות העדכונים:
- נוספו אזורים חדשים. אם אזורים חדשים יהיו זמינים אחרי שתפעילו מדיניות גלובלית, VM Extension Manager לא יחיל באופן אוטומטי מדיניות קיימת על המכונות הווירטואליות באזור החדש. Google Cloud אפשר לנסות שוב את הפריסה של העדכון כדי להחיל את מדיניות התוסף על מכונות וירטואליות באזורים החדשים.
- חזרה לגרסה הקודמת של שינויים במדיניות אזורית אם בוצעו שינויים במדיניות אזורית באופן עצמאי – למשל, באמצעות קריאה אזורית ל-API כדי לשנות מדיניות אזורית – אפשר לנסות שוב להפעיל עדכון עם
conflictBehaviorשמוגדר ל-overwriteכדי להחיל מחדש את ההגדרה של המדיניות הגלובלית ולדרוס את השינויים במדיניות האזורית. - השקה שהופסקה. אם השקה קודמת נכשלה לפני שהסתיימה, אפשר להתחיל השקה חדשה כדי לנסות שוב את העדכון.
- האצת ההשקה. אם הטמעה מתמשכת מתקדמת לאט מדי, אפשר להתחיל הטמעה חדשה באמצעות
FAST_ROLLOUTתוכנית או תוכנית הטמעה בהתאמה אישית כדי להאיץ את תהליך העדכון.
מידע נוסף על הפרמטר retryUuid זמין במאמר בנושא השיטה globalVmExtensionPolicies.update.
כשמנסים להפעיל שוב את ההשקה, צריך לספק מזהה ייחודי אוניברסלי (UUID) כדי לזהות את בקשת הניסיון החוזר.
אפשר להשתמש בכל מחולל UUID כדי ליצור אחד. המזהה הייחודי האוניברסלי (UUID) צריך להיות בפורמט הקסדצימלי של 32 תווים, לדוגמה, a1a2a3a4-b1b2-c1c2-d1d2-d3d4d5d6d7d8.
ניסיון חוזר להפעלת מדיניות מחיקה
ברשימה הבאה מתוארים תרחישים שבהם יכול להיות שתצטרכו לנסות שוב את ההשקה כדי למחוק מדיניות:
- השקה שהופסקה. אם השקה קודמת למחיקת מדיניות הופסקה או לא הושלמה בהצלחה, אפשר להתחיל השקה חדשה כדי לנסות שוב את פעולת המחיקה.
- האצת ההשקה. אם ההשקה של המחיקה מתקדמת לאט מדי, אפשר להתחיל השקה חדשה באמצעות
FAST_ROLLOUTתוכנית או תוכנית השקה בהתאמה אישית כדי להאיץ את תהליך המחיקה.
מידע נוסף על הפרמטר retryUuid זמין במאמר בנושא השיטה globalVmExtensionPolicies.delete.
המאמרים הבאים
מידע נוסף על ניהול תוספים זמין במקורות המידע הבאים:
- התקנת תוספים למכונות וירטואליות על ידי יצירת מדיניות תוספים
- ניהול תוספים למכונות וירטואליות באמצעות כללי מדיניות לתוספים