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

אנחנו מחברת הפינטק Exness, המפתחת שירותים למסחר מקוון ומוצרי פינטק ל-B2B ו-B2C. למו"פ שלנו יש צוותים רבים ושונים, במחלקת הפיתוח יש 100+ עובדים.

אנו מייצגים את הצוות שאחראי על הפלטפורמה עבור המפתחים שלנו לאיסוף ולהריץ קוד. בפרט, אנו אחראים לאיסוף, אחסון ודיווח של מדדים, יומנים ואירועים מיישומים. אנו מפעילים כיום כשלושת אלפים מכולות Docker בסביבת ייצור, שומרים על אחסון הנתונים הגדולים שלנו בנפח 50 TB ומספקים פתרונות ארכיטקטוניים שנבנו סביב התשתית שלנו: Kubernetes, Rancher וספקי ענן ציבוריים שונים. 

המוטיבציה שלנו

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

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

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

סוכנים

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

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

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

סוכנים מתכוונים גם לכלי שירות לתפעול ותחזוקה שיכולים לעבוד במערכות תזמור שונות התומכות בתמונות שונות (Debian, Alpine, Centos וכו').

לבסוף, סוכנים חייבים לתמוך ב-CI/CD פשוטים הכוללים קבצי Docker. אחרת, הספינה תתפרק, כי מכולות יתחילו להימסר לאורך מסילות "עקומות".

בניית תהליך ותמונה יעד

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

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

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

מה טוב בגישה הזו? 

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

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

איך עובד הליך הבנייה שלנו

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

Header מוסיף הפצות מהתמונות המתאימות. וכותרת תחתונה מתקינה את השירותים שלנו בפנים, מגדירה את ההשקה של עומס העבודה, רישום וסוכנים אחרים, מחליפה נקודת כניסה וכו'. 

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

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

 

עבור אותו מיכל אנו מקבלים עצי תהליך שונים ב-Docker וב-Kubernetes:

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

אם נסתכל על המפרט של ה"פוד" (להלן – Kubernetes pod), נראה שמיכל האירועים מבוצע בפוד, שיש לו מיכל אספן נפרד המבצע את תפקיד איסוף המדדים והלוגים. אנחנו יכולים להשתמש ביכולות של Kubernetes: הפעלת קונטיינרים בפוד אחד, בתהליך אחד ו/או בחלל רשת. למעשה הצג את הסוכנים שלך ובצע כמה פונקציות. ואם אותו קונטיינר יושק ב-Docker, הוא יקבל את כל אותן היכולות כמו פלט, כלומר, הוא יוכל לספק לוגים ומדדים, מאחר והסוכנים יושקו באופן פנימי. 

מדדים ויומנים

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

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

ההיבט השלישי הוא שיש צורך לתמוך בכמה שיותר שיטות איסוף מדדים מחוץ לקופסה. מקריאת קבצים וסקר נקודת הקצה של Prometheus ועד לשימוש בפרוטוקולים ספציפיים ליישום.

וההיבט האחרון הוא למזער את צריכת המשאבים.

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

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

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

אנו אוספים יומנים דרך ה-API של Docker: מפתחים רק צריכים לשים אותם ב-stdout או stderr, ו-Collector יסדר את זה. יומנים נאספים בחתיכות עם עיכוב מסוים כדי למנוע עומס יתר אפשרי של המארח. 

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

• יומנים זמינים ב-Graylog (לניתוח חזותי);
• יומנים, מדדים, אירועים נשלחים ל- Clickhouse לאחסון לטווח ארוך.

הכל עובד בדיוק אותו הדבר ב-AWS, רק שאנחנו מחליפים את Graylog בקפקא ב-Cloudwatch. אנחנו שולחים לשם את היומנים, והכל מתברר מאוד נוח: מיד ברור לאיזה אשכול ומיכל הם שייכים. הדבר נכון גם לגבי Google Stackdriver. כלומר, התוכנית שלנו פועלת גם ב-Premise עם קפקא וגם בענן. 

אם אין לנו Kubernetes עם תרמילים, התוכנית קצת יותר מסובכת, אבל היא עובדת על אותם עקרונות.

אותם תהליכים מבוצעים בתוך המיכל, הם מתוזמרים באמצעות S6. כל אותם תהליכים פועלים בתוך אותו מיכל.

כתוצאה מכך,

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

• פיתחנו גישה סטנדרטית להרכבת תמונות, ועל בסיסה פיתחנו תבניות CI;
• סוכני איסוף נתונים הם הרחבות של Telegraf שלנו. בדקנו אותם היטב בייצור;
• אנו משתמשים ב-mutation webhook כדי ליישם מיכלים עם סוכנים בתרמילים; 
• משולב במערכת האקולוגית של Kubernetes/Rancher;
• אנחנו יכולים לבצע את אותם קונטיינרים במערכות תזמור שונות ולקבל את התוצאה לה אנחנו מצפים;
• יצר תצורת ניהול קונטיינר דינמית לחלוטין. 

מחבר שותף: איליה פרודניקוב

מקור: www.habr.com