יצירת תמונות זהב של מכונות וירטואליות באמצעות Packer

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשרויות בנייה של תמונות ייחוס: השוואת גישות

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

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

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

איך אנחנו בונים צינור בנייה של תמונות ייחוס

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

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

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

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

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

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

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

מה אנחנו מעבירים בסיום: תיאורים, סכמות, נהלים

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

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

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

מקרה בוחן: פחות פערים בין סביבות ושחרור מהיר יותר

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

מה שינינו

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

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

במה תמונת ייחוס שונה מהגדרה ידנית של שרת?

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

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

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

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

שאלות טכניות נפוצות על בניית תמונות ייחוס

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

איך מעדכנים תמונת ייחוס בלי זמן מושבת?

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

אצלנו השרתים מוגדרים ידנית — אפשר להעביר אותם?

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

אצלנו כבר יש צינור בנייה משלנו

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

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

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

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

נתוני פתיחה שמאיצים את הערכת ההיקף:

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

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