תזמורת הופעה

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

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

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

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

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

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

הגישה להשגת ולתפעול שרתים אלו מגוונת. כמה דוגמאות:

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

הצוות שלנו משתמש בשרתים שצריך לתמוך בהם - עדכון מערכת ההפעלה, התקנת חבילות חדשות וכו'.

עבור עצמנו, חילקנו אותם לשני סוגים עיקריים:

• קבוצת טנקים,
• קבוצת שירות.

קבוצת הטנקים מורכבת ממארחים עם Yandex.Tank.

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

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

למה צריך מנצח, גם אם התזמורת עצמה יכולה לנגן?

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

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

נכון לעכשיו, מאגר המארח מורכב משלושה תפקידים של Ansible:

• התפקיד הראשון מתקין את מערכת ההפעלה,
• השני מפעיל הגדרות בסיסיות עבור המארח, הרשאת LDAP, למשל,
• והשלישי מתקין את Yandex.Tank ותלויות קשורות במיכל docker.

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

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

הערה קטנה לגבי ipv6 ב-Docker

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

על פי תיעוד ipv6 באתר הרשמי של Docker, ipv6 מופעל על ידי הוספת פרמטרים ל-daemon.json:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

במקרה זה, על הספק להנפיק תת-רשת ipv6, בה תירשם fixed-cidr-v6.
עם זאת, בחרנו באפשרות אחרת - ipv6 NAT, והנה הסיבה:

• עכשיו דוקר לא יכול להשתמש רק עם ipv6.
• כתובת הניתנת לניתוב גלובלית בכל קונטיינר פירושה שכל היציאות (אפילו אלה שלא פורסמו) חשופות לכולם אלא אם כן בוצע סינון נוסף.
• userland proxy עבור יציאות פרסום, iptables רק עבור ipv4.

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

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

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)

הבעיה נפתרה לאחר הוספת אתחול לתפקיד Ansible באמצעות מודול modprobe וטעינתו באתחול מערכת ההפעלה באמצעות lineinfile:

- name: Add ip6table_nat module
 modprobe:
   name: ip6table_nat
   state: present
- name: Add ip6table_nat to boot
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

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

אבל בואו נחזור לשאלתנו שנשאלה בהתחלה:
למה צריך מנצח, גם אם התזמורת עצמה יכולה לנגן?

עכשיו כולם מדמיינים איך לשחק בקבוצה שלנו:

• נוצר תהליך "מזיגה" של שרתים,
• פיתוח ופריסה של שירותים מאוחדים.

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

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

איך להשיג מנצח טוב במינימום השקעה?

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

קוֹנסוּל - מערכת המספקת שתי פונקציות עיקריות:

• גילוי שירות,
• אחסון מבוזר של ערך מפתח.

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

• פעיל הוא כאשר השירות רושם את עצמו באמצעות ה-API של HTTP;
• פסיבי - יש לרשום את השירות באופן ידני.

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

• מרכז יחיד ליצירה ואחסון של סודות וניהול מחזור החיים שלהם באמצעות ה-API של HTTP.
• Transit Secrets Engine - הצפנה ופענוח של נתונים מבלי לשמור אותם. היכולת להעביר נתונים בצורה מוצפנת על פני ערוצי תקשורת לא מאובטחים.
• גישה למדיניות שקל להגדיר.
• ביקורת גישה לסודות.
• היכולת ליצור CA משלך (רשות אישורים) לניהול אישורים בחתימה עצמית בתוך התשתית שלך.

בהתחשב בכל הדרישות שלנו, שתי אפשרויות התאימו לתפקיד המנצח - Kubernetes ו-Nomad.

קוברנט

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

נוד

כלי מחברת HashiCorp הידועה בקונסול ובכספת שהוזכרו לעיל.

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

מה כרגע בתהליך:

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

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

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

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

מקור: www.habr.com