Blue-Green Deployment: למה שחרור שובר את הפרודקשן
תמונה קלאסית: סביבה אחת, מתאר אחד, והשחרור עולה מעל האפליקציה הפעילה. החלפת התעבורה נעשית ידנית — מהנדס עורך קונפיגורציה או מפעיל מחדש תהליכים, בעוד חלק מהמשתמשים כבר מחזיקים חיבורים פתוחים. כל שחרור הופך לחלון אי-זמינות שאיש לא מעז לנקוב באורכו מראש.
הצד השני — החזרה לאחור של השחרור. אין גיבוי מוכן של הגרסה הקודמת: האימג'ים נדרסו, סכימת הנתונים הועברה קדימה ולא מתהפכת בחזרה. אפשר להחזיר את המצב הקודם רק בבנייה חדשה ובהרצה חוזרת של מיגרציות — במקום דקה מתקבלות שעות, והכול על מתאר חי.
סביבות משולבות מוסיפות רעש: באותו אשכול חיים ריצות בדיקה, סביבת קבלה ופרודקשן, המשאבים מתחלקים, וזינוק מהבדיקות פוגע בתעבורת המשתמשים. השבתה מפסיקה להיות תרחיש חירום והופכת למצב שגרתי של שחרור.
מחיר הטעות הוא לא רק אי-זמינות. הצוות מתחיל לפחד משחרורים: פריסות נדחות לשעות הלילה, תדירות השחרורים יורדת, תיקונים ממתינים בתור, ומשוב מאחר בימים. נסביר איך זה נסגר: מה נותן מתאר מקביל, מוכנות קבועה של הסביבה השנייה והחלפת תעבורה צפויה ללא השבתה.
מה נותנת החלפה בין שתי סביבות
המכניקה פשוטה: במקביל חיות שתי סביבות — פעילה ומוכנה, והתעבורה מנותבת לאחת מהן באמצעות מתג Service או כלל Ingress. החזרה לאחור היא החלפת הסלקטור בחזרה, לא בנייה מחדש: זמן החזרה נמדד בשניות ואינו תלוי בגודל האימג' או במספר הפודים. הגרסה הקודמת נשארת פעילה וחמה, ולכן החזרה לא מלווה בזינוק שגיאות בגלל התנעה קרה.
מוכנות הסביבה ובדיקה לפני שחרור
לפני ההחלפה הסביבה החדשה צריכה להוכיח מוכנות: readiness-בדיקות מחזירות הצלחה, האפליקציה מגיבה בנתיב שירות, מריצים בדיקות עשן בנתיבים קריטיים, ובמידת הצורך — בדיקת עומס על פוד אחד.
Argo Rollouts מוסיף לכך ניתוח מדדים ישירות בתהליך השחרור: כל עוד הסביבה לא עוברת את הסף שהוגדר לשגיאות ולהשהיות, התעבורה לא מועברת אליה. אישור ידני משאירים במקומות שבהם השחרור נוגע לתשלומים או לנתונים.
מה זה נותן במונחים מדידים
ההשבתה בזמן שחרור יורדת לאפס: התעבורה מוחלפת בין קבוצות פודים שכבר פועלות, ואין חלון אי-זמינות. שיעור השחרורים המוצלחים עולה משום שהבדיקה מתבצעת לפני העברת כל התעבורה — גרסה כושלת просто לא הופכת לפעילה. זמן החזרה לאחור מתקצר לפעולת ההחלפה, ואפשר לנהל אותו בלי מהנדס תורן ובלי מעבר חוזר של בדיקות.
בנפרד נעלם סוג שלם של כשלים שקשור ל«החזרנו קוד לאחור — איבדנו נתונים»: סכימת מסד הנתונים משתנה כך שתהיה תואמת לשתי הגרסאות, והחזרה הופכת לבטוחה.
השוואת סכמות שחרור: blue-green deployment וקנארית
סכמת שחרור היא פשרה: ככל שהסיכון נמוך יותר, כך היא דורשת יותר משאבים, זמן או תשתית. ב-Kubernetes בוחרים בין ארבע אפשרויות, והמגבלות של כל אחת מופיעות לא בהדגמה, אלא בשחרור השלישי עם מיגרציית נתונים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סכמת blue-green | נדרשת חזרה מיידית באמצעות החלפת תעבורה; שירות ללא מצב או נתונים תואמים בשני הכיוונים | מלאי כפול של משאבים בזמן השחרור; ההחלפה קוטעת חיבורים ארוכים וסשנים ללא אחסון חיצוני |
| שחרור קנארי | התעבורה גדולה והטרוגנית, יש מדדים להחלטה אוטומטית על פריסה מדורגת | הפריסה והחזרה לאחור מתרחשות לאורך זמן; נדרש ניתוב אמין לפי משקלים או כותרות |
| שיקוף תעבורה בצל | רוצים לבדוק גרסה על תעבורה אמיתית בלי סיכון למשתמשים | ההעתק לא משפיע על התשובות — השוואה נבנית בנפרד; כתיבות לוואי וקריאות חוץ מבודדות |
| עדכון הדרגתי | שירותים פשוטים ללא מצב, שבהם די בהחלפת פודים אחד-אחד | אין סביבה לבדוק את השחרור כולו; גרסאות פועלות במקביל, והחזרה לאחור גם היא הדרגתית |
הסכמות אינן סותרות זו את זו: Argo Rollouts מוביל שחרור בשלבים עם השהיות וחזרה אוטומטית לאחור לפי מדדים, ולכן סכמת blue-green משלימים בפריסה קנארית, ושיקוף תעבורה בצל מציבים לפני החלפת התעבורה — כך המגבלות של כל סכמה מכוסות על ידי זו שלידה.
סדר הטמעה: מניתוח הסכמה ועד מסירה
אנחנו בונים את סדר העבודה כך שהחלפת גרסה תהפוך לפעולה שגרתית עם חזרה לאחור צפויה, ולא לאירוע עם סיכון. בכל שלב של הטמעת blue-green deployment אצל הלקוח נשאר ארטיפקט: סכמה, קונפיגורציה או נוהל.
- ניתוח השחרור הנוכחי. נסתכל איך הגרסה מגיעה לאשכול היום: מניפסטים, בעלי אימג'ים, בדיקות, זמן החזרה לאחור בפועל. התוצאה — מפת סיכונים ורשימת שינויים במתאר.
- תכנון הסכמה. שתי סביבות עם קבוצות פודים בלתי תלויות, גישה משותפת לנתונים וכלל נוקשה: תעבורה משרתת בדיוק גרסה אחת.
- הגדרת ניתוב. מחליפים סלקטורים של שירותים וכללי Ingress controller, בודקים שחיבורים נסגרים כראוי ובקשות לא הולכות לאיבוד.
- הגדרת Argo Rollouts. מתארים אובייקט שחרור עם הפניות לשירות הפעיל ולשירות המקדים, מגדירים בדיקות ושלב אישור ידני לפני העברת התעבורה.
- בדיקת מוכנות. מריצים תרחישים בסביבה המקדימה: תגובה של נתיבים קריטיים, מדדי שגיאות, לוגים, התנהגות תחת עומס.
- החלפת בדיקה וחזרה לאחור. מבצעים העברת תעבורה לצורכי תרגול וחזרה לגרסה הקודמת, תוך מדידת הזמן של כל פעולה. אם החזרה לאחור ארוכה מהצפוי — מתקנים את הסכמה.
- מסירת הנוהל. מוסרים תיעוד: איך לשחרר, איך להחזיר לאחור, מה לבדוק בתורנות, ואילו אותות נחשבים עילה להחזרת גרסה. בהמשך צוות הלקוח מנהל את השחרורים בעצמו.
קונפיגורציות, סכמות סביבות ונוהל חזרה לאחור
בסיום הלקוח מקבל לא אוסף קבצים מפוזרים, אלא חבילה מחוברת: קונפיגורציות, סכמות, נוהלים והוראות שלפיהם משמרת תורנית פועלת בלי מחבר השינויים. להלן מה בדיוק נכלל במסירה ולמה כל חלק נחוץ בתפעול.
- קבצי קונפיגורציה של פריסה: תיאורים של שתי סביבות עבודה, כללי החלפת תעבורה, מגבלות משאבים ובדיקות מוכנות — במאגר עם היסטוריית שינויים, לא על המחשב של המהנדס.
- סכמת סביבות: אילו סביבות קיימות, במה הן שונות בהרכב ובנתונים, איך עובר זרם התעבורה בזמן החלפה ואיפה נשארת נקודת כניסה לחזרה.
- מדיניות גישה: תפקידים לקריאה ולשינוי, מי רשאי להחליף תעבורה, מי רק צופה, סדר רוטציה של גישות וסודות.
- נוהל חזרה לאחור: תנאי הפעלה, האחראי להחלטה, זמן יעד לחזרה לגרסה הקודמת והתנהגות חיבורים פעילים ברגע ההחלפה.
- הוראה לתורן: תרחיש בעמוד אחד — מאותת הניטור ועד אישור התוצאה, עם ציון היכן לבדוק מצב ולאן לפנות במקרה של ספק.
- מפת נראות: סט מדדים וספים שלפיהם נראית הידרדרות של הגרסה החדשה, ורשימת נמעני התראות.
- סדר עבודה עם סכמת נתונים: כללי תאימות של שינויים, כדי שהחזרת קוד לא תשבור מיגרציות שכבר הוחלו.
חבילה כזו מסירה את התלות במומחה מסוים: החלפה וחזרה לאחור ניתנות לשחזור לפי מסמך, לא לפי זיכרון.
ניתוח הטמעה: איך קיצרנו את חלון אי-הזמינות
מה היה לפני
שירות בן עשרה מיקרו-שירותים ב-Kubernetes שוחרר פעם בשבועיים, ורק בחלון לילה. שחרור אחד ארך 3-4 שעות: שליש מהזמן הוקדש להחלפת תעבורה ידנית, חימום מתארים ובדיקות, ובמקרה של שגיאה בבנייה החדשה השירות נכנס לכשל למשך 20-40 דקות — עד שהתורן החזיר את האימג' לאחור והרים את המתאר הקודם. הצטברו עד שבעה אירועים כאלה ברבעון.
מה שינינו ומה נהיה
הקמנו מתאר שני עם קונפיגורציה זהה, והוצאנו את החלפת התעבורה לרמת הניתוב לפי סכמת blue-green, ואת ניהול הפריסה העברנו ל-Argo Rollouts.
הגרסה החדשה קיבלה תחילה חלק מהתעבורה ורק אחר כך את הזרם הראשי; קריטריוני הקידום והחזרה לאחור הוגדרו במדדים: שיעור שגיאות, זמן תגובה, מצב בדיקות המוכנות. אם המדדים חרגו מהסף, הפריסה נעצרה מעצמה, והתעבורה חזרה למתאר הקודם בלי מעורבות התורן.
זמן השחרור התקצר מ-3-4 שעות ל-20-25 דקות, וחלון הלילה הפסיק להיות חובה. מספר התקריות בשחרורים ירד משבעה ברבעון לאחת, ושיעור החזרות לאחור ללא השבתה הגיע ל-100%: החזרה לגרסה הקודמת אורכת פחות מדקה ולא מנתקת חיבורים של משתמשים. את הזמן שהתפנה הצוות העביר לבדיקות בסביבת הבדיקות.
מה לעשות אם צינור השחרורים כבר פרוס?
אין צורך לבנות מחדש את כל הצינור הפעיל. Blue-green משתלב כשלב נפרד בשחרור: הבנייה, הבדיקות והאימותים נשארים במקומם, ורק אופן אספקת הגרסה לאשכול משתנה. התהליך הקודם ממשיך לעבוד עד שהחדש יעבור בדיקה על שירות אחד.
מעבר הדרגתי מתחיל מהאשכול ומהסביבות. לצד המתאר הפעיל מקימים קבוצת פודים שנייה עם קונפיגורציה זהה, שנבדלת רק בתוויות; החלפת התעבורה נופלת על Service, והפצה משוקללת — על Ingress או service mesh. מכסות ומגבלות מחושבות מיד לשני מתארים, אחרת הסביבה הירוקה תדחוק את הכחולה תחת עומס.
המגבלה המרכזית היא תאימות סכמות הנתונים. מכינים מיגרציות לפי עקרון ההרחבה: קודם מוסיפים שדות וטבלאות, מלמדים את הקוד לקרוא את שני הפורמטים, ורק בשחרור הבא מסירים את הישן. אז שתי הגרסאות עובדות מול מסד נתונים אחד, וההחלפה לא דורשת עצירה.
העברת השחרור נעשית בגלים: תחילה שירות ללא מצב, אחר כך תורים ומשימות רקע, ובסוף — הליבה. חזרה לאחור היא החזרת התעבורה למתאר הקודם תוך שניות, בלי בנייה מחדש של האימג' ובלי הרצה חוזרת של בדיקות. הפיתוח לא נעצר: שני המתארים חיים באותו אשכול, והצינור בונה לאותו ענף.
לפני הגל הראשון בודקים בדיקות מוכנות, התנהגות חיבורים ארוכים וסדר החלת מיגרציות — אחרת ההחלפה תקטע סשנים פתוחים. בהמשך הסכמה משוכפלת לשאר השירותים בלי שינויים בתהליכים הרגילים של הצוות.
שאלות טכניות נפוצות לפני ההתחלה
Blue-green ב-Kubernetes נראה פשוט: שתי סביבות, החלפת תעבורה ברמת השירות, וחזרה לאחור על ידי החזרת המצביע. בפועל הפתרון נתקל בארבע שאלות — מה בדיוק לשכפל, מה לעשות עם מסד נתונים משותף, איך להפריד סודות, ובמה להוכיח שהגרסה הירוקה בריאה לפני ההחלפה. להלן תשובות קצרות למה שעולה הכי часто בהתחלה.
האם צריך לשכפל את כל התשתית?
לא — רק את שכבת האפליקציות: עומס העבודה, ההגדרות שלו וכללי הניתוב. מסד הנתונים, התורים, המטמון והאחסון נשארים משותפים, והסביבה השנייה פונה אליהם דרך חשבונות וקידומות נפרדים.
מה קורה למסד הנתונים בזמן ההחלפה?
הסכמה משתנה במיגרציות מרחיבות, תואמות לשתי גרסאות הקוד: שדות חדשים מוסיפים מראש, וישנים מסירים רק אחרי הוצאת הגרסה הקודמת. אז החזרה לאחור נוגעת לאפליקציה ולא דורשת החזרת נתונים לאחור.
איך מפרידים בין סודות ומפתחות?
לכל סביבה סט משלה, שמחובר מאחסון חיצוני ולא מוטמע במניפסטים. הרוטציה מתבצעת בנפרד, ולכן ההחלפה לא גוררת הנפקה מחדש של מפתחות ותיקונים סינכרוניים בשתי הסביבות.
איך לוודא שהגרסה הירוקה בריאה, והאם העומס לא יוכפל?
לפני ההחלפה היא עוברת בדיקות מוכנות, תרחישים סינתטיים וזרם בצל על חלק מהתעבורה; מדדים וטרייסינג מושווים לנוכחיים. משאבים לזמן הבדיקה מוקצים מעבר לרגיל — השיא מתוכנן מראש, וצמתים מיותרים מוסרים מיד אחרי ההחלפה.
נדבר על המשימה ונחזור עם הערכה
כדי שהערכת הזמנים ותוכנית העבודה יתבססו על עובדות ולא על ניחושים, אנחנו צריכים תמונת מצב קצרה של המתאר שלכם: איך בנוי השחרור, מה מגביל אותו ומה קריטי לא לשבור בזמן עדכון. אפשר לדון במשימה בצורה חופשית — נבהיר פרטים בשיחה עם מהנדס שיוביל את הפרויקט בהמשך, ונחזור עם הערכה ושלבים.
השיחה זורמת מהר יותר כשכבר ברור:
- איך משחררים עדכונים היום: צעדים ידניים, מי מאשר, מה קורה בין הבנייה לסביבת העבודה;
- מה אסור לאבד בזמן ההחלפה: סשנים פעילים, משימות רקע, מצב המטמון והתורים;
- ממה מורכבת הסביבה: אשכולות, מאגר אימג'ים, תלויות חוץ וגישות;
- דרישות לחזרה לאחור: תוך כמה זמן צריך לחזור לגרסה הקודמת ומי נותן את הפקודה;
- מה כבר קיים באוטומציה: תיאור האפליקציה, מניפסטים, כללי בנייה ובדיקות;
- מגבלות: חלונות שחרור, מצב תחזוקה, תיאומים עם אבטחה וצוותים סמוכים.
אם מדובר ב-blue-green deployment, נדבר בנפרד על איך שתי גרסאות מתקיימות זו לצד זו ולפי איזה סימן מתקבלת ההחלטה על החלפה וחזרה לאחור.
לפי הנתונים הראשוניים האלה אנחנו מרכיבים את היקף העבודה, הערכת הזמנים וסדר השלבים — וחוזרים עם תוכנית עבודה שאפשר להתחיל ממנה, בלי אי-בהירויות בתחילת הפרויקט.