הגדרת מאגר GitOps (מבנה, מוסכמות, סביבות)

מאגר GitOps: מבנה שעומד בצמיחה

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

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

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

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

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

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

מה משתנה בעבודת הצוות לאחר סידור המבנה

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

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

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

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

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

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

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

סכימת המאגר היא прежде всего תשובה לשאלה מי ומתי תכופות משנה את תיאורי הסביבות. כל עוד יש מוצר אחד, והקונטורים נבדלים רק בקבוצת פרמטרים, הסכימה המונוליטית נותנת את המסלול הקצר ביותר מהעריכה ועד ליישום: מערך בדיקות אחיד, היסטוריית שינויים אחת, החזרה לאחור צפויה.

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

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

שלבי ההקמה: מהאודיט ועד למסירה לצוות

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

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

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

ארטיפקטים של מסירה: סכימות, כללים, נהלים

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

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

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

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

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

לפני: שחרור של 40 דקות והתורן בתפקיד השליח

שחרור גרסה ארך 35–45 דקות: הרכבת מניפסטים, עריכה ידנית של ערכים עבור סביבת הבדיקות והפרודקשן, ובדיקה בעין. שגיאות קונפיגורציה היוו כ-30% מכלל התקלות, וההתאוששות אחרי שחרור כושל נמשכה 25–40 דקות, כי החזרה לאחור נעשתה באותן ידיים ובאותו סדר. התורן התעורר פעמיים-שלוש בלילה, וחצי מהקריאות לא היו על קוד, אלא על פרמטרים שהתפזרו.

אחרי: הסביבות מתוארות באופן הצהרתי, הסנכרון מתבצע מעצמו

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

השחרור התקצר ל-6–8 דקות, והחזרה לאחור ל-90 שניות, כי הגרסה הקודמת מוחזרת ממצב חתום של המאגר, ולא נבנית מחדש. שיעור התקלות בגלל קונפיגורציה ירד מ-30% ל-5%, וכולן נתפסות בשלב הבדיקה לפני היישום. קריאות הלילה של התורן פחתו פי שלושה: נותרו רק כשלים של האפליקציה, ולא עבודה עם פרמטרים.

מה לעשות אם הקונפיגורציה כבר התפזרה?

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

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

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

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

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

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

כיצד יופרדו ההרשאות בין הצוותים?

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

מאגר אחד או כמה?

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

עד כמה ההחלטה הפיכה?

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

מה יקרה אחרי המסירה?

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

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

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

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

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