הגדרת תזמור קונטיינרים עם Nomad (HashiCorp)

אורקסטרציית קונטיינרים Nomad: היכן נשברת פריסה ידנית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סדר העבודות: ביקורת, תרשים, הגדרה, בדיקה, מסירה

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

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

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

מדיניות גישה לקונטיינרים, תרשיםים ונהלים

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

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

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

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

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

לפני: הפעלות ידניות בשלוש סביבות

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

אחרי: שליטה אחודה בפריסה

האורקסטרציה נבנתה על Nomad: תיאור כל שירות הפך לקובץ דקלרטיבי במאגר קוד משותף, זהה לכל הסביבות — שונה רק סט משתני הסביבה. הפריסה מופעלת בפקודה אחת, הולכת בשלבים עם בדיקת זמינות, ואם בדיקה נכשלת המערכת מחזירה בעצמה את הגרסה הקודמת, בלי תורן ובלי פקודות ידניות. זמן הפריסה הצטמצם ל-5–8 דקות, שחרורים כושלים — פחות מ-2%, התאוששות — עד 2–3 דקות באוטומציה.

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

מה לעשות אם השירותים כבר הופעלו ידנית

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

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

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

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

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

ספקות טכניים נפוצים לפני התחלה

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

איפה נשמרים הסודות?

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

האם יהיה צריך לכתוב מחדש אפליקציות?

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

מה יישאר לנו אחרי המסירה?

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

נדון במשימה ונחזור עם תוכנית מעבר

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

• רשימת שירותים וקשרים ביניהם: מה מדבר עם מה, איפה נשמר מצב משותף;
• איך השירותים מופעלים сейчас ואילו שלבים עדיין נעשים ביד;
• דרישות זמינות וחלון תחזוקה מותר;
• מגבלות תשתית: איפה ממוקמים הצמתים, אילו מערכות חיצוניות אסור לעקוף;
• כמה סביבות נדרשות, באיזו תדירות יוצאים שחרורים, מי יוזם פריסה;
• מי מצד הלקוח אחראי על הרשאות וקבלת שלבים.

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

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

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