כיצד חברת Nuvo Cares מבצעת CI/CD בעזרת GitLab, Kubernetes, Helm וכלים נוספים
ב- 30.12.2018 קפצתי למפגש שארגנו NUVO וקבוצת Kubernetes Israel – התארחנו בחברת Nuvo Cares ואת השיחה העביר מאור פרידמן.
מאור: הגיע מרקע של פיתוח ו "מצא את מקומו ב- DevOps" . אוהב את האתגרים שב- DevOps.
רקע על חברת Nuvo :
ל – Nuvo מוצר Healthcare להריון – חגורה שאוספת מטריקות מהאם והעובר. המוצר משלב ענן וטכנולוגיה עדכנית.
טכנולוגיות שעובדים איתן בחברה:
- GitLab (היכן שמתנהל הקוד המרכזי של החברה)
- GitHub (היכן ששמים את הקוד הפתוח שפיתחו)
- GitLab CI/CD
- Jira
- AWS
- Kubernetes
- Helm
- Grafana
- ELK
הם פיתחו מוצר משלים משלהם בקוד פתוח לאחר שנתקלו בחוסר במוצרים קיימים.
למה צריך CI/CD ? ע"פ התפיסה של Nuvo:
- Velocity
- Repeatability
- Eliminate toil
- Traceability (to be able to recover all back way [when necessary])
לקח להם 9 חודשים לבנות כך שהכל יהיה אוטומטי (כולל פיתוח 2 גירסאות של Orca)
הם רצו להגיע למצב שכל ה- deploy יעשה כ- Self service . רצו למשל שהצוות שיושב בקייב יסתדר לבד ביום שישי ולא יפנה אליהם
שיקולי CI/CD שעמדו לנגד עיניהם:
- Requirements
דרישות שהגיעו מהלקוחות שלהם ( = מפתחים). המפתחים רצו להתרכז בפיתוח קוד נטו
- Branch Strategy
שאלות לדוגמא: האם פורסים מה- master ? מתי עושים Merge Request ? וכו'
- Repo structure
שיקול שנגזר ממבנה המוצר (microservices במקרה שלהם) ומהכלי בו משתמשים (gitlab / git או כל כלי אחר)
- Environment
סביבת העבודה – היכן שמים artifacts וכד' (S3? או כלי אחר) ; לאן מעלים את זה וכו'
Work Environment:
- K8S
- Deploy by HELM
- GitLab + GitLab CI (runners are running on AWS above Kubernetes)
- Microservices
- Each repo has its own CI flow (configured by YML file)
הקבצים הנ"ל זהים בכל ה- repos למעט משתני הסביבה שבשימוש (בכל repo משתנים אחרים)
- JIRA
- Orca
עובדים עם קוד פתוח ורוצים לתרום חזרה – יש פוסט של המנהל שלו בנושא
Orca זה עטיפה ל HELM
בחנו כמה כלים (כולל CodeFresh) והעדיפו להשתמש ב- GitLab CI/CD ולפתח תוספת קטנה משלהם שהפכו לקוד פתוח (ובינתיים חלק מהפיצ'רים שפיתחו בו כבר נוספו ל- GitLab כמו הרצת pipeline שונה לכל תיקיית source – נוספה לזה תמיכה ב GitLab 11.4 )
- Kubernetes secrets
מאור ציין שיש להם 3 סוגי Pipelines :
- Source code pipeline
Triggered when there are new changes in /src folder
Flow: ( build) → (update chart [after commit])
- Kubernetes pipeline
Running a chart
Flow: (upload chart) → ( deploy chart)
- Merge Request pipeline
Flow: (build [they build from scratch if something has changed]) → (update chart [with no commit!] ) → (upload chart [without changing version control] ) → (deploy env) → (delete env)
חשוב לציין שה- pipelines האלה הם מאוד מפושטים לטובת ההדגמה, ו- pipelines אמיתיים יכללו שלבים נוספים, כגון בדיקות (tests).
תמונות מהמפגש:
