שלום לכולם! שמי פאבל אגלצקי. אני עובד כמוביל צוות בצוות שמפתח את מערכת המסירה של למודה. בשנת 2018, דיברתי בכנס HighLoad++, והיום אני רוצה להציג תמליל של הדו"ח שלי.

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

פריסת יישומים ל-VM

נתחיל מזה שלפני 3 שנים כל המערכות והשירותים של החברה נפרסו על גבי שרתים וירטואליים רגילים. מבחינה טכנית, זה היה מאורגן כך שכל הקוד למערכות שלנו אוחסן והורכב באמצעות כלי הרכבה אוטומטיים, באמצעות ג'נקינס. באמצעות Ansible, הוא הושק ממערכת בקרת הגרסאות שלנו לשרתים וירטואליים. יתרה מכך, כל מערכת שהייתה לחברה שלנו נפרסה על 2 שרתים לפחות: אחד מהם על הראש, השני על הזנב. שתי המערכות הללו היו זהות לחלוטין זו לזו בכל הגדרותיהן, הספק, תצורה וכו'. ההבדל היחיד ביניהם היה שהראש קיבל תעבורת משתמשים, בעוד שזנב מעולם לא קיבל תעבורת משתמשים.

למה זה היה?

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

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

אילו יתרונות ראינו בכל זה?

1. קודם כל, זה מספיק זה פשוט עובד. כולם מבינים איך תוכנית פריסה כזו עובדת, מכיוון שרוב האנשים פרסו אי פעם לשרתים וירטואליים רגילים.
2. זה מספיק באופן מהימן, מכיוון שטכנולוגיית הפריסה פשוטה, נבדקה על ידי אלפי חברות. מיליוני שרתים פרוסים בדרך זו. קשה לשבור משהו.
3. וסוף סוף יכולנו להשיג פריסות אטומיות. פריסות המתרחשות בו זמנית עבור המשתמשים, ללא שלב מורגש של מעבר בין הגרסה הישנה לחדשה.

אבל ראינו גם כמה חסרונות בכל זה:

1. בנוסף לסביבת הייצור, סביבת הפיתוח, ישנן עוד סביבות. לדוגמה, qa וקדם ייצור. באותה תקופה היו לנו שרתים רבים וכ-60 שירותים. מסיבה זו זה היה הכרחי עבור כל שירות, שמרו על הגרסה העדכנית ביותר עבורו מכונה וירטואלית. יתרה מכך, אם ברצונך לעדכן ספריות או להתקין תלות חדשה, עליך לעשות זאת בכל הסביבות. היה עליך גם לסנכרן את הזמן שבו אתה עומד לפרוס את הגרסה החדשה הבאה של היישום שלך עם הזמן שבו devops מבצע את הגדרות הסביבה הדרושות. במקרה זה, קל להגיע למצב שבו הסביבה שלנו תהיה שונה במקצת בכל הסביבות בבת אחת. לדוגמה, בסביבת QA יהיו כמה גרסאות של ספריות, ובסביבת ייצור יהיו כאלה שונות, מה שיוביל לבעיות.
2. קושי לעדכן תלות האפליקציה שלך. זה לא תלוי בך, אלא בקבוצה השנייה. כלומר, מצוות devops שמתחזק את השרתים. עליך לתת להם משימה מתאימה ותיאור של מה שאתה רוצה לעשות.
3. באותה תקופה רצינו גם לחלק את המונוליטים הגדולים הגדולים שהיו לנו לשירותים קטנים נפרדים, שכן הבנו שיהיו עוד ועוד כאלה. באותה תקופה כבר היו לנו יותר מ-100 מהם. לכל שירות חדש היה צורך ליצור מכונה וירטואלית חדשה נפרדת, שגם אותה היה צריך לתחזק ולפרוס. בנוסף, אתה לא צריך מכונית אחת, אלא לפחות שניים. לכל זה נוסף סביבת ה-QA. זה גורם לבעיות ומקשה עליך לבנות ולהפעיל מערכות חדשות. תהליך מורכב, יקר וארוך.

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

חשבנו הרבה זמן איזה מהם נוכל לקחת. העובדה היא שבאותו זמן ערימת הפריסה הזו בשרתים וירטואליים רגילים הייתה מיושנת במקצת, מכיוון שלא היו להם את הגרסאות העדכניות ביותר של מערכות ההפעלה. בשלב מסוים, היה אפילו FreeBSD, שלא היה נוח מאוד לתמיכה בו. הבנו שעלינו לעבור אל docker מהר ככל האפשר. ה-devops שלנו בחנו את הניסיון הקיים שלהם עם פתרונות שונים ובחרו במערכת כמו Nomad.

עבור לנומד

Nomad הוא מוצר של HashiCorp. הם ידועים גם בפתרונות האחרים שלהם:

"קוֹנסוּל" הוא כלי לגילוי שירותים.

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

"מְשׁוֹטֵט" מאפשר לך לפרוס מכונות וירטואליות באופן מקומי או בענן באמצעות קבצי תצורה ספציפיים.

Nomad נראה אז כמו פתרון פשוט למדי שניתן לעבור אליו במהירות מבלי לשנות את כל התשתית. בנוסף, זה די קל ללמוד. זו הסיבה שבחרנו בה כמערכת הסינון למיכל שלנו.

מה אתה צריך כדי לפרוס את המערכת שלך לנומאד?

1. קודם כל אתה צריך תמונת docker האפליקציה שלך. אתה צריך לבנות אותו ולמקם אותו במאגר התמונות של docker. במקרה שלנו מדובר בארטיפקטורה - מערכת המאפשרת לדחוף לתוכה חפצים שונים מסוגים שונים. זה יכול לאחסן ארכיונים, תמונות docker, חבילות PHP מלחינות, חבילות NPM וכן הלאה.
2. נדרש גם קובץ תצורה, שיגיד לנומד מה, איפה ובאיזה כמות אתה רוצה לפרוס.

כשאנחנו מדברים על Nomad, הוא משתמש בשפת HCL כפורמט קובץ המידע שלו, המייצג שפת התצורה של HashiCorp. זוהי ערכת על של Yaml המאפשרת לך לתאר את השירות שלך במונחים של Nomad.

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

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

לכן, החלטנו שיהיה לנו נוח לאחסן את כל קבצי התצורה שלנו לפריסה במאגר אחד משותף. כך הם היו גלויים: הם היו קלים לתחזוקה ויכולנו לראות אילו מערכות יש לנו. אם יש צורך, קל גם לעדכן או לשנות משהו. הוספת מערכת חדשה היא גם לא קשה - אתה רק צריך ליצור קובץ תצורה בתוך הספרייה החדשה. בתוכו נמצאים הקבצים הבאים: service.hcl, המכיל תיאור של השירות שלנו, וכמה קבצי env המאפשרים להגדיר את השירות הזה בדיוק, הנפרס בייצור.

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

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

כלומר, החלפנו כמה משתני מיקום בתצורה במשתנים שהוכנסו שנלקחים מקבצי env או מקורות אחרים. בנוסף, קיבלנו את ההזדמנות לאסוף קבצי HCL באופן דינמי, כלומר, אנו יכולים להשתמש לא רק בהכנסות משתנים רגילות. מכיוון ש-jinja תומך בלולאות ובתנאים, אתה יכול גם ליצור שם קובצי תצורה, המשתנים בהתאם למקום שבו בדיוק אתה פורס את היישומים שלך.

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

כאשר שירות Nomad כבר פרוס באשכול שלך, זה נראה כך.

ראשית, אתה צריך איזשהו איזון בחוץ, שיקבל את כל תעבורת המשתמשים. הוא יעבוד יחד עם Consul ויברר ממנו היכן, באיזה צומת, באיזו כתובת IP נמצא שירות ספציפי המתאים לשם דומיין מסוים. השירותים בקונסול מגיעים מ-Nomad עצמה. מכיוון שמדובר במוצרים של אותה חברה, הם די קשורים זה לזה. אנו יכולים לומר שנומד מחוץ לקופסה יכול לרשום את כל השירותים שהושקו בו בתוך קונסול.

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

כמה עלה לנו המעבר מבחינת משאבי אנוש?

המעבר של החברה כולה לנומד ארך כ-5-6 חודשים. עברנו על בסיס שירות אחר שירות, אבל בקצב די מהיר. כל צוות היה צריך ליצור קונטיינרים משלו עבור השירותים.

אימצנו גישה כזו שכל צוות אחראי ל-docer images של המערכות שלו באופן עצמאי. DevOps מספקים את התשתית הכללית הדרושה לפריסה, כלומר תמיכה באשכול עצמו, תמיכה במערכת ה-CI וכו'. ובאותה תקופה הועברו לנו יותר מ-60 מערכות שהסתכמו בכ-2 מכולות.

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

סיבות לנטישת Nomad

אילו יתרונות קיבלנו על ידי מעבר לפריסה באמצעות Nomad ו- docker, בין היתר?

1. אנחנו בתנאי שווים לכל הסביבות. בפיתוח, סביבת QA, טרום-ייצור, ייצור, נעשה שימוש באותן תמונות מיכל, עם אותן תלות. בהתאם, אין לך כמעט סיכוי שמה שייגמר בייצור הוא לא מה שבדקת בעבר מקומית או בסביבת הבדיקה שלך.
2. מצאנו גם שזה מספיק קל להוסיף שירות חדש. מנקודת מבט של פריסה, כל מערכות חדשות מושקות בצורה פשוטה מאוד. פשוט עבור אל המאגר המאחסן הגדרות, הוסף שם תצורה נוספת עבור המערכת שלך, והכל מוכן. אתה יכול לפרוס את המערכת שלך לייצור ללא כל מאמץ נוסף מצד devops.
3. כל קבצי תצורה במאגר אחד משותף התברר שהוא בבדיקה. בתקופה שבה פרסנו את המערכות שלנו באמצעות שרתים וירטואליים, השתמשנו ב-Ansible, שבה התצורות היו באותו מאגר. עם זאת, עבור רוב המפתחים זה היה קצת יותר קשה לעבוד איתו. כאן נפח ההגדרות והקוד שאתה צריך להוסיף כדי לפרוס את השירות הפך קטן בהרבה. בנוסף, קל מאוד ל-devops לתקן או לשנות את זה. במקרה של מעברים, למשל, לגרסה חדשה של Nomad, הם יכולים לקחת ולעדכן בכמות גדולה את כל קבצי ההפעלה שנמצאים באותו מקום.

אבל נתקלנו גם בכמה חסרונות:

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

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

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

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

מעבר ל-Kubernetes

אני אספר לכם קצת על המושגים הבסיסיים של Kubernetes וכיצד הם שונים מ-Nomad.

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

נניח שיש לך אפליקציית PHP שמורכבת מ-nginx ו-php-fpm - הסכמה הקלאסית. סביר להניח שתרצה לשמור גם את מיכלי nginx וגם php-fpm ביחד בכל עת. Kubernetes מאפשר לך להשיג זאת על ידי תיאורם כתרמיל אחד נפוץ. זה בדיוק מה שלא יכולנו להשיג עם Nomad.

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

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

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

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

אם נשווה את כל המושגים הללו עם Nomad, נוכל לומר ששלושת המושגים הראשונים הם כולם ביחד שירות. והמושג האחרון נעדר בנומד עצמו. השתמשנו באיזון חיצוני כמו זה: זה יכול להיות haproxy, nginx, nginx+ וכן הלאה. במקרה של קובייה, אין צורך להציג את המושג הנוסף הזה בנפרד. עם זאת, אם אתה מסתכל על Ingress באופן פנימי, זה או nginx, haproxy או traefik, אבל מעין מובנה בתוך Kubernetes.

כל המושגים שתיארתי הם, למעשה, משאבים שקיימים בתוך אשכול Kubernetes. כדי לתאר אותם בקובייה, נעשה שימוש בפורמט yaml, שהוא קריא ומוכר יותר מקבצי HCL במקרה של Nomad. אבל מבחינה מבנית הם מתארים את אותו הדבר במקרה של, למשל, תרמיל. אומרים - אני רוצה לפרוס שם פודים כאלה ואחרים, עם תמונות כאלה ואחרות, בכמויות כאלה ואחרות.

בנוסף, הבנו שאנחנו לא רוצים ליצור כל משאב בודד ביד: פריסה, שירותים, Ingress וכו'. במקום זאת, רצינו לתאר כל אחת מהמערכות שלנו במונחים של Kubernetes במהלך הפריסה, כך שלא נצטרך ליצור מחדש באופן ידני את כל תלות המשאבים הדרושים בסדר הנכון. הלם נבחרה כמערכת שאפשרה לנו לעשות זאת.

מושגי יסוד בהלם

הגה הוא מנהל אריזה עבור Kubernetes. זה דומה מאוד לאופן שבו עובדים מנהלי חבילות בשפות תכנות. הם מאפשרים לך לאחסן שירות המורכב, למשל, פריסה nginx, פריסה php-fpm, config for Ingress, configmaps (זוהי ישות שמאפשרת לך להגדיר env ופרמטרים נוספים עבור המערכת שלך) בצורה של כך- שנקרא תרשימים. במקביל הלם פועל על גבי Kubernetes. כלומר, לא מדובר בסוג של מערכת שעומדת בצד, אלא סתם עוד שירות שהושק בתוך הקובייה. אתה מתקשר איתו דרך ה-API שלו באמצעות פקודת מסוף. הנוחות והיופי שלו היא שגם אם ההגה נשבר או שתסיר אותו מהאשכול, השירותים שלך לא ייעלמו, מכיוון שההגה בעצם משמשת רק להפעלת המערכת. Kubernetes עצמה אחראית לאחר מכן לביצועים ולמצב השירותים.

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

Helm מוסיף לנו עוד כמה מושגים.

תרשים - זהו תיאור של השירות שלך. במנהלי חבילות אחרים זה ייקרא חבילה, חבילה או משהו דומה. כאן זה נקרא תרשים.

ערכים הם המשתנים שבהם אתה רוצה להשתמש כדי לבנות את ההגדרות שלך מתבניות.

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

במקרה בו אנו משתמשים ב-helm, הגדרות רגילות עבור Kubernetes הופכות גם לתבניות בהן ניתן להשתמש במשתנים, פונקציות ולהחיל הצהרות מותנות. כך תוכל לאסוף את תצורת השירות שלך בהתאם לסביבה.

בפועל, החלטנו לעשות דברים קצת אחרת ממה שעשינו עם Nomad. אם ב-Nomad הן תצורות הפריסה והן משתני n שהיו נחוצים לפריסת השירות שלנו היו מאוחסנים במאגר אחד, כאן החלטנו לחלק אותם לשני מאגרים נפרדים. מאגר ה"פריסה" מאחסן רק n-משתנים הדרושים לפריסה, ומאגר ה"הגה" מאחסן הגדרות או תרשימים.

מה זה נתן לנו?

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

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

בתוך כל מאגר השארנו חלוקה לספריות נפרדות לכל שירות. כלומר, בתוך כל ספרייה יש תבניות הקשורות לתרשים המקביל ומתארות את המשאבים שצריך לפרוס כדי להפעיל את המערכת שלנו. השארנו רק envs במאגר "פריסה". במקרה זה, לא השתמשנו בתבנית באמצעות ג'ינג'ה, מכיוון שההגה עצמה מספקת תבנית מחוץ לקופסה - זו אחת הפונקציות העיקריות שלו.

השארנו סקריפט פריסה - deploy.sh, אשר מפשט ומתקן את ההשקה לפריסה באמצעות helm. לכן, לכל מי שרוצה לפרוס, ממשק הפריסה נראה בדיוק אותו הדבר כפי שנראה בעת הפריסה דרך Nomad. אותו deploy.sh, שם השירות שלך והיכן אתה רוצה לפרוס אותו. זה גורם להגה להתניע באופן פנימי. זה, בתורו, אוסף תצורות מתבניות, מכניס לתוכם את קבצי הערכים הדרושים, ואז פורס אותם, משיק אותם לתוך Kubernetes.

ממצאים

נראה ששירות Kubernetes מורכב יותר מאשר Nomad.

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

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

דוגמה לשימוש כזה היא Prometheus, הפועל בתוך אשכול Kubernetes שלנו. על מנת שהוא יתחיל לאסוף מדדים משירות מסוים, עלינו להוסיף סוג נוסף של משאב, מה שנקרא מוניטור שירות, לתיאור השירות. Prometheus, בשל העובדה שהוא יכול לקרוא סוג משאב מותאם אישית בעת ההשקה ב- Kubernetes, מתחיל אוטומטית באיסוף מדדים מהמערכת החדשה. זה די נוח.

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

מקור: www.habr.com