תצורת פרודקשן של GCP Compute Engine עם MIG ו-OS Login

GCP Compute Engine הגדרה: איפה הפרודקשן נשבר

הגדרת מכונות וירטואליות ב-GCP Compute Engine נשברת לא בהתחלה, אלא בצמיחה. המכונות הראשונות נבנות בידיים: בוחרים סוג, מוסיפים דיסק, רושמים מפתח SSH במטא-דאטה של הפרויקט. כל עוד יש חמישה מופעים ומהנדס אחד מנהל אותם, הסכמה מחזיקה — ומשם מתחיל פער בקונפיגורציות.

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

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

שינויים ידניים בקונסולה הם המוקש השני. מפתחות במטא-דאטה של הפרויקט שורדים עזיבה והעברת משימות: הגישה נשארת, אבל מי משתמש בה — לא ברור. OS Login סוגר את זה, אבל רק כשהוא מופעל ברמת הארגון ומקושר לתפקידים; להפעיל אותו בפרויקט בודד, מעל מפתחות ישנים, זה חסר טעם.

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

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

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

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

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

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

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

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

אפשרויות הפריסה ב-Compute Engine של Google Cloud נבדלות לא כל כך בסוג המכונה, אלא במי שאחראי לשחזור הצומת. מכונה וירטואלית בודדת נוחה כצעד ראשון: פרסת, הגדרת, העברת תעבורה.

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

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

מה זה אומר לבחירה

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

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

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

1. ביקורת פרויקט הענן. עורכים ספירת מלאי של מופעים, דיסקים, תמונות מצב, תת-רשתות, כללי גישה וחשבונות. מסירים משאבים לא בשימוש, ומצמצמים הרשאות שניתנו „לזמן מה” לתפקידים הנדרשים באמת.
2. סכמת תשתית. מתאמים את מספר האזורים, הרכב קבוצות המופעים המנוהלות (MIG) והגבולות בין סביבת בדיקות לסביבת ייצור — לפני יצירת המשאב הראשון. הסכמה מתועדת כמסמך שלפיו בודקים אחר כך את המצב בפועל.
3. בניית תבנית וקבוצות. תבנית המופע הופכת לארטיפקט מנוהל גרסאות: תמונת בסיס, דיסקים, תגיות רשת, הרכב הרשאות. גישת SSH — דרך OS Login עם חשבונות ארגוניים במקום מפתחות המופצים במטא-דאטה של הפרויקט.
4. בדיקת עמידות לתקלות. מפילים בכפייה אזור ומופע בודד: מתעדים תוך כמה זמן הקבוצה משחזרת צמתים פעילים והאם התעבורה חוזרת ללא התערבות ידנית.
5. הרצת עדכונים וחזרה לאחור. מריצים החלפה הדרגתית של מופעים עם הגבלה על מספר בלתי זמינים ובודקים חזרה לתבנית הקודמת — החזרה לאחור צריכה לקחת דקות, ולא לדרוש בנייה מחדש של הקבוצה.
6. מסירת נהלים. מוסרים סכמה, קונפיגורציות, מדיניות גישה, הוראות לפעולות שגרתיות וסדר פעולות בתקלה, ועוברים עליהם עם צוות הלקוח.

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

התשתית נשארת אצלכם כקוד ומסמכים, ולא כמהנדס שזוכר היכן ללחוץ. כל מה שאנחנו מגדירים ב-Google Cloud Compute Engine — תבניות מכונה, קבוצות מופעים מנוהלות, OS Login ומדיניות גישה — נמצא במאגר שלכם ונפרס באופן משוחזר.

• תבניות מכונה: תמונה, סוג דיסק, מטא-דאטה, בדיקת תקינות ותסריט התחלתי מתוארים באופן דקלרטיבי — גרסה חדשה עוברת רוויו כמו קוד רגיל.
• מדיניות גישה: תפקידי IAM לפי חשבונות שירות, כניסה דרך OS Login במקום מפתחות סטטיים, הפרדה בין פרודקשן לסטייג', רשימת חריגים עם נימוק.
• סכמת תשתית: רשת, תת-רשתות, כללי חומת אש, מאזן עומסים, פריסה לפי אזורים ומכסות — בקובץ אחד, קריא בלעדינו.
• תיעוד התשתית: מה נמצא איפה, אילו משתנים מוגדרים בקלט, איך להקים סביבה מאפס ואיך לפרק אותה כראוי.
• נהלי תפעול: סדר פריסת גרסה חדשה, חזרה לאחור, עדכון תמונות ורוטציית גישות — עם ציון מי עושה זאת.
• התראות ודשבורדים: מדדי קבוצת המופעים, זמינות השירות, שגיאות בעלייה — עם שיוך לאחראי.
• יומן בדיקות: אילו תרחישים הורצו (אובדן אזור, דרדור מופע, התמלאות דיסק) ומה אושר בסביבת בדיקות.

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

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

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

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

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

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

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

פעולות ידניות מהעבודה היומיומית עברו לחד-פעמיות — אישור תפקיד חדש או עריכת תבנית — וזה בדיוק מה שהפחית את שיעור העבודה הידנית בסדר גודל.

במה שונה קבוצת מכונות מנוהלת ממכונה בודדת?

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

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

איזו גישה לפרויקט נדרשת לכם?

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

מה לעשות עם מורשת ההגדרות הידניות?

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

איך בודקים ששום דבר לא ייפול?

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

נדבר על המשימה: מה דרוש להערכה ולתוכנית

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

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

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

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