סיפור לקוח: כיצד משתמשים ב- GitLab CI ו- Terraform בחברת StartApp
לאחרונה אירחתי את דוד מרק מחברת StartApp למפגש שבו תיאר כיצד הם עובדים עם GitLab CI ו- Terraform .
המפגש וההדגמה הוקלטו! למעוניינים בוידאו, ניתן לפנות אלינו במייל אל devops@almtoolbox.com ואנו נשלח קישור להקלטה.
לנוחיותכם הוספנו כאן את מלל השיחה.
טקסט מלא:
שלום לכולם
אני תמיר גפן מ- ALM-Toolbox .
אני שמח לארח כאן את דוד מרק מחברת StartApp , שבתפקידו הוא ארכיטקט תשתיות וראש צוות DevOps.
תמיר: דוד – אני שמח שאתה מצטרף ואני נותן לך את הבמה. בהצלחה.
דוד: תודה על ההשתתפות. אני מקווה שהוובינר הזה יצאו טובים ומועילים לכולם. ואם יש שאלות אתם יותר ממוזמנים לשאול.
תמיר: רוצה לספר קצת עליך? מה אתה עושה ומה החברה עשה?
דוד: אני ארכיטקט תשתיות בחברת StartApp .
על חברת StartApp
אנחנו עובדים בצורה מגוונת עם הרבה טכנולוגיות מאתגרות.
זו חברת Big-Data שפועלת בעולמות ה- mobile . המוצר שלנו היא פלטפורמת פרסום ו- data שמעניקה לכל אחד מצד אחד יכולות מוניטיזציה למפתחי אפליקציות,
והמפתחים אמורים להטמיע את ה SDK שלנו ואז הם יכולים להתאים את הפרוסמומת בצורה מותאמת אישית היכן שהם רוצים.
יש לנו מהצד השני לקוחות שהם מפרסמים כמו Disney שיכולים לפרסם בצורה ממקודת לקהל שהם בוחרים.
ה- SDK שלנו מוטמע היום בלמעלה חצי מליון אפליקציות ולמעלה מ 20 מליארד פעמים – אחד הגבוהים בעולם.
החברה נוסדה לפני 8 שנים ואנחנו יושבים בפולג שבנתניה.
אנחנו מחפשים אנשי DevOps טובים ואיכותיים שרוצים לעבוד בסביבה מאתגרת מאוד
ואתם תראו בוובינר חלק משיטות העבודה ודברים שמאוד מאתגרים ומרתקים.
בשנה וחצי האחרונות עשינו שינוי מהותי:
מעבר מ- GitHub ל- GitLab
עשינו מעבר מ GitHub ל- GitLab: מהלך שהובלתי אותו והכיוון שלו היה באמת לעשות קונסולידציה של כמה כלים שעבדנו איתם – בעיקר Jenkins ו- GitHub – אל GitLab .
בוובינר הזה נדבר בעיקר על GitLab CI ואיך לקחנו את Terraform בתור הכלי והמהות איך אנחנו מנהלים את התשתית (infrastructure) שלנו בענן ולמה תכל'ס לדעתנו זה המוצר הנכון ביותר לעשות את הדברים האלה.
תמיר: אני אזכיר ש- GitLab לטובת מי שלא מכיר שזה כלי שיש לו הרבה יכולות, אבל לענייננו יש הוא גם Version control וגם כלי CI כמו Jenkins וגם כלי CD של Continuous Deployment .
דוד: נכון מאוד.
אני אדבר יותר על GitLab CI ולמה באמת הכלי הזה מושך מבחינתי יותר מכלים אחרים.
אני חושב שהקשר שבין GITLAB ל GITLAB CI זה ההשלמה שה- CI עושה ל GITLAB.
דהיינו זה היכולת של כל מפתח , לא משנה אם זה מפתח אפליקציות , BE או FE או תשתיות – כולם יכולים להשתמש באותם FLOWS ואותן שיטות עבודה בשביל להשיג ולקבל את אותם outputs .
אנחנו כצוות DevOps בחברה בחרנו לעבוד ב- Terraform .
Everything is CI/CD
אז באמת ההסתכלות שלנו על כל העבודה של GitLab ו- GitLab CI היא " Everything is CI/CD"
וזה לא משנה אם זו אפליקציה , Backend או Frontend או כל שינוי ברמת התשתית
אנחנו רוצים להסתכל להסתכל לעולם ה- INFRA ספציפית כ-
Infrastructure as code / service
ולכן אנחנו צריכים להתנהל כמו בכל שיטת עבודה,
כלומר עבודה מלאה עם git ועם ענפים (branches) ועם בדיקות
וסביבות dev ו- stage וכו'
כל דבר שאנחנו עובדים אנחנו רוצים גם ליישם אותן שיטות עבודה
אנחנו רוצים שגם כל ה- tests
בין אם זה בדיקות ספציפיות על מכונות
ובין אם זה OS
ואז אנחנו יודעים בוודאות שכל ה- roles שאנחנו עובדים איתם אכן יעבדו.
אותו דבר אנחנו גם עושים ב- Terraform
מדוע Terraform
תמיר: זה בעצם גם אומר שנניח חלילה העלתם משהו לא טוב אז אתם יכולים לעשות rollback ולחזור לגירסא קודמת, כי הכל versioned (מנוהל גירסאות) , נכון?
דוד: מדויק. אנחנו גם עושים versioning, אנחנו גם בתצורה של environments – ב- GitLab CI אפשר לחזור אחורה ל- git HEAD, ובגלל ש Terraform הוא mutable אנחנו נקבל את אותו ה- state שהיינו בו לפני X גירסאות (או commits) וכך אנחנו יכולים לחזור חזרה ל- HEAD לגירסא שאנחנו רוצים לעבור אליה.
אז זה מהבחינה של הצדדיים טיפה של העבודה ב- GitLab CI.
ה- pipeline שאנחנו בנינו – אקח דוגמה אחת -ש יש לנו – לקחנו את זה כמה צעדים קדימה והיום אנחנו מנהלים את Kafka topics שלנו דרך GitLab, הוספנו מודולים, עושים כל מיני וריפיקציות, ובדיקות על שמות של טופיקים, הם נקראים. יש לנו קונבנציה מסודרת איך Kafka topic נראה…
תמיר: א' אם יש לך אפשרות להראות את ה-pipeline, זה יהיה מעולה, וב' אם אתה יכול להסביר למה אתם משתמשים ב-Kafka ובכלל מה Kafka עושה, במשפט אחד.
על Kafka
דוד: OK, אם מישהו לא מכיר באמת את Kafka, זה אחד ה- message brokers היותר מוכרים והנפוצים שקיימים בעולם. זו מערכת שהתחילה ב-Linkedin ויצאה החוצה ע"י המפתחים שפתחו חברה משלהם. זה כלי מאוד מוכר כדי להעביר בו event-ים בצורה שהיא… Kafka זה היום מכונות community לגמרי, מקבל מסות גדולות של event-ים עם קונסומרים שכל אחד יכול לקחת מה-offset שלו. זה כלי שהוא אמין ברמה מאוד מאוד גבוהה, לכן הרבה חברות משתמשות בו ל…. Event-ים. אז זה Kafka. אחד הדברים שעושים ב-Kafka, שמייצים לו טופיקים. טופיק זה איזשהו סגמנט שמקבל data, ומתחתיו יש partition-ים וכמה consumer-ים וכו'. ומה שקורה שאנחנו למשל אם עובדים לסטנדרטיזציה, אחד הדברים שנוכחנו כשיצרנו את המודולים שלנו ב-AWS זה באמת להכין סטנדרטיזציה שחייבים להיות בה תגים לכל אחד מ-resource-ים וחייבים להיות בה גם type-ים וגם סטנדרטיזציה איפה כותבים וכמה כותבים, האם זה production או dev , השם של ה-VPC ועוד כל מיני שמות אחרים שבסוף עוזרים לנו להבין איזה VPC וכל resource לאן הוא שייך, במולטי… ב-Kafka היכולת הגדולה של Terraform באמת לעבוד מול כל מערכת מבוססת API שזה Cloud-native Infrastructure. בכמה מילים זה היכולת שלנו להתנהל בצורה של infrastructure as code מול כל מערכת מבוסס API , ו-Terraform הוא אחד מהם. יש לו יכולת לעבוד עם admin client של Kafka מגרסה 1 . הם הכניסו את זה ברמת API. אחד החבר'ה שפיתחו את ה-provider הזה ב-Terraform ל-Kafka הוא באמת כתב את האימפלמנטציה עם Sarama, ה-Go Client של Spotify , ומשם הדרך לייצר את כל מה ש-Terraform נותן היא יחסית קצרה.
אז בדוגמה שאנחנו ניתן פה זה באמת לראות איך אנחנו מוסיפים topic-ים בצורה יחסית קלה ואחר כך איך נראה כל ה-pipeline של CI/CD. אז בגדול ככה נראה ה-repository. ..
תמיר: אנחנו רואים עדיין, תנסה עכשיו אם התכוונת…
דוד: OK, אז אנחנו הולכים לראות איך נראה ה-pipeline של הפרויקט ספציפי הזה, איך אנחנו מוסיפים topic למערכת אחרי שהוא עובר כל שלבי הוולידציה ששוב יש ולידציה ברמת Terraform שהוא … סטנדרטי וולידציה של דברים אחרים, ואנחנו נראה איך זה נראה.
תמיר: אנחנו עכשיו בעצם רואים את ה-dashboard של GitLab של החברה עצמה.
דוד: נכון מאוד.
תמיר: ספציפית את ה- CI/CD.
GitLab CI Dashboard + Terraform Steps
דוד: נכון מאוד. זה מה שחשוב לצורך הוובינר הזה. נתחיל לראות. אז אלה כל השלבים שאנחנו עושים היום בשביל כל pipeline של GitLab של Terraform . יש לנו שלב "Validate" שמי שמכיר מ-Terraform, זה Terraform Validate. ואז אנחנו עושים בדיקת security קצרה לראות שאנחנו לא הכנסנו איזו שהם secrets בתוכו. אחר כך אנחנו עושים "Plan", שזה Terraform Plan למי שמכיר, אחר כך עושים "Apply". כל הדברים האלה בסופו של דבר, כל ה-pipeline הזה הוא transparent, הוא מבוסס גם branch-ים אם צריך. עכשיו branch-ים מבחינתנו זו יכולת לעשות את הדברים ב- multiple clusters. אם יש לי cluster ב-dev ויש לו branch משלו וזה יכול להתנהל בתצורה של dev בשלבים של "Stage" ו-"Production", ואחר כך אנחנו עושים "Release" בשביל להוציא גרסה ואחר כך נַרְאֶה איך זה נִרְאֶה גם בתוך ה-change שקורה בצורה אוטומטית עם כמובן גרסה שיוצאת.
תמיר: רק לוודא שאני מבין. למעשה מה שהראת זו תצוגה ויזואלית של משהו שמקור כתבתם ממש בתור קוד, נכון?
דוד: נכון מאוד.
תמיר: כלומר קובץ YAML של GitLab CI?
דוד: כן, אנחנו גם נראה את קובץ ה-YAML. אתם תראו שהוא מאוד קצר, הוא מאוד ספציפית Terraform. אנחנו נשתדל להגיע לזה בסוף.
תמיר: OK
דוד: מעולה. אז התחלנו עם ה-"Validate". ברגע שיש לנו "Validate", ה-runner-ים של GitLab CI קיבלו את המשימה שלהם ומאפשרים להתחיל לרוץ. ה-Docker שאנחנו עובדים מולו זה Docker ספציפי. זה Docker שאנחנו יצרנו, יש לו גם גרסה משלו כמובן ל-Docker ספציפי הזה.זו גרסה של Terraform שאנחנו קראנו … לפני שנעבור ל-Terraform 12. ולבסוף זו הגרסה של ה-provider שאנחנו עובדים איתו. אפשר לומר שבסוף יש לנו Docker image שיש לו בפנים כמה ומה provider-ים, כרגע provider אחד ובהמשך יצטרפו אליו provider-ים אחרים.
תמיר: את ה-image-ים שאתם מייצרים אתם שומרים ב-GitLab, באזור של ה-registry?
דוד: כן, אנחנו משתמשים בצורה מצוינת ב-registry של GitLab. ושוב,זה יכול לתת service למפתחים שבמקום לעבור לכל מיני מערכות חיצוניות, 3rd parties כאלה ואחרים, הם יכולים במקום אחד לראות כל מה שהם ירצו. גם ב-packages אנחנו משתמשים בשביל מעבר לפרויקט ההוא.
תמיר: מעבר ללראות, מה עוד פיתחת שמקבלים בתור self-service?
Self-service
דוד: ה-self-service שאנחנו מדברים עליו הוא באמת יכולת לנהל את ה-versioning, לנהל טסטים או בדיקת security. אז אנחנו נותנים איזשהו suite יחסית שהוא גדל עם הזמן, ורוצים להכניס יכולות של code quality ו- code coverage, ויכולת לעבוד עם stress tests. אנחנו נכניס את זה לאט לאט, אבל האמת כרגע אנחנו בעיקר מסתכלים על ה-security, ואלה הדברים שראיתם קודם ב- Gitleaks.
אנחנו מסתכלים על monoliths, אנחנו מסתכלים על… אם אנחנו מייצרים ב-Docker, אנחנו משתמשים גם בבדיקות של Docker וב-packages של ? Docker. אנחנו היום בהסתכלות מאוד רחבה על security, ובהמשך אנחנו נגיע קצת יותר ויותר לרבדים שאנחנו רוצים להסתכל, כל אחד מהארטיפקטים ומה- pattern שאנחנו מריצים.
תמיר: מרשים מאוד
דוד: אז נמשיך. זה באמת terraform init שאנחנו עושים, עכשיו בדלת האחורית, אנחנו רואים, אנחנו מורידים את כל המודולים. אני לא אכנס כרגע איך בנוי כל מודול, דווקא משהו שמאוד נחמד לדבר עליו, אבל זה לפעם אחרת. ה-workspace שאנחנו עובדים איתו master, שהוא מבחינתנו master, הוא נותן לינק ל-production.
אחרי שעשינו validate, זה אומר שמבחינת Terraform הקונפיגורציות שכתבנו הן קונפיגורציות ולידיות. לפני שאנחנו עושים plan, רק בואו נוודא דבר אחד קטן, שאין לנו שום זליגת סיסמא, משהו קשור אולי ל-AWS או איזה שהם ? או כל דבר אחר. אנחנו יכולים לראות שהרצנו את הקונטיינר של Gitleaks וקיבלנו שיש לנו אפס ? מתוך הקוד שלנו וגם בקומיטים שעשיתי. המבחן הקצר הזה עברנו.
Terraform plan
מה שאנחנו עושים, זה plan. שוב, אנחנו משתמשים ב- cache, שכולל את כל הדברים שהורדנו כבר לפני, כל המודולים שהורדנו לפני, ויש לנו שני טופיקים חדשים שיצרנו. אלה שמות של הטופיקים, אני כרגע לא אתעכב למה יש לנו שני טופיקים ולא אחד, אבל הרעיון הוא שבסופו של דבר Terraform מצא שה- stage שקיים אצלנו במערכת וה-stage שקיים ב-remote הם שונים אחד מהשני וזה שלב של ה- reconciliation של Terraform, וזה השינוי שהוא מצא ולכן הוא מצביע שמתחילים להיווצר שני טופיקים חדשים בתוך cluster ספציפי, וזה השם שלו. אנחנו גם הכנסנו יכולת לעבוד ב-enum-ים. במקום שכל אחד יכניס איזה שהם פרמטרים, חלק מהסטנדרטיזציה שעשינו, זה enum-ים של מספר partition-ים,וכמה זה ה-retention time ו-application factor. אנחנו נוסיף לדבר הזה עוד ועוד יכולות.
בכל מקרה ה- plan בסופו של דבר שהוא מאוד מאוד transparent, מאוד מובן, נתן לנו הבנה שאנחנו הולכים להוסיף שני טופיקים חדשים. רואים שיש פה play ליד ה-Apply, זה אומר שה-Apply שלנו אף פעם לא רץ בצורה אוטומטית. אגב, גם בדרך כלל (?) stage יורה בצורה אוטומטית אבל בפועל action לא רץ בצורה אוטומטית כי אנחנו רוצים לדעת מה הולך להשתנות, ולכן אנחנו נעשה את ה-Apply הזה בצורה של manual, מי שמכיר את התכונה הזאת ב-GitLab CI. כשעשינו את ה-Apply, אנחנו רואים שהוא הלך לתוך ה-cluster,מאמת יצר שני טופיקים, לקח לו שנייה, יצר את שני הטופיקים האלה, והם כרגע למעלה, יש לנו אישור שהם שניים נוצרו, ויש לנו state חדש למערכת. שוב, אנחנו, כחלק מה-pipeline שלנו, מייצרים כאן דבר הזה, Release. כדי אחר כך נוכל להתקדם לדבר הזה ייכתב בתוך איזה שהוא changelog, ואם אני רגע קופץ איך נראה changelog, אז תוכלו לראות שיש לנו changelog מאוד מעודכן שכל הדברים שכל הדברים שהשתנו בו בגרסה זאת, גרסה ספציפית שנקראת 0.0.2, יש לנו פה אפילו איזשהו עדכון מסוים עם ה-commit, זה איזשהו image שאנחנו משתמשים בו ואותנו יכולת לעשות version בצורה נקייה עם semantic release ו-semantic versioning בצורה אוטומטית.
כל מי שמייצר בצורה אוטומטית זה מה שהוא יגיע אליו. בסדר, ככה הוא יגיע. ככה הם ירוצו, והוא יידע מה צריך לשנות, ובסוף אנחנו נדע איזה דברים משתנים, אם דברים נוספו, ירדו, השתנו. אלה כל השינויים שקורים ב- Kafka, ושוב זו דוגמה אחת פשוטה, דברים שאנחנו עושים גם היום ב-AWS, אנחנו עושים את זה ב-InfluxDB, אנחנו עושים את זה עם mySQL, אנחנו עושים את עוד בעוד הרבה מאוד מערכות אחרות.
Include external files
אמרנו שאם תהיה היום איזושהי דקה בסוף, אני אתן איזושהי נקודה פה. אנחנו עובדים בצורה די אינטנסיבית מאוד עם GitLab CI עם ה-template-ים… זה לא דבר הזה, זה include, זה feature-ים חדשים שנכנסו בגרסאות די אחרונות של GitLab CI, וכמו שאתם רואים, במקום שיהיו פה gitlab-ci.yml של איזו שהם 150 או אפילו יותר שורות, של כל אחד מהדברים האלה, אז יש לנו מקום אחד שאנחנו מנהלים את כל ה-pipeline, ואנחנו בסך הכל עושים איזשהו include. גם פה כל מה שקשור ל-versioning נכנס פנימה בצורה חזקה, ועובדה שבגירסה 0.1.8 של אותו pipeline שלנו אני יודע מה אני הולך לקבל, אם עשיתי איזשהו שינוי ב-pipeline של Terraform, ב-pipeline של sbt או Maven או go או כל דבר אחר, אני יודע מה אני מצפה לקבל, כי יש לי changelog שהוא מאוד מאוד ברור מה השתנה בכל גרסה, אז אני לא ארחיב את הצד הזה של GitLab CI, ובגדול בתוך כל הדבר הזה, בתוך כמה שורות האלו, כל ה-pipeline המלא שראינו, ששוב שהוא נכון גם ל-multiple environments, multiple stages, כל הדברים האלה נכנסים פנימה בצורה נקייה וחלקה ע"י ארבע שורות שראינו.
אז ככה זה נראה, ככה אנחנו מנהלים היום, ואני אומר, היכולת בשימוש שלנו ב-Terraform רק עולה ועולה ועולה, ואצם זה שהכנסנו את היכולת ל-pipeline של בדיקות אוטומטיות, זה רק מעלה את השימוש גם שלנו וגם של מפתחים אחרים בתוך החברה, שימוש ב-Terraform וניהול הרבה יותר בטוח ונכון של כל infras שלנו בחברה.
אז ככה זה נראה, ובאמת זו רק ההתחלה שלנו.
תמיר: יפה מאוד, נראה מרשים מאוד.
דוד: תודה רבה.
תמיר: דוד, תודה רבה על השיתוף ועל התובנות, ובהצלחה!
דוד: תודה על האירוח, תמיר, ושיהיו עוד הרבה ובינרים איכותיים בהמשך.
תמיר: כן, בסדר, אני אשמח, למה לא.
דוד: תודה רבה.
חברת ALM-Toolbox מייצגת את החברות HashiCorp ו- GitLab בישראל ובמדינות נוספות, ומציעה יעוץ, תמיכה, הדרכות, עזרה בבחירת רישוי מתאים (on-premises או בענן), שירותים מנוהלים ומכירת רשיונות. ניתן לפנות אלינו במייל devops@almtoolbox.com או טלפונית 072-240-5222
קישורים רלוונטים:
