הגדרת GitOps לתשתית בסיסית (Bootstrap)

GitOps bootstrap: היכן נשברת תשתית הבסיס

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

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

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

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

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

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

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

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

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

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

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

אפשרויות GitOps bootstrap: מהרכבה ידנית ועד אוטומציה

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

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

כיצד עוברים בין המצבים

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

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

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

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

ארטיפקטים: ריפוזיטורים, מדיניות הרשאה, תקנונים

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

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

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

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

מקרה בוחן: תשתית המנוהלת מהריפוזיטורי

המצב לפני

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

מה שינינו

העברנו את תיאור תשתית הבסיס לריפוזיטורי: פריסה ב־Kubernetes, מדיניות רשת, מרחבי שמות (namespaces), הרשאות גישה, מאגר סודות. תיארנו גם את ה־bootstrap עצמו — סט המשאבים המינימלי שממנו נפרס כל השאר, כולל רכיב הסנכרון. כל שינוי עובר בדיקת תוכנית ב־pull request, ואת הפער מול המצב בפועל מתקן הקונטור בעצמו.

מה התוצאה

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

במה נבדלת אספקה דקלרטיבית מצינור קלאסי?

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

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

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

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

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

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

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

כיצד מוחזר שינוי כושל לאחור?

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

מי אחראי לתיקונים דחופים?

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

מה יקרה אם הריפוזיטורי או הסוכן אינם זמינים?

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

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

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

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

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