מה זה GitOps?

הערה. תרגום: לאחר פרסום אחרון חומר לגבי שיטות משיכה ודחיפה ב-GitOps, ראינו עניין במודל הזה באופן כללי, אבל היו מעט מאוד פרסומים בשפה הרוסית בנושא זה (פשוט אין כאלה על Habré). לכן, אנו שמחים להציע לתשומת לבכם תרגום של מאמר אחר - אם כי לפני כמעט שנה! - מ-Weaveworks, שראשה טבע את המונח "GitOps". הטקסט מסביר את מהות הגישה ואת ההבדלים העיקריים מהקיימים.

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

המאמר התברר כפופולרי. אנשים אחרים התחילו לדבר על GitOps והחלו לפרסם כלים חדשים עבור דחיפת גיט, פיתוח, סודות, פונקציות, אינטגרציה מתמשכת וכולי. הופיע באתר שלנו מספר גדול פרסומים ומקרי שימוש ב-GitOps. אבל לחלק מהאנשים עדיין יש שאלות. במה הדגם שונה מהמסורתי? תשתית כקוד ואספקה ​​רציפה (משלוח רציף)? האם יש צורך להשתמש ב- Kubernetes?

עד מהרה הבנו שיש צורך בתיאור חדש המציע:

1. מספר רב של דוגמאות וסיפורים;
2. הגדרה ספציפית של GitOps;
3. השוואה לאספקה ​​רציפה מסורתית.

במאמר זה ניסינו לכסות את כל הנושאים הללו. הוא מספק מבוא מעודכן ל-GitOps ונקודת מבט של מפתחים ו-CI/CD. אנו מתמקדים בעיקר ב- Kubernetes, אם כי ניתן להכליל את המודל.

הכירו את GitOps

דמיינו את אליס. היא מנהלת את Family Insurance, שמציעה ביטוח בריאות, רכב, דירה ונסיעות לאנשים שעסוקים מכדי להבין בעצמם את הפרטים הקטנים של חוזים. העסק שלה התחיל כפרויקט צדדי כאשר אליס עבדה בבנק כמדען נתונים. יום אחד היא הבינה שהיא יכולה להשתמש באלגוריתמים ממוחשבים מתקדמים כדי לנתח נתונים בצורה יעילה יותר ולגבש חבילות ביטוח. המשקיעים מימנו את הפרויקט, וכעת החברה שלה מכניסה יותר מ-20 מיליון דולר בשנה וצומחת במהירות. כיום היא מעסיקה 180 עובדים בתפקידים שונים. זה כולל צוות טכנולוגי שמפתח, מתחזק את האתר, מסד הנתונים ומנתח את בסיס הלקוחות. את הצוות המונה 60 אנשים מוביל בוב, המנהל הטכני של החברה.

הצוות של בוב פורס מערכות ייצור בענן. יישומי הליבה שלהם פועלים על GKE, תוך ניצול היתרון של Kubernetes ב-Google Cloud. בנוסף, הם משתמשים בכלי נתונים וניתוח שונים בעבודתם.

ביטוח משפחה לא יצא להשתמש במכולות, אלא נקלע להתלהבות של דוקר. עד מהרה גילתה החברה ש-GKE הקלה על פריסת אשכולות כדי לבדוק תכונות חדשות. Jenkins for CI ו-Quy נוספו כדי לארגן את רישום הקונטיינרים, סקריפטים נכתבו עבור Jenkins שדחפו קונטיינרים ותצורות חדשות ל-GKE.

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

ואז הם למדו על GitOps. ההחלטה הזו התבררה בדיוק מה שהם צריכים כדי להתקדם בביטחון.

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

ביטוח המשפחה מחליט ליישם את GitOps. לחברה יש כעת מודל תפעול אוטומטי התואם עם Kubernetes ומשלבים מהירות עם יַצִיבוּתבגלל שהם:

• גילה שהתפוקה של הצוות הוכפלה מבלי שאף אחד ישתגע;
• הפסיק להגיש סקריפטים. במקום זאת, הם יכולים כעת להתמקד בתכונות חדשות ולשפר שיטות הנדסיות - למשל, הצגת השקות קנריות ושיפור הבדיקות;
• שיפרנו את תהליך הפריסה כך שהוא מתקלקל לעתים נדירות;
• קיבל את ההזדמנות לשחזר פריסות לאחר כשלים חלקיים ללא התערבות ידנית;
• נרכש משומשоאמון רב יותר במערכות מסירה. אליס ובוב גילו שהם יכולים לפצל את הצוות לצוותי מיקרו-שירות הפועלים במקביל;
• יכול לבצע 30-50 שינויים בפרויקט בכל יום באמצעות המאמצים של כל קבוצה ולנסות טכניקות חדשות;
• קל למשוך מפתחים חדשים לפרויקט, שיש להם הזדמנות להפיץ עדכונים לייצור באמצעות בקשות משיכה בתוך כמה שעות;
• לעבור ביקורת בקלות במסגרת SOC2 (לעמידה של ספקי שירותים בדרישות לניהול נתונים מאובטח; קרא עוד, למשל, כאן - משוער. תרגום).

מה קרה?

GitOps זה שני דברים:

1. מודל תפעולי עבור Kubernetes ומקורי ענן. הוא מספק קבוצה של שיטות עבודה מומלצות לפריסה, ניהול וניטור אשכולות ויישומים מכולים. הגדרה אלגנטית בצורה מגלשה אחת מ לואיס פאסיירה:
2. הדרך ליצירת סביבת ניהול יישומים הממוקדת במפתחים. אנו מיישמים את זרימת העבודה של Git הן בתפעול והן בפיתוח. שימו לב שזה לא רק על Git push, אלא על ארגון כל הסט של כלי CI/CD ו-UI/UX.

כמה מילים על Git

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

איך Kubernetes עובד

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

מה Kubernetes נותן למשתמשים?

להלן כמה תכונות עיקריות:

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

יכולות ההתכנסות הגדולות של Kubernetes

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

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

איך GitOps עובד

למדנו מספיק על Kubernetes כדי להסביר איך GitOps עובד.

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

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

1. תהליך עבודה: "ג'נקינס לבנות - סניף מאסטר".
רשימת מטלות:

• ג'נקינס דוחף תמונות מתויגות ל- Quay;
• ג'נקינס דוחף תרשימי הגדרות ו-Helm לדלי האחסון הראשי;
• פונקציית הענן מעתיקה את התצורה והתרשימים מדלי האחסון הראשי למאגר Git הראשי;
• האופרטור GitOps מעדכן את האשכול.

2. Jenkins build - סניף שחרור או תיקון חם:

• ג'נקינס דוחף תמונות לא מתויגות לקוואי;
• ג'נקינס דוחף תרשימי הגדרות ו-Helm לדלי האחסון;
• פונקציית הענן מעתיקה את התצורה והתרשימים מדלי אחסון ה-Staging אל מאגר Git ה-Staging;
• האופרטור GitOps מעדכן את האשכול.

3. ג'נקינס לבנות - לפתח או להגדיר ענף:

• ג'נקינס דוחף תמונות לא מתויגות לקוואי;
• ג'נקינס דוחף תרשימי הגדרות ו-Helm לתוך דלי אחסון הפיתוח;
• פונקציית הענן מעתיקה את התצורה והתרשימים מדלי האחסון של פיתוח למאגר Git של פיתוח;
• האופרטור GitOps מעדכן את האשכול.

4. הוספת לקוח חדש:

• המנהל או המנהל (LCM/ops) קורא ל- Gradle לפרוס ולהגדיר תחילה מאזני עומסים ברשת (NLBs);
• LCM/ops מבצע תצורה חדשה כדי להכין את הפריסה לעדכונים;
• האופרטור GitOps מעדכן את האשכול.

תיאור קצר של GitOps

1. תאר את המצב הרצוי של המערכת כולה באמצעות מפרטים הצהרתיים לכל סביבה (בסיפור שלנו, הצוות של בוב מגדיר את כל תצורת המערכת ב-Git).
   • מאגר Git הוא מקור האמת היחיד לגבי המצב הרצוי של המערכת כולה.
   • כל השינויים במצב הרצוי מתבצעים באמצעות commits ב-Git.
   • כל פרמטרי האשכול הרצויים ניתנים לצפייה גם באשכול עצמו. בדרך זו נוכל לקבוע אם הם חופפים (מתכנסים, לְהִתְכַּנֵס) או להבדיל (להתפצל, לִסְטוֹת) מצבים רצויים ונצפוים.
2. אם המצבים הרצויים והנצפים שונים, אז:
   • קיים מנגנון התכנסות שבמוקדם או במאוחר מסנכרן אוטומטית את היעד והמצבים הנצפים. בתוך האשכול, Kubernetes עושה זאת.
   • התהליך מתחיל מיד עם התראת "תבצע שינוי".
   • לאחר פרק זמן מסוים שניתן להגדרה, ניתן לשלוח התראה "הבדל" אם המצבים שונים.
3. בדרך זו, כל ההתחייבויות ב-Git גורמות לעדכונים ניתנים לאימות וחסרי כוח לאשכול.
   • החזרה לאחור היא התכנסות למצב רצוי בעבר.
4. ההתכנסות היא סופית. התרחשותו מסומנת על ידי:
   • אין התראות על הבדל לפרק זמן מסוים.
   • התראה "מתכנסת" (למשל webhook, אירוע כתיבה של Git).

מהי סטייה?

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

כמה דוגמאות לסטייה:

• שינוי בקובץ התצורה עקב מיזוג סניפים ב-Git.
• שינוי בקובץ התצורה עקב התחייבות Git שנעשתה על ידי לקוח ה-GUI.
• שינויים מרובים למצב הרצוי עקב PR ב-Git ולאחר מכן בניית תמונת הקונטיינר ושינויי התצורה.
• שינוי במצב האשכול עקב שגיאה, התנגשות משאבים שגרמה ל"התנהגות רעה", או פשוט סטייה אקראית מהמצב המקורי.

מהו מנגנון ההתכנסות?

הנה כמה דוגמאות:

• עבור מכולות ואשכולות, מנגנון ההתכנסות מסופק על ידי Kubernetes.
• ניתן להשתמש באותו מנגנון לניהול יישומים ועיצובים מבוססי Kubernetes (כגון Istio ו-Kubeflow).
• מנגנון לניהול האינטראקציה התפעולית בין Kubernetes, מאגרי תמונות ו-Git מספק מפעיל GitOps Weave Flux, שהוא חלק Weave Cloud.
• עבור מכונות בסיס, מנגנון ההתכנסות חייב להיות הצהרתי ואוטונומי. מהניסיון שלנו אנחנו יכולים לומר זאת Terraform הכי קרוב להגדרה זו, אבל עדיין דורש שליטה אנושית. במובן זה, GitOps מרחיבה את מסורת התשתית כקוד.

GitOps משלב את Git עם מנוע ההתכנסות המצוין של Kubernetes כדי לספק מודל לניצול.

GitOps מאפשר לנו לומר: רק אותן מערכות שניתן לתאר ולהתבונן בהן יכולות להיות אוטומטיות ובקרה.

GitOps מיועד לכל מחסנית המקור של הענן (לדוגמה, Terraform וכו')

GitOps זה לא רק Kubernetes. אנחנו רוצים שהמערכת כולה תהיה מונעת באופן הצהרתי ותשתמש בהתכנסות. במערכת כולה אנו מתכוונים לאוסף של סביבות שעובדות עם Kubernetes - למשל, "אשכול מפתח 1", "ייצור" וכו'. כל סביבה כוללת מכונות, אשכולות, יישומים, וכן ממשקים לשירותים חיצוניים המספקים נתונים, ניטור וכו'.

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

יש התמקדות חזקה ביישום מושגי GitOps על שכבות על גבי Kubernetes. כרגע קיימים פתרונות מסוג GitOps עבור Istio, Helm, Ksonnet, OpenFaaS ו-Kubeflow, וכן למשל עבור Pulumi שיוצרים שכבה לפיתוח אפליקציות ל-Cloud Native.

Kubernetes CI/CD: השוואת GitOps עם גישות אחרות

כאמור, GitOps זה שני דברים:

1. מודל ההפעלה של Kubernetes ומקורי ענן שתואר לעיל.
2. הדרך לסביבת ניהול יישומים הממוקדת במפתחים.

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

GitOps מאפשר פריסה רציפה (CD) עבור Kubernetes

GitOps מציעה מנגנון פריסה רציפה שמבטל את הצורך ב"מערכות ניהול פריסה" נפרדות. Kubernetes עושה את כל העבודה בשבילך.

• עדכון האפליקציה דורש עדכון ב-Git. זהו עדכון עסקה למצב הרצוי. לאחר מכן "פריסה" מתבצעת בתוך האשכול על ידי Kubernetes עצמה בהתבסס על התיאור המעודכן.
• בשל האופי של אופן הפעולה של Kubernetes, עדכונים אלה מתכנסים. זה מספק מנגנון לפריסה רציפה שבה כל העדכונים הם אטומיים.
• הערה: Weave Cloud מציעה אופרטור GitOps המשלב את Git ו-Kubernetes ומאפשר ביצוע CD על ידי התאמה בין המצב הרצוי והנוכחי של האשכול.

בלי kubectl ותסריטים

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

ההטבות כוללות:

1. ימין. ניתן ליישם קבוצה של עדכונים, להתכנס ולבסוף לאמת, ולקרב אותנו ליעד של פריסה אטומית. לעומת זאת, שימוש בסקריפטים אינו מספק כל ערובה להתכנסות (עוד על כך בהמשך).
2. אבטחה. מצטט Kelsey Hightower: "הגבלת את הגישה לאשכול Kubernetes שלך לכלי אוטומציה ומנהלי מערכת שאחראים על איתור באגים או תחזוקה שלו." ראה גם הפרסום שלי לגבי בטיחות ועמידה במפרטים טכניים, כמו גם מאמר על פריצת Homebrew על ידי גניבת אישורים מתסריט של ג'נקינס שנכתב ברישול.
3. חוויית משתמש. Kubectl חושף את המכניקה של מודל האובייקטים של Kubernetes, שהם די מורכבים. באופן אידיאלי, משתמשים צריכים לקיים אינטראקציה עם המערכת ברמת הפשטה גבוהה יותר. כאן אתייחס שוב לקלסי ואמליץ לצפות קורות חיים כאלה.

ההבדל בין CI ל-CD

GitOps משפר דגמי CI/CD קיימים.

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

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

מדוע שרתי CI לא צריכים לעשות תקליטורים באמצעות עדכונים ישירים ב-Kubernetes

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

בוא נחזור לאליס ובוב.

עם אילו בעיות הם התמודדו? שרת ה-CI של בוב מחיל את השינויים על האשכול, אך אם הוא קורס בתהליך, בוב לא יידע באיזה מצב נמצא (או אמור להיות) האשכול או כיצד לתקן זאת. הדבר נכון גם במקרה של הצלחה.

הבה נניח שהצוות של בוב בנה תמונה חדשה ולאחר מכן תיקן את הפריסה שלהם כדי לפרוס את התמונה (הכל מצינור ה-CI).

אם התמונה נבנית כרגיל, אך הצינור נכשל, הצוות יצטרך להבין:

• האם העדכון יצא?
• אנחנו משיקים מבנה חדש? האם זה יוביל לתופעות לוואי מיותרות - עם אפשרות לשתי בנייה של אותה תמונה בלתי ניתנת לשינוי?
• האם עלינו לחכות לעדכון הבא לפני הפעלת ה-build?
• מה בדיוק השתבש? על אילו שלבים יש לחזור (ועל אילו מהן בטוח לחזור)?

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

לסיכום, הנה הסיבה ששרתי CI לא צריכים להתמודד עם CD:

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

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

GitOps כדרך הטובה ביותר ליישם משלוח רציף עבור Kubernetes

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

מודל הפעלה עבור Kubernetes

התבונן בתרשים הבא. הוא מציג את Git ואת מאגר התמונות המכיל כמשאבים משותפים עבור שני מחזורי חיים מתוזמרים:

• צינור אינטגרציה רציף שקורא וכותב קבצים ל-Git ויכול לעדכן מאגר של תמונות מיכל.
• צינור Runtime GitOps המשלב פריסה עם ניהול וצפייה. זה קורא וכותב קבצים ל-Git ויכול להוריד תמונות מיכל.

מהם הממצאים העיקריים?

1. הפרדת חששות: שימו לב ששני הצינורות יכולים לתקשר רק על ידי עדכון Git או מאגר התמונות. במילים אחרות, יש חומת אש בין CI לבין סביבת זמן הריצה. אנו קוראים לזה "חומת האש ללא שינוי" (חומת אש בלתי ניתנת לשינוי), מכיוון שכל עדכוני המאגר יוצרים גרסאות חדשות. למידע נוסף על נושא זה, עיין בשקפים 72-87 המצגת הזו.
2. אתה יכול להשתמש בכל שרת CI ו-Git: GitOps עובד עם כל רכיב. אתה יכול להמשיך להשתמש בשרתי CI ו-Git המועדפים עליך, מאגרי תמונות וחבילות בדיקה. כמעט כל שאר כלי המסירה הרציפה בשוק דורשים שרת CI/Git או מאגר תמונות משלהם. זה עשוי להפוך לגורם מגביל בפיתוח של native בענן. עם GitOps, אתה יכול להשתמש בכלים מוכרים.
3. אירועים ככלי אינטגרציה: ברגע שהנתונים ב-Git מתעדכנים, Weave Flux (או המפעיל של Weave Cloud) מודיע על זמן ריצה. בכל פעם ש-Kubernetes מקבל ערכת שינויים, Git מתעדכן. זה מספק מודל אינטגרציה פשוט לארגון זרימות עבודה עבור GitOps, כפי שמוצג להלן.

מסקנה

GitOps מספק את ערבויות העדכון החזקות הנדרשות על ידי כל כלי CI/CD מודרני:

• אוטומציה;
• הִתכַּנְסוּת;
• אימפוטנציה;
• דטרמיניזם.

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

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

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

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «GitOps: השוואה של שיטות משיכה ודחיפה";
• «הכירו את kubedog, ספרייה למעקב אחר משאבי Kubernetes";
• «הרחבת והשלמה של Kubernetes (סקירה כללית ודוח וידאו)".

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם ידעת על GitOps לפני ששני התרגומים האלה הופיעו ב-Habré?

• כן, ידעתי הכל

• רק בצורה שטחית

• לא

35 משתמשים הצביעו. 10 משתמשים נמנעו.

מקור: www.habr.com