GitOps: עוד מילת באז או פריצת דרך באוטומציה?

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

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

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

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

אז מה בעצם ההבדל? GitOps מ IaC? עם השאלה הזו התחלתי את החקירה שלי. לאחר שוחחתי עם עמיתים, הצלחתי להגיע להשוואה הבאה:

GitOps

IaC

כל הקוד מאוחסן במאגר git

ניהול גרסאות קוד הוא אופציונלי

קוד הצהרתי תיאור / אימפוטנציה

הן תיאורים הצהרתיים והן תיאורים ציוויים מקובלים

השינויים נכנסים לתוקף באמצעות מנגנוני בקשת המיזוג / Pull Request

הסכם, אישור ושיתוף פעולה הם אופציונליים

תהליך השקת העדכונים הוא אוטומטי

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

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

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

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

החברה GitLab פיתחנו שתי הגדרות למונח החדש הזה: תיאורטית ומעשית. נתחיל מהתיאורטי:

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

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

מנקודת מבט מעשית, אנו מתארים GitOps כדלקמן:

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

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

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

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

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

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

• יישם את העקרונות הבסיסיים של GitOps

• צור וערוך שינויים בתשתית הענן (באמצעות הדוגמה של Yandex Cloud)

• זיהוי אוטומטי של סחיפה של המערכת ממצב רצוי באמצעות ניטור פעיל

https://bit.ly/34tRpwZ

מקור: www.habr.com