הקלטה: המסע של LivePerson מ- CI ל- CD בסקייל גבוה

אתמול אירחתי את ניר קורן לוובינר מעניין על המסע ל- Continuous Delivery בחברה בה הוא עובד – LivePerson .

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

בוובינר ניר הציג הקמת מערכת CI/CD מורכב בסקייל גבוה של 7 אתרים בעולם, עם עשרות Kubernetes clusters, מאות micro-services ועשרות-אלפי שרתים, פודים ו- builds שבועיים, ובין היתר השתמשו בכלים  git, GitHub, Kubernetes, HashiCorp Vault Enterprise, SonarQube, Prometheus, Kafka, Jenkins  .

ניר הציג למעשה  case study ושיתף בתובנות וב- best practices .

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

הקלטת הוובינר כאן:

נקודות מעניינות שעלו בוובינר:

• הקשיים שחוו עם Kubernetes בהתחלה ואיך התמודדו עם זה
• קצת מספרים:  12,000 פודים (pods) פעילים;  320 מיקרו-סרביסס (Kubernetes micro-services) ; כ- 25,000 בילדים (builds) שבועיים
• ניר והצוות שלו הטמיעו שיטה שבה המפתחים עצמם עובדים עם Kubernetes אך לא צריכים להכיר אותו – מה שעוזר להם להתמקד בכתיבת קוד
• ניר הסביר מדוע הם משתמשים ב- HashiCorp Vault וכיצד הם משתמשים בו כדי למנוע דליפת סודות ומידע רגיש
• חלק השאלות ותשובות מתחיל בדקה 25 (היו שאלות רבות וניר ענה על כולן)

רוצה לקבל מאיתנו עדכונים לכשנקיים וובינרים נוספים בנושאים דומים ונפרסם תכנים נוספים בנושא?
ניתן לשלוח אלינו את המייל הבא – אנו מבטיחים לשלוח רק תוכן רלבנטי ואיכותי, ללא ספאם.

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

• אתר Vault בעברית
• אתר SonarQube בעברית

תמליל הוובינר:

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

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

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

קצת על LivePerson:

אני מניח שכולנו כאן ישראלים כמעט , אז כולנו מכירים או לפחות שמעו על החברה. אנחנו מתעסקים עם Conversational AI and messaging, פתרונות של בוטים, AI-ים, מה שמוכר הרבה פעמים בתורת ה-chats. לא נכנס למוצר, תרגישו חופשיים להיכנס ל-liveperson.com אם אתם רוצים קצת ללמוד על החברה. החברה באמת קיימת מ-95, די ותיקה, יש לנו עשרים אלף לקוחות, 1200 עובדים בכל העולם. אנחנו מאה אחוז חברת cloud, מאה אחוז software service, אין לנו שום מוצר on-premises שאנחנו נותנים אותו, מתעסקים בהתקנות אצל לקוחות, הכל אצלנו ב-cloud. החברה היא אמריקאית, עם headquarters בניו-יורק. זה מצחיק להגיד שיש לנו 18 משרדים עכשיו. אף אחד מ-LivePerson בכל העולם לא נמצא במשרד בשום רגע נתון כרגע, כולם עובדים מהבית. אין עוד צפי בכלל  אם אי פעם בחזרה, כרגע כולנו home working מלא.

בואו נדבר קצת על המספרים:

חשוב לי להציג את המספרים כדי להסביר למה הגענו והטמענו את ה-best practices כמו שהטמענו.

אז אנחנו בעצם רצים ב-7 data center-ים בכל העולם, יש לנו כ-12,000 שרתים וירטואליים ופיזיים, איך שנחלק את זה.

מבחינת הקלאסטרים של Kubernetes, אז אנחנו רצים על 40 קלאסטרים של kubernetes ב-production, שמריצים 800 nodes של kubernetes. לא אמרתי לפני זה: אני מדבר הרבה על Kubernetes, אז מי שפחות מכיר את זה, תסלחו לי, לא נכנס לעומק כמובן. אנחנו רצים על 12,000 פודים אקטיביים ב-production, ובעצם כל המוצר שלנו  מול הלקוח זה  facing אחד של מוצר אחד, כמו LinkedIn לדוגמא, אבל אנחנו בעצם מריצים מאחורי הקלעים 320 micro-services של Kubernetes , כאשר כל micro-service ממש מוצר בפני עצמו, עם גירסא משלו, עם life-cycle משלו, ומתוכם כ-100 micro-services שהם קצת legacy, דברים שעדיין לא עברו, שבעידן הטרום Kubernetes , שרצים על Puppet ועל RPM.

מבחינת ה-build שלנו אנחנו מריצים 25,000 builds בשבוע, רובם ב-TeamCity, חלקם ב-Jenkins. מבחינת deployment אנחנו משנים את production  חמש מאות פעמים בשבוע. הקוד שלנו מנוהל על  GitHub repositories 5,000. לא לכל micro-service יש לו repository אחד, יש לנו המון repositories טכניים. המספרים כפי שאתם רואים די גדולים, בגלל זה זה הכריח אותנו באמת לעבור לאיזה מוד שאנחנו יודעים לנהל את זה.

מבחינת ה-data centers אנחנו חולשים על 7 data center-ים בעולם, בכל region יש לנו active ו-passive. באמריקה, באירופה וב-APAC שזה סידני, אמסטרדם, לונדון, אוקלנד ווירג'יניה. תל אביב זה  data center קטן. 

זה בגדול קצת הכרה של LivePerson וה-production שלנו. 

תהליכי ה- CI שלנו:

מבחינת תהליכי ה-CI שלנו, הם די סטנדרטיים. יש לנו המון המון build-ים, volume מאוד גבוה של build-ים ותהליכים. רוב ה-serverside שלנו מבוסס Java, Scala, nodeJS. הצד של המשתמש (client side) כמובן גם nodeJS. לא באמת משנה על מה אתם עובדים, באיזו טכנולוגיה, תהליכי CI שלנו זהים לחלוטין., ואני אכנס לזה בהמשך. בעצם ה-build שלנו ברגע שאנחנו משנים את ה-GitHub (אנחנו משתמשים ב-GitHub Enterprise, מותקן אצלנו , ה-clients רץ אצלנו בתוך הרשת),  TeamCity ימשוך את השינויים ויתחיל להריץ את התהליך של ה-build עצמו.

התהליך הוא די סטנדרטי, binaries יעלו ל-Artifactory ו-Docker images נארזים ויעלו ל-Harbor . Harbor זה למי שלא מכיר זה open source של VMware שהוא בעצם Docker Registry, ואז יבואו אנשים וישאלו למה אתם לא משתמשים ב-Artifactory כ-Docker Registry כי גם Artifactory  הוא Docker Registry, והתשובה היא כי בשביל שאנחנו נשתמש ב- JFrog Artifactory כ-Docker Registry, אנחנו צריכים לרפלק אותו לכל אחת מהחוות, ו-Artifactory כמה שאני מאוד מאוד אוהב את המוצר, ואנחנו מאוד אוהבים את החבר'ה שם, זה מוצר שהוא ברישיון, ואז אנחנו באמת צריכים לשכפל את הרישיון שלנו, וזאת הסיבה שבחרנו Harbor שהוא בחינם.

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

מבחינת scanning, אז אנחנו סורקים ב-SonarQube כל ה-static code analysis בעולם של ה-Java, ומבחינת dependencies scanning אנחנו משתמשים ב-WhiteSource, וב-Checkmarx שזה static code analysis ל-security. די ציונים כמו שאתם רואים פה. אנחנו, ואני אומר את זה, באמת  מעדיפים חברות ישראליות, ככה זה יוצא, אבל בסופו של דבר ברגע שנגמר תהליך של CI וה-release …. ע"י המפתח, הוא יכול לעשות לו deployment בעצמו, למערכות ה-production בעזרת כלי deployment שאנחנו נותנים לו.

מ- CI אל CD

בואו נעשה יישור קו קצת כי אנחנו הולכים לדבר על CI/CD. כשאנחנו אומרים CD, יש שתי משמעויות למונח הזה. CD אחד זה Continuous Deployment, והשני הוא Continuous Delivery. ההבדל הוא כמו שאתם רואים, פה יש לנו build ו-deployment וטסטים שהם יחסית אוטומטיים. בעולם של continuous deployment ה-deployment ל-production יהיה אוטומטי, זאת אומרת שברגע שעשיתי שינוי ב-master branch או ב-branch אחר שלי, תוך X זמן, כולל טסטים, אנחנו נגיע ל-production. לעומת זאת, continuous delivery – זה רוב הסרביסים שלנו היום, חלקם ב-Continuous Deployment, בעצם התהליכים יקרו אוטומטית והקליק ל-production יבוצע ידנית,  גם ע"י המפתח. 

יש לנו תהליכי continuous deployment, אצלנו חלק לא קטן כבר מה-service-ים מגיעים לא בדיוק עד ל-production. כרגע יש לנו כמה obstacles שאנחנו צריכים לעבור, אבל יש לנו תהליך CI רגיל שברגע שהוא מסתיים אנחנו מוצאים deployment ל-QA ול-staging שלנו וממש לגרסאות שהן שנייה אחת לפני ה-production, שאנחנו מתייחסים אליהן לגמרי כמו production, כאשר בין כל סביבה לסביבה יש טסטים אוטומטיים שבודקים אותה, והתהליך הזה לגמרי אוטומטי, לגמרי מה שנקרא ללא מגע יד אדם.

אז בעצם המפתחים שלנו הם אלה שעושים את ה-deployment ל-production, הם אלה שבעצם אחראים על כל התהליך מהרגע שהם כותבים את הקוד עד הרגע שזה רץ ב-production. אני חושב שזה באיזה שהוא מקום מסכם מה זה DevOps culture בסופו של דבר. 

Best Practices

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

אז בואו נתחיל מ-best practice הראשון שלנו. הראשון זה internal building block.  מה זה אומר? בעולם של microservices הרבה פעמים יש כפילויות ודברים שחוזרים על עצמם. זאת אומרת, אני ה-microservice  שלי רץ על Centos, רץ על Tomcat לדוגמא, ואני בחרתי Centos. למה? כי ככה אני אוהב. ומישהו אחר בחר Ubuntu, כי ככה הוא מכיר מהבית, וכל אחד עושה "FROM centos/ubuntu" משהו אחד, תופר עליו את מה שהוא רוצה, תופר עליו JPK, תופר עליו Tomcat, תופר עליו כל מיני דברים של הארגון שלו, כל מיני תפירות של כל מיני אפליקציות קטנות, בסופו של דבר אנחנו חוזרים על עצמנו כל הזמן ואין אפשרות לנהל את זה. מה שאנחנו עושים, אנחנו בעצם מספקים building block, אנחנו לוקחים את Centos הרשמי , סורקים אותו, בודקים אותו, שמים עליו את כל הדברים של LivePerson, ונותנים לו שם אחר, LP-centos7 נגיד, ובסופו של דבר אתם כמפתחים משתמשים ב-LP-centos7 ואתם יודעים שאתם מקבלים גם את כל הדברים שאתם לא צריכים לתפור בצורה ידנית וגם את כל ה-clients וה-certification שאנחנו סרקנו, בדקנו ונתנו לכם מוצר שעובד. כמובן מי שמכיר Docker, אם אתם משתמשים כל הזמן ב-latest, אתם לא צריכים לדאוג מ-patch-ים ומ-OS patches וכל מיני דברים כאלה שהרבה פעמים אנחנו נוטים להתעסק ולא ממש אוהבים לעשות את זה. 

אז בעצם איך אנחנו עושים building block? לוקחים את הדבר הרשמי , תופרים עליו את מה שאנחנו צריכים, נותנים לו שם מסוים וגירסא מסוימת ועושים לו push ל-Docker registry ובסופו של דבר אנחנו אומרים לכם, "חבר'ה", אם אני מסתכל משמאל לימין, "תקחו את 7 Centos ותקראו לו LP-Centos7 או איך שבא לכם ותשתמשו בדבר שכבר הכנו לכם עליו". 

איזה building blocks יש לנו? יש לנו בעצם על ה-Centos כמו שנתתי בדוגמא, ל-Node.js, ל-Jenkins, ל-OpenJDK, ל-Tomcat, ל-Nginx, דברים שאנחנו באמת חוסכים למפתחים את כל הכאב ראש של ה-onboarding, ואת כל התפירות של הדברים החדשים. מי שמכם התקין Jenkins יודע ש-"וואלה מה אני צריך עכשיו בכל מקום שאני מרים את השרת Jenkins להתחיל להגדיר מחדש – לא יודע מה – את ה-SMTP שלי או כל דבר אחר." הדברים האלה מוכנים בתוך ה-building block שאנחנו מציעים. אתם יכולים רק להשתמש.

ה-best practice הבא שלנו זה archetype. מה זה אומר בגדול? ברגע שאתם יוצרים פרויקט חדש,  אתם יכולים ללחוץ על כפתור אחד וייווצר לכם בעצם כל הפרויקט עם כל מה שאתם צריכים. כל מי שמפתח פה, מכיר את השיטה איך יוצרים פרויקט חדש. לוקחים פרויקט חדש שהוא עובד, עושים לו copy-paste, משנים את השם, והנה יש לי פרויקט חדש. יוצרים GitHub repository, יוצרים job ב-Jenkins, הכל עובד, אלא מה: אנחנו לוקחים אתנו גם את כל הזבל מהפרויקט הישן. לא הכי אידיאלי. מה אנחנו עושים? אני אתן כאן דוגמה של Java ו-Maven בשביל להמחיש את זה. אם אני עכשיו רוצה ליצור פרויקט חדש, שהוא מבוסס Java ו-Maven, אני לוחץ על כפתור, בוחר את השם שאני רוצה לתת לו, באותו רגע נוצר לי ממש המבנה של Maven עם src/main/java, ו-src/main/resources, והטסטים. יש שם איזה "Hello world" קטן ממש עם unit test בסיסי שממחיש לי שהכל עובד. אני מקבל איזה סקלטון של Dockerfile, שממש מביא לי פה Centos עם ה-Tomcat, או מה שאני רוצה, וסקלטון של Kubernetes, וסקלטון של system test שרק נותן ping כשמערכת עלתה.

בעצם בלחיצת כפתור, לא כתבתי שורת קוד אחת, ותוך חמש שניות אני מקבל את זה. אני מקבל GitHub repository וכל מה שהראתי בסלייד הקודם עולה ל-GitHub repository, ונוצר לי job, במקרה שלנו,  ב-TeamCity מכל הסוגים, ובעצם יש לי "Hello world" שעובד בתוך 5 שניות וכל מה שאני צריך לעשות זה להעיף את "Hello world" ולהכניס את הקוד שלי ואני לא צריך עם קונפיגורציה של Kubernetes. חלק גדול מהמפתחים שלנו אין להם מושג בכלל להשתמש ב-Kubernetes, זה לא מעניין אותם, הם מתעסקים בפיתוח קוד, ואנחנו נותנים להם את התשתית. אם מחר אני רוצה להוסיף משהו חדש ב-archetype שיוותר עבור כל פרויקט, אני משנה את זה במקום אחד, וכל פרויקט שנוצר מעתה והלאה יווצר עם ה-archetype הזה.

Service Catalog

ה- best practice הבא שאני רוצה להעלות הוא ה-service catalog. service catalog בעצם כל service ב-Kubernetes שלנו יושב ב-database, הנתונים עליו, וה-database חשוף ב-API וכמובן יש לו UI מאוד יפה. זה אומר לדוגמא שאני ב-database מחזיק, לדוגמא, עבור כל סביבה לאיזה namespace הוא אמור להיות deployed, כמה רפליקות הוא אמור לראות בכל סביבה, כמה memory וכמה CPU ובסופו של דבר אני יכול לתחזק את זה ב-UI מסוים, וכל פעם שאני מייצר משהו – זה רק דוגמא קטנה של – אבל כל הדברים שרלוונטיים ל-service הזה נמצאים שם. וכל הדברים האלה כמובן נחשפים בצורה RESTfully ל-API, ואני יכול לגשת אליהם מכל tool, ובעצם כל deployment שקורה אצלנו, בין אם זה CI, בין אם זה  production, בין אם זה כל deployment שהוא, לפני שאני עושה deploy לכל service, אני שואל את ה-database מה אני צריך לדעת על ה-service הזה, ואני מתערב באובייקט תוך כדי deployment. זה אומר שאתם יכולים לכתוב ב-YAML שלכם שאתם רוצים לרוץ עם 10 רפליקות. למה? ככה! "כמה שיותר יותר טוב", הרבה פעמים שמעתי את המונח הזה, זה פחות מעניין אותנו, מעניין אותנו מה שיש בקטלוג עצמו, אז אנחנו בעצם עושים override לכל מה שיש שם, והקטלוג זה ה- single source of truth שלנו.

בואו נדבר על secrets ו- configmap:

זו בעייה כואבת למי שעובד עם Kubernetes, איך אני מנהל את ה-secret-ים שלי ואת ה-configmaps שלי? איפה אני מנהל אותם, איך אני מחזיק אותם?
יש לי secret שהוא רלוונטי לכל סביבה, איפה אני מחזיק את זה בקוד? שאלה שהיא מאוד בעייתית.
אז אנחנו בעצם מנהלים את הכל ב- GitHub. תשאלו למה, איך זה יכול להיות ב-GitHub, איך זה secure?
אני אסביר: אז בעצם מה שקורה, אנחנו מחזיקים מבנה עץ ב- GitHub. אם אני מסתכל פה, נגיד על ה-DEV או על PROD, נגיד אני רוצה לעשות deployment בחווה שלנו בווירג'יניה, אז אני מחזיק מבנה תיקיות שיש לי על כל US, על כל וירג'יניה ואני מחזיק שם את service שלי. ופה אני אזרוק את כל ה-secret-ים וה-configmap שרלוונטי ל-service שלנו בווירג'יניה.זה אומר שאם אני עושה deployment לווירג'יניה, הוא יגש לפה, יקח את ה-secret-ים וה-configmap מפה, יגיע לפה, אם הוא ימצא את השם של ה-service שלי בתיקייה עם דברים שהם רלוונטיים לכל US, אז הוא יאסוף את זה מפה ובסופו של דבר הוא יאסוף ערימה של secret-ים ו-config maps ואיתם הוא יוכל לגשת ולעשות להם deployment.
עכשיו, עד כאן הכל טוב ויפה. עד שהטמענו את HashiCorp Vault היו לנו באמת את כל ה-secret-ים וה-configmap שם, ואז אנשים אמרו, "רגע, זה לא secure!", כי אם אני עושה clone ל-repository הזה ומישהו גנב לי את הלפטופ, יש לו את הסיסמאות לכל ה-production, ואז אמרנו, "נכון, ברור, הגיוני", הפכנו את ה-repository הזה ל-private ונתנו רק לכמה engineer-ים לראות אותו, אבל זה עדיין לא פתר את הבעייה – ואז הטמענו את Vault אצלנו בארגון כחלק מהפתרון הכולל שיש לנו על Vault

על הטמעת HashiCorp Vault (דקה 20:03 בוידאו)

עשינו את הדבר בצורה הזאת בעצם:
ב- repository הזה של ה-secret-ים, של כל ה-secret-ים, וכל ה-service-ים, וכל הסביבות שיושבים ב-GitHub repository אחד אין שום value של סיסמא, או username או כל דבר אחר. במקום זה מה אנחנו עושים? אנחנו שמים… – אנחנו רואים אם אנחנו מסתכלים בסלייד – אני רואה פה דוגמא ל-YAML של secret – במקום לשים פה key ו-value או key ו-value ו-base64 בהצפנה – ב-encryption של base64 – מה שאני עושה אני פשוט שם פה נתיב ל-Vault. וכמו שאתם רואים, אני שם נתיב ל-Vault ואיזה key לחפש לי ב-Vault. מה שקורה במהלך ה-deployment, ה-deployment tool שלנו – אני אדבר עליו עוד רגע – מה הוא עושה, הוא לוקח את הנתיב הזה, הוא לוקח את את ה-secrets, לפני שהוא עושה לו deploy, הוא לוקח את ה-key, הוא נגש לנתיב הזה ב-Vault, מביא את ה-value של ה-key שנמצא פה, מחליף באובייקט – לא בקובץ, כן – באובייקט עצמו של ה-deployment, הוא מחליף את ה-key ובסופו של דבר הוא עושה apply ל-secrets עם ה-value האמיתי שהוא הביא אותו מתוך ה-Vault. אף אחד לא רואה את זה, הדבר הזה מתבצע בתוך ה-cluster עצמו שזה אומר שאנחנו לא מתעסקים בכלל עם הדבר הזה – וזה מבחינתנו הכי secure שיש. המפתח מבחינתו מגדיר חד פעמי נתיב ב-secret ואת ה-value הוא מנהל בתוך ה-Vault עצמו. הם ניגשים ל-Vault, עושים login, ומנהלים בעצמם את מה שהם צריכים. ה-secret הוא באיזשהו מקום place holder לאיפה לחפש ב-Vault, ובפועל ה-deployment tool שלנו, מה שדורס אותו.

איך אנחנו משנים secrets ?

אז כמובן המפתח משנה את הכל בצורה אוטומטית, עושה Pull Request, יש  job שרץ ובודק שהוא לא שבר את ה-YAML עצמו, ובמידה והכל בסדר , הוא יכול לעשות merge ל-PR ולהכניס את כל ה-configmap ו- secret או כל מה שהוא רוצה. ככה אנחנו מוודאים שהוא לא שבר לנו את ה-production בבסיס.

Deployment

ה-best practice הבא זה ה- deployment engine. בעצם ה-deployment  שלנו ל-Kubernetes הוא הרבה מעבר ל-"kubectl apply -f". בעצם בתהליך ה-deployment יש לנו כלי מאוד גדול שעושה deployment, שכל service שעושה deployment מפעיל את אותו כלי. אנחנו גם עושים את כל ה-resource-ים לפי סביבה מהעץ שהראתי. אנחנו גם עושים dependency, עושים validation ו-verification, וכמובן הדבר הכי חזק בכלי הזה אנחנו משנים את האובייקט לפני ה-deployment לפי מה שצריך להיות. כי שוב אין לנו שליטה שיש מלא microservices, ואין לנו שליטה כמה מפתחים ישימו ומה הם ישימו ופתאום אחד שם 30 ג'יגה RAM כי ככה זה מגניב לו, כי מה אכפת לו,  ואז הקלאסטר שלנו נחנק. אנחנו משתמשים במה שצריך ואנחנו עושים את החישובים באמצעות ה-deployment tool ומשנים את האובייקט, ומה שיפה בזה שכל הקלאסטרים שלנו בין אם זה CI או QA או Production משתמשים באותו deployment tool ובסופו של דבר אנחנו יכולים לשלוט במה יהיה, ואם אני רוצה עכשיו להוסיף לזה יכולת או וולידציה, אני מוסיף את זה ל-tool עצמו ומעתה והילך כל deployment יקבל את השינוי שעשיתי. 

דבר אחרון, אנחנו משתמשים ב-GitHub לא רק כ-source code repository, אנחנו משתמשים בו גם כ-deployment repository, ואני אסביר:

מה שזה אומר, אין לנו בפרויקט שאנחנו יוצרים, בכל microservice, אין לנו שום hardcoded value שהוא מתחלף. לדוגמא, ב-deployment YAML אנחנו לא מחזיקים את ה-Docker image, מן הסתם. מה שקורה, במהלך ה-build אנחנו מחשבים מה צריך להיות ואנחנו מחליפים את הערך באותו YAML ועושים לו push ישירות ל-GitHub repository מתייגים אותו עם הגירסא. בעצם יש לנו GitHub organization שהוא טכני לחלוטין שתחתיו כל repository מייצג service, ואם אני מסתכל על הדוגמא פה, כל תג מייצג גירסא. ברגע שאני רץ על התג, אני מקבל את אותם YAML-ים עם  hardcoded values שנוצרו באותו build ספציפי.

מה שזה אומר, שאני יכול בעצם לגשת, ה-deployment tool שלי יכול לגשת ל-GitHub, לעשות grab לכל ה-YAML-ים שהוא צריך לפי גירסא מסוימת , ואין לי שום מקום שאני צריך להחזיק אותם, ויש לי בעצם מקום אחד שכל מי שיעשה ל-lp-playground-app, בדוגמא הזאת בגירסא הזאת ייקח את ה-YAML-ים באותו מקום. לא תהיה שום כפילות, מאוד קל לי להבין מה יש בכל גירסא, מאוד קל לעקוב אחרי זה, ואם אני רוצה להעיף גירסא מסוימת, מאוד קל לעשות את זה. 

שאלה מהצ'ט: Data center – זה Azure, AWS, GCP?

אנחנו data center-ים פרטיים, אנחנו מחזיקים אותם, פה ושם משלמים לחברות חיצוניות שילכו להוציא איזה כבל רשת ולהכניס כבל רשת, וה-data center-ים שלנו הם פרטיים, הם מסיבה מאוד היסטורית, לקוחות דרשו שה-data שלהם יישב שם, יש הרבה פוליטיקה. לא יודע האם אתם יודעים, אבל מי שמשתמש ב-AWS, לעולם Walmart לא יהיה הלקוח שלו. יש כל מיני פוליטיקות קטנות, אמריקאיות כאלו. ה-data center הוא שלנו, יש לזה המון חסרונות כמובן, יש לזה המון יתרונות כמובן, אבל זאת התשובה.

"ואו, מרשים!": תודה רבה. איך ה-developers עובדים עם Kubernetes? אם הבנתי את השאלה ואנחנו מדברים על הסביבה לוקאלית, אז המפתחים אצלנו משתמשים ב-Kubernetes building שבא בתוך התקנה של Docker ל-Mac – אני פחות מכיר את זה ב-Windows. יש כאלה שמשתמשים ב-Minikube, כל הכלי deployment שאנו תומכים, כל הכלים האלה, אני מוסיף עכשיו איזו יכולת מסוימת לכלי deployment, אני ברוב המקרים אשתדל גם לבדוק את זה על הכלים הלוקאליים הסטנדרטיים שבאים.

אני מקווה שעניתי על השאלה.

האם הכלי שהראת, service catalog, הוא מוצר קיים? הוא מוצר נטו שלנו, פיתוח שלנו, הכל התחיל מ-database ו-API ואז התפתח UI. זה מוצר מאוד גדול, מאוד מרכזי, אחד המוצרים הכי קריטיים. אם הוא למטה אף אחד לא יכול לעשות שום deployment אצלנו.

האם אתם משתמשים ב- ISTIO או ב-service משלכם? אנחנו עכשיו מטמיעים את ISTIO אצלנו והתחילו כבר סנוניות ראשונות של service-ים שרצים עם זה.

איך אנחנו מנהלים את השדרוגים של 40 קלאסטרים? אנחנו משתמשים ב-Puppet. בסופו של דבר יש לנו צוות שמנהל כל ה-core של הסביבה, הכל מנוהל אצלנו ב-Puppet.

“What’s the big advantage of your deployment tool over using Jenkins?”

ניר: Jenkins, אנחנו משתמשים בו. Jenkins מריץ את ה-deployment tool שלנו. אם אני עושה deployment ל-service מאוד מאוד פשוט ל-Kubernetes, מספיק לי לעשות  kubectl -f, אבל אם אני רוצה להוסיף לו כל מיני יכולות, אם אני רוצה לוודא שהדברים ב-YAML-ים הם לפי הסטנדרטים שלי כארגון, אם אני רוצה לרשום אותו ל-DNS, אם אני רוצה לעשות אותו המון המון המון דברים מסביב, זו רשימה מאוד ארוכה של דברים שאנחנו עושים כחלק מה-deployment, אין לנו אפשרות לעשות את זה. אני יכול לכתוב איזה pipeline שעושה את כל הדברים האלה, אבל יש לנו כלי שאנחנו מריצים אותו ו-Jenkins פשוט מריץ אותו בסופו של דבר. 

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

“Hi thanks, so developers have access to Vault and can so cleartext password or production once creating enough to Vault”

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

בואו נעבור לחלון של Q&A. 

If developer has its own Kubernetes cluster 

התשובה היא לא. יש קלאסטרים ל-dev, קלאסטרים ל-CI. מי שרוצה לרוץ עצמאית בלי שאף אחד לא יפריע לו,  רץ על הלפטופ. אז זאת התשובה.

ה-seed שלכם נשמע טוב, האם אתם מתקינים אותו מול ה-seed שקיים לדוגמא ב-react-spring והאם הוא open source?

אז הוא לא open source. הכוונה בטח ל-project archetype. אנחנו משתמשים ב-Node.js, אז אנחנו לוקחים את ה-Node.js שאנחנו רוצים ותופרים עליו דברים של הארגון שלנו על ה-image עצמו. זה דברים שלא נכון להוציא אותם כ-open source, כי הם הדברים מאוד נכונים רק אלינו ובסך הכל Docker image שאנחנו בונים.

איך אתם מתנהלים עם ניטור של ה-deployment?

אם הכוונה לניטור של ה-runtime עצמו, של מה שרץ, יש לנו צוות monitoring, יש לנו כל הכלים הסטנדרטיים של Prometheus וכל כלי הניטור שאנחנו משתמשים. אני פחות בעולם הזה של monitoring. מבחינת הניטור של ה-deployment עצמו בזמן ה-deployment, אם הכוונה הייתה לשאלה זאת, כמובן אנחנו לא מסיימים deployment עד שה-pod הוא לא בסטטוס של Ready. לא רק Run, אלא Ready.

האם אתם עושים upgrade-ים in-place ל-Kubernetes cluster?

כן, אם אני הבנתי נכון. In-place upgrades? אני אולי פחות הבנתי את השאלה…

ה-Jenkins שלכם רץ גם על Kubernetes? מה קורה כשכולם בחברה עושים push, האם הוא עושה scaling?

ה-Jenkins שלנו רץ על Kubernetes רק ב-CD. תהליכי ה-CI אצלנו ברובם רצים על TeamCity שהוא לא רץ על Kubernetes. ה-Kubernetes אצלנו – גילוי נאות – ה-Jenkins master רץ על Kubernetes, ה-Jenkins slaves רצים על VM-ים. יש לנו מספיק VM-ים שמנוהלים ב-Puppet, ואנחנו בלחיצת כפתור יכולים להרים. עוד לא עברנו לשלב שה-VM-ים רצים על Kubernetes כי הבעייה מאוד פשוטה אנחנו לא רוצים להתנהל עם Maven שמוריד מחדש את ה-dependencies עבור כל build. תחשבו שלכל build שנכשל אני צריך לבנות את ה-M2 שלי מחדש ו-Kubernetes  לא הצליח לענות על זה כרגע.  ב-Node.js יש מקום להכניס זה, ב-Java זה פחות יעיל. זאת הסיבה שאנחנו עדיין לא משתמשים בזה.

Security-minded development

מה השאלה? איפה אנחנו דוחפים security במהלך הזה? אם הבנתי נכון את השאלה, אז אנחנו דוחפים security במהלך ה-CI שאנחנו סורקים ב-WhiteSource , ה-Checkmarx רץ כ-nightly build ומנוטר ע"י אנשי ה-security. זה בגדול, וכמובן יש גם מחלקת security שלמה שעובדת עם המפתחים וצמודה אליהם ומלווה אותם.

בגלל שמשתמשים ב-Puppet ו-data center-ים פרטיים, האם אתם משתמשים ב- Packer?

לא מכיר, לא. שמעתי את השם הזה, אנחנו לא משתמשים בדבר הזה.

בואו נראה האם יש עוד שאלות…

ניר: זה כמו שאמרתי לפני, פשוט הסשן הזה בדרך כלל ארוך יותר, אני בדרך כלל צולל פנימה לכל נושא והכל. ניסיתי לדחוף הכל ב-20 דקות כזה, לתת לכם קצת overview איך אנחנו משתמשים, איך Vault עזר לנו מבחינת האבטחה של העץ של ה-secret-ים וכל ה-best practice-ים שאנחנו בנינו עם הזמן ולמדנו בדם, מה שנקרא, כדי לנהל את כל הכמות הזאת של ה-microservice-ים.

ותרגישו חופשי לפנות אלי אם יש לכם שאלות, בשמחה.

תמיר: ניר, תודה רבה! 

 ניר: בכיף!

תמיר: היה סופר מעניין. אני אומר את זה בתור מישהו שהקשיב פעם שנייה גם.

ניר: אחלה, תודה!