USA / Canada 866-503-1471

International +972-722-405-222

« לעמוד הראשי

האם התקנת GitLab מעל Kubernetes מספקת High Availability?

עדכון אחרון: 17/03/2019

gitlab on kubernetes

בקצרה: זהו מאמר שמסביר מה משיגים בשילוב GitLab עם Kubernetes – ומה לא.

כנציגי GitLab בארץ, אנו מקבלים שאלות טכניות על בסיס יומיומי בנוגע למוצר ולכלים שמתחברים אליו.
אחת השאלות שראינו שחוזרת על עצמה בתקופה האחרונה, היא החיבור מול Kubernetes .
שמנו לב שישנה מחשבה שהתקנת GitLab מעל Kubernetes תתן פתרון High Availability מלא – וזה לא מדוייק – לכן החלטתי לכתוב את המאמר הזה ולעשות קצת סדר בדברים.

ראשית – קצת רקע:

  • GitLab משמש לא רק ככלי version-control מעל git  – אלא גם ככלי CI/CD מתקדם
    (ניתן לקרוא על כך בהרחבה בדו"ח של חברת המחקר Forrester . בסקירה שלהם הם בחנו כמה כלי CI/CD מוכרים ונפוצים כגון Jenkins ונוספים, ולבסוף GitLab CI/CD קיבל את הציונים הגבוהים ביותר.  קישור להורדת הדו"ח המלא בסוף המאמר הזה).
  • ל- GitLab אינטגרציה מצויינת עם קונטיינרים ועם Kubernetes. למעשה הוא נחשב כיום לדעת רבים ככלי ה- CI/CD וניהול קוד/גירסאות המוביל בנושא זה הואיל והוא נבנה מלכתחילה בהתאמה לעולמות Docker / Containers / Kubernetes / cloud computing , ויתירה מזו – הכל מגיע יחד ככלי אחד כך שאין צורך להתעסק ב "הדבקות" בין כלים.
  • כידוע, Kubernetes (מבטאים "קוּברנטיס") הוא הסטנדרט כיום דה-פקטו לניהול ואורקסטרציה של containers, וארגונים רבים כבר משתמשים ב- Kubernetes באופן קבוע, או שמנסים אותו ונמצאים בשלבי פיילוט, או שחושבים להשתמש בו בעתיד הקרוב כתשתית לניהול קונטיינרים ( Container Orchestration Framework).

GitLab  ו- High Availability – מדוע ?

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

חשוב להזכיר ש- GitLab לא מספק git repository בלבד — אלא הרבה מעבר:  ניהול משימות ; ניהול code reviews  ; ניהול pipelines ועוד meta-data נוסף (ואם היה מדובר ב- git repository בלבד לא היה צורך ב- High Availability היות והמערכת מבוזרת כך שכל מופע של repo מחזיק את כל ההסטוריה).

כיום, אם רוצים High availability של GitLab יש 3 אפשרויות פעולה:

  1. לקנות רישוי בגירסת GitLab Premium או Ultimate ולקבל לצד הרשיון גם תמיכה של היצרן
  2. להשתמש בשירות הענן הציבורי של GitLab שמספק HA ע"י היצרן
    (יחד עם זאת חשוב לזכור שלאפשרות זו כמה השלכות: חוסר בשליטה על השרת, אבטחת מידע שנחשבת חלשה יותר ועוד).
  3. להקים סביבת High Availability בעצמכם ולתמוך בעצמכם, או להעזר בחברה שמתמחה בנושא
כנציגי היצרן בארץ, אנו (חברת ALM-Toolbox) מספקים מענה לכל 3 האפשרויות, כולל אפשרות להקמה של סביבת High Availability מקצה לקצה עם תמיכה באתר הלקוח ועם אפשרות ל- SLA

ומה לגבי Kubernetes ? האם הוא מספק HA ל- GitLab ?

חשוב להבין שהתקנת שרת GitLab מעל Kubernetes לא תתן לכם High Availability מלא – הואיל ולא מדובר כאן ביתירות הנתונים עצמם (דהיינו ה- storage וה- databases).
וביתר פירוט:

אם שמים את השרת מעל Kubernetes אזי אפשר להשיג Self-healing – דהיינו שהשרת "יתרפא" לבד (כך שאם למשל הוא נופל אז הוא יעלה את עצמו לבד).

ישנה גם התקנת GitLab שבה כל רכיב מגיע בקונטיינר נפרד, וכל הרכיבים יושבים ב- node משותף. אם אותו node יפול אז הוא יתרפא מעצמו (דהיינו שיווצר persistent volume חדש , הנתונים יועתקו אליו והתפקוד יחזור לקדמותו), אבל – חשוב לזכור שהנתונים יושבים חיצונית לקונטיינרים – כך שאם אין יתירות (redundancy) של הנתונים וה- storage אזי אין דרך לשחזר את המידע – ולכן אין כאן HA  .
נוסף על כך – יהיה פרק-זמן כלשהו שבו המערכת לא תהיה זמינה (מהנפילה ועד ההתאוששות המלאה שלה).

לכן ניתן לסכם זאת כך: התקנת שרת GitLab מעל Kubernetes תעזור להתאוששות מהירה מתקלות, דהיינו זהו סוג של פתרון Disaster Recovery – אך לא מדובר בפתרון HA.

ומה לגבי GitLab Runners ? האם יש יתרון בהקמתם מעל Kubernetes ?

למי שטרם מכיר – ה- Runners הם ה- executors / nodes של GitLab CI/CD (רכיב ה- CI/CD שמגיע built-in יחד עם GitLab) .

למי שמכיר את Jenkins CI , ניתן לומר שה- nodes של Jenkins (או Slaves בשמם הקודם) שקולים ל- Runners של GitLab מבחינה פונקציונלית.

כאן יש ל- Kubernetes יותר יתרונות בהשוואה להתקנת שרת GitLab  מעל Kubernetes , הואיל ובד"כ אין צורך ב- HA  עבור runner  ספציפי, והואיל ו- runners לרוב עולים ויורדים בהתאם לצורך של הרצת עיבוד כלשהו, וכאן באים לידי ביטוי יכולות ה- self-healing  וה- auto-scaling של Kubernetes .

על Runners והחיבור עם Kubernetes ויכולות יפות נוספות שאפשר להשיג יחד נרחיב באחד מהפוסטים הבאים.

בקרוב גם נציג Case Study (סיפור לקוח) בו נספר על סביבת GitLab שבנינו מעל Kubernetes עבור אחד מלקוחותינו.

 

הכותב הוא מנהל חברת ALM-Toolbox – מפיצי GitLab בישראל ובמדינות נוספות.

חברת ALM-Toolbox מתמחה ב- DevOps ו- ALM, מעבר לענן, בניית תהליכי CI/CD כולל "Self Service" , תכנון ופריסת פתרונות HA / DR אפליקטיביים ועוד, ובפרט בכלים git, GitLab, Jenkins  Docker, Rancher, Kubernetes (ונוספים) ובעננים AWS, GCP, Azure .
לשאלות נוספות, קבלת רשיון התנסות בגירסת המלאה של GitLab הכוללת את כל הפיצ'רים (ב- self-hosted או בענן) או קבלת הצעת מחיר, ניתן לפנות אלינו במייל gitlab@almtoolbox.com או טלפונית: 072-240-5222

רוצים לקבל עדכון במייל כאשר נעלה כאן בבלוג תכנים חדשים על GitLab ו- Kubernetes ?  השאירו כאן כתובת מייל – אנו מתחייבים לא לשלוח SPAM!

* אימייל:

 

קישורים רלבנטים:

 

 

נסו את כל הפיצ'רים שב- GitLab ל- 30 יום , בענן או על שרת פרטי – ללא התחייבות.

להתנסות לחצו כאן. שאלות? צרו איתנו קשר

x icon svg