ההיסטוריה של יצירת שירות ענן, בטעם סייברפאנק

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

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

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

ברוכים הבאים לחתול.

תחילתו של מסע

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

היו גם מספר דרישות:

• השירות צריך חשבון אישי נוח;
• יש לשלב את הפלטפורמה במערכת החיוב הקיימת;
• תוכנה וחומרה: OpenStack + Tungsten Fabric (Open Contrail), שהמהנדסים שלנו למדו "לבשל" היטב.

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

• Python + Flask + Swagger + SQLAlchemy - ערכת Python סטנדרטית לחלוטין;
• Vue.js עבור frontend;
• החלטנו לעשות את האינטראקציה בין רכיבים ושירותים באמצעות סלרי על פני AMQP.

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

אז בואו נתחיל את ההיכרות שלנו.

חשבון שקט - חיוב

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

חיוב היא המערכת הראשונה שניסינו להתיידד איתה. והקושי הראשון שנתקלנו בו היה בעת עיבוד שירותים.

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

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

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

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

בעיה נוספת היא השתיקה.

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

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

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

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

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

למרבה המזל, למוצר יש API נרחב למדי ושילבנו את תת המערכות הבאות בחשבון האישי שלנו:

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

הליכה בשדות טונגסטן - בד טונגסטן

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

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

המערכת משולבת עם OpenStack (נדון בהמשך) באמצעות תוסף Neutron.

אינטראקציה של שירותי OpenStack.

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

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

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

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

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

Silicon Lifeforms - OpenStack

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

OpenStack הוא הליבה של הפלטפורמה שלנו.

ל-OpenStack יש מספר תת-מערכות, מהן אנו משתמשים כיום ב- Nova, Glance ו-Cinder באופן הפעיל ביותר. לכל אחד מהם יש API משלו. נובה אחראית על משאבי המחשוב ויצירת מופעים, סינדר אחראית על ניהול נפחים ותצלומי המצב שלהם, Glance הוא שירות תמונה שמנהל תבניות מערכת הפעלה ומטא-אינפורמציה עליהם.

כל שירות פועל במיכל, ומתווך ההודעות הוא "הארנב הלבן" - RabbitMQ.

מערכת זו נתנה לנו את הצרות הכי לא צפויות.

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

החלטנו לעשות מעקף וביקשנו את אותה פעולה מ-Nova API. התוצאה היא שהמכשיר מתחבר בצורה נכונה ונגיש בתוך השרת. נראה שהבעיה מתרחשת כאשר אחסון בלוק אינו מגיב לסינדר.

קושי נוסף חיכה לנו בעבודה עם דיסקים. לא ניתן היה לנתק את אמצעי האחסון של המערכת מהשרת.

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

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

OpenStack היא מערכת מורכבת למדי של מערכות עם הגיון אינטראקציה משלה ו-API מעוטר. אנו נעזרים בתיעוד מפורט למדי וכמובן בניסוי וטעייה (איפה היינו בלעדיו).

מבחן ריצה

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

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

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

קוריוז נוסף קשור לפונקציונליות של כפתור "שנה סיסמה" בחשבון האישי שלך.

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

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

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

המשך יבוא

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

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

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

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

צוות פיתוח CLO

קישורים שימושיים

לפתוח ערימה

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

בד טונגסטן

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

מקור: www.habr.com