ArgoCD ללא GitOps: מדוע מצב האשכול סוטה מהמאגר
לרוב ArgoCD נכנס לאשכול כדשבורד מצב נוח: רואים מה פרוס, רואים אי-התאמות, אבל שינויים עדיין מבוצעים בידיים. במהלך חקירת תקרית מישהו מעלה את מספר הרפליקות, מרחיב את המגבלות או מחליף אימג' ישירות באשכול — «זמנית, כדי שיהיה מהיר יותר». הפאץ' נשאר במצב החי, ובמאגר איש לא זוכר אותו.
כך מתחילה סחיפת קונפיגורציה: המצב בפועל מפסיק להתאים למתואר במאגר. כל עוד הסנכרון לא מופעל, אי-ההתאמה אינה מורגשת — האפליקציה עובדת, המדדים תקינים. אבל די להפעיל סנכרון אוטומטי, והאשכול יחזור לגרסה מהמאגר ואיתה יאבד השינוי העקיף שעליו נשענת עבודת השירות.
בהמשך אי-ההתאמה במצב מצטברת: פאצ'ים זמניים נערמים זה על זה, תיקונים ידניים באשכול הופכים לחלק מסביבת העבודה, ולמקור האמת נשאר תיקון שאיש לא תיעד. חזרה לשחרור קודם בסכימה כזו גם היא לא מצילה — במאגר מתוארת קונפיגורציה שאינה זו שעבדה בפועל.
המחיר — השבתה לא מתוכננת ברגע הכי פחות מתאים: בזמן פריסה, חזרה לאחור או אתחול לילי של צומת. ArgoCD ללא לופ סגור של GitOps נשאר מראה, ולא מנגנון ניהול. בואו נפרק איך סוגרים את זה.
מה נותנת אספקה מנוהלת: מהירות, חזרה לאחור ויכולת חיזוי
מקור אמת יחיד — תיאור דקלרטיבי של אפליקציות ותשתית במאגר. האשכול מובא למצב הזה אוטומטית, והאי-התאמה מתגלה ומטופלת בלי מהנדס תורן. זו נקודת ההתחלה שממנה נגזרים כל שאר האפקטים.
זמן החזרה לאחור מפסיק להיות תלוי באישורים ובתיקונים ידניים: זוהי פעולה אחת של חזרה למצב מתועד קודם, שאורכה דומה להחלה רגילה של שינויים.
שיעור הפריסות המוצלחות עולה משום שהסדר והבדיקות מתוארים מראש ואחידים לכל הקונטורים — סביבת הבדיקות מפסיקה להיות שונה מסביבת הפרודקשן באופן האספקה. עבודה ידנית פוחתת: המהנדס לא מרכיב שחרור לפי הוראה, אלא מאשר שינוי שכבר עבר בדיקות.
היסטוריית השינויים מפסיקה להיות בעל-פה. לכל תיקון יש מחבר, סיבה וקשר למשימה, וגם החזרה לאחור משאירה עקבות ברורים באותה מידה. מכאן צומחת יכולת החיזוי של השחרורים: הצוות יודע מראש מה בדיוק ובאיזה רגע יופיע באשכול, ויכול להראות זאת בכל נקודת זמן.
יש לציין בנפרד סוג כשל שנמנע — «בסביבת הבדיקות זה עבד, בקונטור הפרודקשן הקונפיגורציה אחרת». תיקון באשכול תוך עקיפת המאגר הופך לאנומליה גלויה, ולא לנורמה נסתרת, ומבחינים בו לפני שהוא מגיע למשתמשים.
ArgoCD בסכימה כזו רק מבצע את מה שקבוע במאגר — לכן מצב הסביבה משוחזר, ולא משוחזר מהזיכרון. בדיוק את המדדים האלה אנחנו מודדים בקבלה: זמן החזרה לאחור, שיעור הפריסות המוצלחות ומספר הפעולות הידניות לשחרור.
מצבי אספקת שינויים: סנכרון מהמאגר וחלופות
מצב סנכרון הוא מדיניות ברמת האפליקציה: האם הבקר עוקב אחרי אי-ההתאמה בין האשכול למאגר ומה הוא עושה כשהיא מתגלה. ממנה תלוי מי לוחץ «לפרוס»: צינור הבנייה, המהנדס התורן או הבקר עצמו.
ב-ArgoCD אלה שתי הגדרות בלתי תלויות — סנכרון אוטומטי והתאוששות עצמית, והשילובים שלהן נותנים מודלים שונים של אספקה.
הבחירה כמעט תמיד נתקלת במחיר הטעות: בקונטור הבדיקות הוא נמוך, בפרודקשן — לא. להלן האפשרויות שביניהן באמת בוחרים כשהשירותים והאשכולות הופכים ליותר מאחד.
| מצב אספקה | מתי מתאים | מגבלות |
|---|---|---|
| פריסה אוטומטית עם התאוששות עצמית | קונטור בדיקות, שינויים קטנים ותכופים, נכונות לתקן מהר | תיקונים ידניים באשכול לא שורדים — הבקר מוחק אותם; מניפסט שגוי נפרס בלי השהיה |
| פריסה לפי מוכנות האימג' (הצינור מעדכן את התג במאגר) | השחרור צריך לצאת מיד לאחר הבנייה והבדיקות | תלוי בזמינות מאגר האימג'ים; אי-התאמה בין התג למניפסט מתגלה לא מיד |
| אישור ידני לשחרור (סנכרון אוטומטי כבוי) | קונטור פרודקשן עם חלונות לשינויים | אי-ההתאמה מצטברת, נדרש תורן; סטיות מתגלות מאוחר יותר |
| תבנית אחת לכמה אשכולות | קונטור בדיקות ופרודקשן עם מניפסטים זהים | טעות בתבנית מתפשטת לכל האשכולות בבת אחת |
כלל מעשי: סנכרון אוטומטי היכן שהחזרה לאחור זולה מהאישור, אישור ידני — היכן שמחיר הטעות גבוה מהמהירות. אפשרות ביניים — סנכרון לפי לוח זמנים או עם התעלמות משדות מסוימים: הבקר לא נוגע במה שכלים אחרים משנים, ולא נלחם בהם.
איך מתנהלת ההטמעה: מניתוח האשכול ועד מסירת הנהלים
הטמעת GitOps אינה התקנה של ArgoCD באשכול, אלא ארגון מחדש של האופן שבו שינויים מגיעים לפרודקשן. סדר השלבים חשוב מהמהירות: בלי סקר מלאי ותכנית מחושבת של מאגרים, הסנכרון יתחיל לסטות מהמצב בפועל כבר אחרי שבוע.
- סקר מלאי של האשכול. אוספים עומסי עבודה, מרחבי שמות, קישורי תפקידים ותיקונים ידניים דרך kubectl. מתעדים אי-התאמות בין המניפסטים למצב החי — זהו היקף העבודה האמיתי.
- תכנית המאגרים. מפרידים בין קונפיגורציית האפליקציות לסביבות, קובעים מבנה תיקיות וגבולות אחריות של צוותים. ממנה תלוי כמה אישורים ידניים יישארו בכל פריסה.
- הגדרת הסנכרון. מחברים את ArgoCD, מתארים Application ו-AppProject, מפעילים סנכרון אוטומטי ושחזור מצב לאחר תיקונים ידניים. סודות עוברים ל-Git רק בצורה מוצפנת.
- בדיקת מדיניות. מגבילים בפרויקטים את מרחבי השמות וסוגי המשאבים הזמינים, מפעילים ולידציה של מניפסטים ב-review. שגיאת קונפיגורציה נתפסת לפני ההגעה לאשכול, והעלות נקבעת לאחר אבחוןהרצת בדיקה. מריצים את השחרור בסביבת הבדיקות, ואחר כך על שירות לא קריטי בפרודקשן: בודקים זמן סנכרון והתנהגות בזמן חזרה לאחור. את החזרה לאחור בודקים בהחזרת קומיט, ולא בפקודות ידניות.
- מסירה לתחזוקה. מוסרים נהלים, מתארים תפקידים והרשאות, ומראים לתורן איך לקרוא את מצב הסנכרון ומה לעשות כששחרור נתקע.
לאחר הקבלה הצוות מוציא שינויים בקומיט, ואנחנו נשארים בתמיכה של השחרורים הראשונים.
מה מוסרים לידיים: מניפסטים, תפקידים, נהלים ותרשימים
אנחנו מוסרים לא אוסף צ'ארטים, אלא קונטור עובד: Argo CD כבר מוגדר, המאגרים מקושרים, המהנדס התורן יכול לשחזר את הסביבה, להחזיר שחרור לאחור ולראות מי שינה מה. להלן מה שנשאר בדיוק בידי צוות הלקוח יחד עם קוד המקור והגישה לאחסון הקונפיגורציות.
- מניפסטים וקונפיגורציות — תיאורים של אפליקציות ושל קבוצות אפליקציות עם מדיניות סנכרון: סנכרון אוטומטי, שחזור לאחר תיקונים ידניים באשכול, מחיקת משאבים שכבר אין ב-Git. מקור אמת יחיד — המאגר, ולא האשכול החי.
- מודל תפקידים ומדיניות גישה — פרויקטים עם הגבלה לפי מאגרים, מרחבי שמות וסוגי משאבים; חיבור לכניסה אחודה ולקבוצות, הרשאה נפרדת לסנכרון בפרודקשן.
- תרשים הסביבות — מפה של פיתוח, קדם-פרודקשן ופרודקשן: אילו ענפים ושכבות מותאמות מתאימים להם, באיזה סדר מתבצעת הפריסה ואיפה הקונפיגורציות נבדלות ביודעין.
- נוהל שחרור — סדר שלב-אחר-שלב: סקירת השינוי, מיזוג, סנכרון, בדיקת בריאות השירותים, החלטה על חזרה לאחור ותיעוד התוצאה.
- עבודה עם סודות — היכן נשמרים פרטי הגישה, במה מפענחים בתוך האשכול, למי יש גישה ואיך מתבצעת רוטציית מפתחות.
- הוראות לתורנים — מה לבדוק כשיש אי-התאמה במצב, איך להבדיל בין כשל פריסה לכשל אפליקציה, פעולות אופייניות וסדר ההסלמה.
- תרשימים ותיעוד — דיאגרמה של זרימת השינויים מהקומיט ועד האשכול, מפת המאגרים וצ'ק-ליסט לחיבור שירות חדש.
כל ארטיפקט אנחנו מפרקים עם הצוות שלכם במסירה — כדי שאחרי חודש איש לא יחפש איפה קבועה הלוגיקה של הפריסה.
קייס: ArgoCD הסיר פריסות ידניות באשכול של 40 שירותים
לפני הטמעת GitOps אשכול עם 40 שירותים חי על פריסות ידניות: המהנדס בנה אימג', תיקן מניפסטים ישירות באשכול והחיל אותם דרך שורת הפקודה. איש לא יכול היה לשחזר את מצב הסביבה — התיאורים סטו ממה שעבד בפועל, ותיקונים «לדקה» שקעו באשכול לנצח.
העברנו את כל התיאורים ל-Git ומסרנו את הסנכרון ל-Argo CD: המאגר הפך למקור האמת היחיד, והאי-התאמה בינו לאשכול — גלויה וניתנת לתיקון. הפעלנו סנכרון אוטומטי והתאוששות עצמית: אם משאב משתנה ידנית או פוד נופל, הבקר מחזיר את המצב המוצהר בלי מעורבות אדם.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן פריסת שחרור | 40–60 דקות לשירות | 4–7 דקות, בלי צעדים ידניים |
| אי-סנכרונים בקונפיגורציה | 10–15 בחודש, התגלו רק בעקבות תקלות | בודדים, נראים בדשבורד מיד |
| שיעור החזרות לאחור | כל פריסה רביעית | כ-6% |
| שחזור לאחר תקלה | 2–3 שעות של ניתוח וחזרה ידנית לאחור | 10–15 דקות בהחזרת גרסה ב-Git |
החזרה לאחור כעת אינה פעולה נפרדת תחת לחץ, אלא החזרת הקומיט הקודם: הבקר בעצמו מביא את האשכול למצב הרצוי. חקירת התקרית עברה מהשאלה «מה סיבכו כאן בידיים» לעבודה עם הפרש גרסאות מובן, והיסטוריית השינויים של כל שירות נשארה במאגר.
במה שונה ArgoCD מצינור אספקה בהרכבה עצמית?
ArgoCD שומר את המצב הרצוי ב-Git ומשווה אותו לאשכול ללא הרף: האי-התאמה נראית מיד ואינה דורשת הרצה ידנית. צינור בהרכבה עצמית הוא רצף פקודות שמופעל פעם אחת ולא יודע דבר על מצב האשכול בפועל.
מכאן ההבדל בתצפיתיות ובחזרה לאחור. במודל הדקלרטיבי רואים אילו משאבים סטו מהמאגר, באיזו סביבה הסנכרון נתקע ואיזה קומיט קדם לו; חזרת השינויים לאחור היא חזרה למצב קודם, ולא הרצה חוזרת. בסקריפטים החזרה לאחור יוצאת לעיתים קרובות חלקית: חלק מהצעדים כבר הוחלו, וחלק לא.
גם האחריות למצב בפועל שונה. במודל הדקלרטיבי התקן הוא המאגר: אם משאב תוקן ישירות, הסחיפה תתגלה ותתוקן. בצינור בהרכבה עצמית את המצב בפועל לא מתאר איש — הוא מורכב מתופעות לוואי של הרצות.
תחזוקת הצינור עוברת מהקוד לכללים, לתפקידים ולהיסטוריית השינויים של המאגר. בהמשך נראה איך זה נראה בעבודה.
שאלות על הרשאות, סביבות ואשכולות שכבר עובדים
לפני ההתחלה אנחנו מפרקים עם צוות הלקוח חמש שאלות — הן קובעות אם ההטמעה תהפוך לקונטור מנוהל או לשכבה נוספת שהמהנדסים יתחילו לעקוף. להלן התמצית הטכנית של התשובות, בלי מילים כלליות.
אילו הרשאות מינימליות נדרשות ל-Argo CD באשכול?
חשבון שירות נפרד, ולא חשבון מנהל. מספיק לו לקרוא תיאורי אובייקטים ולכתוב למרחבי השמות ביעד; הגישה למאגרים — באמצעות טוקן לקריאה בלבד. תפקידי מנהל ברמת האשכול אינם ניתנים: במקרה של פגיעה בבקר הנזק מוגבל לקונטור אחד.
איך לבודד את קונטורי הפיתוח, הבדיקות והפרודקשן?
מפרידים באמצעות מופעים או פרויקטים עם הגבלה לפי מרחבי שמות. קונטור הפרודקשן נבדל באישור ידני חובה לסנכרון ובאיסור על החלה אוטומטית מענף משותף.
האם אשכול שכבר עובד יתחבר?
כן, בלי השבתה. תחילה השירות נלקח למצב תצפית: המצב נקרא, אי-ההתאמות מול המניפסטים מתועדות, אבל שום דבר לא מוחל. כשהתיאורים תואמים את המעשה — מפעילים החלה אוטומטית, שירות אחד בכל פעם.
מה עם תכנית החזרה לאחור?
החזרה לאחור — חזרה לרוויזיה הקודמת של המניפסטים ב-Git: מצב האשכול מובא אליה תוך דקות. המפסק השני — כיבוי ההחלה האוטומטית, ולאחריו שינויים עוברים רק בפקודה מפורשת של המהנדס.
מה כלול בתחזוקה לאחר ההטמעה?
תורנות לתקריות, עדכון הבקר וכללי הגישה, חיבור שירותים חדשים, סקירת אי-התאמות בין התיאור למעשה. בנפרד — ניתוח אילו שירותים נשארו מחוץ לקונטור ומדוע.
אם ולו סעיף אחד לא סגור עד הסנכרון הראשון, ההטמעה נתקעת בצעדי עקיפה ידניים — ולכן אנחנו מתעדים את התשובות בכתב ומצרפים לתכנית העבודה.נדון במשימה: ננתח את האשכול שלכם ונחזור עם תכנית
הערכה עניינית של הטמעת ArgoCD נבנית על עובדות על האשכול שלכם, ולא על מילים כלליות. ככל שהנתונים מדויקים יותר, כך יישארו פחות הנחות בתכנית והעבודה תתחיל מהר יותר.
- תרשים הקונטורים: כמה אשכולות וסביבות, היכן הם ממוקמים, האם הם מחוברים ברשת ובמאגר אימג'ים משותף.
- שיטת הפריסה הנוכחית: פקודות ידניות, משימות בצינור הבנייה, צ'ארטים או מניפסטים נפרדים — ומה בדיוק נעשה בידיים לפני השחרור.
- מבנה המאגרים: היכן נשמרים תיאורי המשאבים, האם יש ענפים נפרדים לסביבות, למי יש הרשאה למזג שינויים.
- מגבלות הרשאות: האם אפשר להנפיק חשבון לקריאה בלבד, האם יש קונטור סגור בלי רשת חיצונית, מרכזי תעודות משלכם.
- דרישות לחזרה לאחור וחלונות שחרור: כמה מהר צריך להחזיר את הגרסה הקודמת, האם יש תקופות שבהן פריסה אסורה.
- מה כבר ניסיתם: פיילוט של ArgoCD, סקריפטים בהרכבה עצמית, מגבלות שבהן הכול נעצר.
בתמורה אנחנו שולחים לא מחשבות כלליות, אלא ערכה עובדת:
- תרשים הקונטורים והטופולוגיה הרצויה — היכן הקונטור המנהל, אילו אשכולות בתצפית, איך מחולקות ההרשאות בין הצוותים;
- תכנית הטמעה בשלבים, עם תוצאה ניתנת לבדיקה בכל שלב: הרצה על סביבה אחת, העברת השאר, כיבוי הפעולות הידניות;
- סדר עבודה משותפת: היכן נדרשים המהנדסים שלכם, איך מתקבלים שינויים ומי מאשר את הפריסה;
- הרכב ההרשאות ותנאי תחילת העבודה — מה נדרש מצדכם לשלב הראשון.
תארו את המשימה וצרפו את מה שיש: זה מספיק כדי לחזור עם הערכה ותכנית.