ראנרים CI/CD בבעלות עצמית: הגדרה, אבטחה וחיסכון

למה ראנרים משלכם של CI/CD מכשילים שחרורים בעומסי שיא

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

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

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

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

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

מה נותן מערך בנייה משלכם: מהירות, בידוד, שליטה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה שינו

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

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

מה התוצאה

בנייה ממוצעת — 14 → 4 דקות, המתנה בעומסי שיא — 22 דקות → 40 שניות, שיעור ההרצות שנפלו — 18 → 5%. הרגרסיה הלילית מסתיימת לפני תחילת יום העבודה, ותיקון בגלל תקרית עובר הרצה מלאה לפני פרסום, ולא מערך בדיקות מקוצר.

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

מה לעשות אם ראנרים משלכם של CI/CD כבר פרוסים

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

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

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

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

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

שאלות טכניות שנשאלות לפני התחלה

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

האם מערך הבנייה מבודד משאר התשתית?

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

מה יקרה לשחרורים בזמן המעבר?

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

מי מתחזק את המכונות לאחר ההפעלה?

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

נדון במשימה: בנייה בלי תורים ודליפות

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

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

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