NET Core ב-Linux, DevOps על סוס

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

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

כיצד להעביר בקלות וללא מאמץ פרויקט ל-RPM באמצעות ליבת TFS, Puppet, Linux .NET? כיצד לתמוך בגירסאות של מסד נתונים של פרויקט אם צוות הפיתוח שומע את המילים Postgres ו-Flyway בפעם הראשונה, והדד-ליין הוא מחרתיים? כיצד להשתלב עם Docker? איך להניע מפתחי NET לנטוש את Windows והשייקים לטובת Puppet ולינוקס? איך לפתור קונפליקטים אידיאולוגיים אם אין לא הכוח, לא הרצון ולא המשאבים לתחזק את Windows בייצור? על זה, כמו גם על Web Deploy, בדיקות, CI, על שיטות השימוש ב-TFS בפרויקטים קיימים, וכמובן, על קביים שבורים ופתרונות עבודה, בתמליל הדו"ח של אלכסנדר.

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

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

למה ליבת .NET בשילוב עם לינוקס?

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

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

המערכת פשוט משולבת ב-CI קיים. אנו רואים בעצמנו DevOps מתקדמים, אנו משתמשים בבמבו, Jenkins ו-GitLab CI, כך שרוב העבודה שלנו פועלת על לינוקס.

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

דרישות

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

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

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

דדליין - אתמול.

Win Group Development

עם מה צוות Windows עבד אז?

עכשיו אני יכול להגיד את זה בביטחון IdentityServer4 הוא חלופה חינמית מגניבה ל-ADFS עם יכולות דומות, או מה ליבת מסגרת הישות - גן עדן למפתח, שבו אתה לא צריך לטרוח בכתיבת סקריפטים של SQL, אלא לתאר שאילתות במסד הנתונים במונחי OOP. אבל אז, במהלך הדיון בתוכנית הפעולה, הסתכלתי על הערימה הזו כאילו היא כתב יתדות שומרי, וזיהיתי רק את PostgreSQL ו-Git.

באותה תקופה השתמשנו באופן פעיל בּוּבָּה כמערכת לניהול תצורה. ברוב הפרויקטים שלנו השתמשנו GitLab CI, אלסטי, שירותי עומס גבוה מאוזנים באמצעות HAProxy פיקח על הכל עם זאביקס, רצועות גרפנה и פרומתאוס, יגר, וכל זה הסתובב על פיסות ברזל HP c ESXi על VMware. כולם מכירים את זה - קלאסיקה של הז'אנר.

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

מה קרה

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

בעבר, אלו היו חלונות מוצקים. TFS השתמש במספר סוכני Build, ששימשו להרכבת פרויקטים רבים. לכל סוכן יש 3-4 עובדים להקביל משימות ולייעל את התהליך. לאחר מכן, על פי תוכניות השחרור, TFS סיפקה את ה-Build הטרי שנאפה לשרת היישומים של Windows.

מה רצינו להשיג?

אנו משתמשים ב-TFS לצורך אספקה ​​ופיתוח, ומפעילים את האפליקציה על שרת Linux Application, ויש ביניהם סוג של קסם. זֶה קופסת קסם ויש מלח העבודה שלפניו. לפני שאפרק אותו, אקח צעד הצידה ואומר כמה מילים על האפליקציה.

פרויקט

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

לקוח

היו שני סוגי משתמשים. ראשון השיג גישה על ידי כניסה באמצעות אישור SSL SHA-2. U השני הייתה גישה באמצעות כניסה וסיסמה.

HAProxy

לאחר מכן בקשת הלקוח הועברה אל HAProxy, אשר פתרה את הבעיות הבאות:

• הרשאה ראשית;
• סיום SSL;
• כוונון בקשות HTTP;
• בקשות שידור.

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

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

קצה אחורי

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

חיסכון עם HAProxy

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

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

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

צעד שלישי - הלקוח הופנה בחזרה להקשר שממנו זה הגיע.

ל-IdentityServer4 יש תכונה: הוא מחזיר את התגובה לבקשת ההחזרה באמצעות HTTP. לא משנה כמה נאבקנו בהקמת השרת, לא משנה כמה הארנו את עצמנו עם התיעוד, בכל פעם קיבלנו בקשה ראשונית של לקוח עם כתובת URL שהגיעה דרך HTTPS, ו-IdentityServer החזיר את אותו הקשר, אבל עם HTTP. היינו בהלם! והעברנו את כל זה דרך הקשר הזהות ל-HAProxy, ובכותרות היינו צריכים לשנות את פרוטוקול ה-HTTP ל-HTTPS.

מה השיפור ואיפה חסכת?

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

איך זה אמור לעבוד

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

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

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

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

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

IdentityServer. ADFS היא לא הדרך שלנו, אנחנו הולכים על קוד פתוח.

בואו נעבור על המרכיבים.

קופסת קסם

מורכב מארבעה חלקים.

סוכן Linux Build. לינוקס, כי אנחנו בונים לזה - זה הגיוני. חלק זה נעשה בשלושה שלבים.

• הגדר עובדים ולא לבד, שכן הייתה צפויה עבודה מבוזרת על הפרויקט.
• התקן את .NET Core 1.x. למה 1.x כאשר 2.0 כבר זמין במאגר הסטנדרטי? כי כשהתחלנו בפיתוח, הגרסה היציבה הייתה 1.09, והוחלט לעשות את הפרויקט על בסיסה.
• Git 2.x.

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

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

בּוּבָּה - פותר את כל הבעיות השנויות במחלוקת ומספק בדיוק את התצורה שאנחנו רוצים מ-Gitlab.

אנחנו מתחילים לצלול. כיצד פועלת משלוח DLL ל-RPM?

משלוח DDL ל-RPM

נניח שיש לנו כוכב רוק לפיתוח NET. הוא משתמש ב-Visual Studio ויוצר ענף שחרור. לאחר מכן, הוא מעלה אותו ל-Git, ו-Git כאן הוא ישות TFS, כלומר, זה מאגר האפליקציות שאיתו עובד המפתח.

לאחר מכן TFS רואה שהגיע commit חדש. איזו אפליקציה? בהגדרות TFS יש תווית המציינת אילו משאבים יש לסוכן Build מסוים. במקרה זה, הוא רואה שאנחנו בונים פרויקט .NET Core ובוחר סוכן Linux Build מהמאגר.

סוכן ה-Build מקבל את המקורות ומוריד את הדרוש תלות ממאגר NET, npm וכו'. ולאחר בניית האפליקציה עצמה והאריזה שלאחר מכן, שולח את חבילת ה-RPM למאגר RPM.

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

הכל פשוט במילים, אבל מה קורה בתוך סוכן ה-Build עצמו?

אריזה DLL RPM

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

ארכיון ה-ZIP נזרק לפח לספריית בניית חבילת RPM. לאחר מכן, הסקריפט של Bash מאתחל את משתני הסביבה, מוצא את גרסת ה-Build, את גרסת הפרויקט, את הנתיב לספריית ה-build, ומריץ RPM-build. לאחר השלמת הבנייה, החבילה מתפרסמת ב- מאגר מקומי, שנמצא בסוכן Build.

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

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

ניהול גרסאות של מסד נתונים

בהתייעצות עם צוות הפיתוח התברר שהחבר'ה היו יותר קרובים ל-MS SQL, אבל ברוב הפרויקטים שאינם Windows כבר השתמשנו בכל הכוח ב-PostgreSQL. מכיוון שכבר החלטנו לנטוש את כל מה ששולם, התחלנו להשתמש ב-PostgreSQL גם כאן.

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

חסרונות

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

עבור Flyway us היה צורך בסוג של עטיפהכדי שהחבר'ה לא יכתבו שאילתות SQL. הם הרבה יותר קרובים לפעולה במונחי OOP. כתבנו הוראות לעבודה עם אובייקטי מסד נתונים, הפקנו שאילתת SQL והוצאנו אותה לפועל. הגרסה החדשה של מסד הנתונים מוכנה, בדוקה - הכל בסדר, הכל עובד.

ל-Entity Framework Core יש מינוס - בעומסים כבדים בונה שאילתות SQL לא אופטימליות, והירידה במסד הנתונים יכולה להיות משמעותית. אבל מכיוון שאין לנו שירות עומס גבוה, אנחנו לא מחשבים את העומס במאות RPS, קיבלנו את הסיכונים הללו והאצלנו את הבעיה לנו בעתיד.

Pros

ליבת מסגרת הישות עובד מחוץ לקופסה וקל לפתח, ו-Flyway משתלב בקלות ב-CI קיים. אבל אנחנו עושים את זה נוח למפתחים :)

הליך רול-אפ

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

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

בעיות TFS

אחרי שהחלטנו והבנו שהכל באמת עובד בשבילנו, החלטתי לבדוק מה קורה עם המכלולים ב-TFS בכללות למחלקת הפיתוח של Win בפרויקטים אחרים - האם אנחנו בונים/משחררים מהר או לא, וגם גילה בעיות משמעותיות במהירות.

אחד הפרויקטים העיקריים לוקח 12-15 דקות להרכיב - זה הרבה זמן, אתה לא יכול לחיות ככה. ניתוח מהיר הראה ירידה איומה ב-I/O, וזה היה על מערכים.

לאחר שניתח אותו מרכיב אחר רכיב, זיהיתי שלושה מוקדים. ראשון - "אנטי וירוס קספרסקי", אשר סורק מקורות בכל סוכני Windows Build. שנית - Windows מַפתְחָן. זה לא הושבת, והכל הוסף בזמן אמת על סוכני ה-Build במהלך תהליך הפריסה.

שלישית - התקנה Npm. התברר שברוב ה-Pipelines השתמשנו בתרחיש המדויק הזה. למה הוא רע? הליך ההתקנה של Npm מופעל כאשר עץ התלות נוצר ב package-lock.json, שבו נרשמות גרסאות החבילות שישמשו לבניית הפרויקט. החיסרון הוא שההתקנה של Npm מעלה את הגרסאות העדכניות ביותר של חבילות מהאינטרנט בכל פעם, וזה לוקח הרבה זמן במקרה של פרויקט גדול.

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

החלטה

• מקורות בחריגים AV.
• השבת אינדקס.
• מעבר ל npm ci.

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

תְצוּרָה

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

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

תוצאה

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

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

תוכניות

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

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

תקציר

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

פרופיל הדובר של אלכסנדר סינצ'ינוב ב-GitHub.

DevOps Conf הינו כנס לשילוב תהליכי פיתוח, בדיקה ותפעול לאנשי מקצוע על ידי אנשי מקצוע. בגלל זה הפרויקט שאלכסנדר דיבר עליו? מיושם ועובד, וביום ההופעה היו שני מהדורות מוצלחות. עַל DevOps Conf ב- RIT++ ב-27 וב-28 במאי יהיו עוד יותר מקרים דומים של מתרגלים. אתה עדיין יכול לקפוץ לכרכרה האחרונה ו הגש דו"ח או לקחת את הזמן להזמין כַּרְטִיס. פגוש אותנו בסקולקובו!

מקור: www.habr.com