מדריך Dummies: בניית רשתות DevOps עם כלי קוד פתוח

בניית שרשרת DevOps הראשונה שלך בחמישה שלבים למתחילים.

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

ההיכרות שלי עם DevOps

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

הטבלה מאחור מראה באיזו תדירות חברות מוציאות גרסאות חדשות:

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

הדברים היו מאוד שונים עבורנו ב-Citi עד שעברנו ל-DevOps. אז לצוות שלי היו סביבות שונות, אבל עשינו את המסירה לשרת הפיתוח באופן ידני. לכל המפתחים הייתה גישה לשרת פיתוח אחד בלבד המבוסס על IBM WebSphere Application Server Community Edition. עם ניסיון בו זמנית לספק, השרת "נפל", ובכל פעם נאלצנו לנהל משא ומתן בינינו "בכאב". גם לא היה לנו כיסוי קוד מספיק עם בדיקות, תהליך מסירה ידני שלוקח זמן רב, ואין דרך לעקוב אחר מסירת הקוד בעזרת משימה כלשהי או דרישת לקוח.

היה ברור שצריך לעשות משהו דחוף, ומצאתי עמית בעל דעה דומה. החלטנו ליצור ביחד את שרשרת ה-DevOps הראשונה - הוא הקים מכונה וירטואלית ושרת יישומים של Tomcat, ואני טיפלתי בג'נקינס, אינטגרציה עם Atlassian Jira ו-BitBucket, כמו גם כיסוי קוד עם בדיקות. הפרויקט הצליח: ביצענו אוטומציה מלאה של שרשרת הפיתוח, השגנו כמעט 100% זמן פעולה בשרת הפיתוח, הצלחנו לנטר ולשפר את כיסוי הקוד באמצעות בדיקות, וניתן היה לקשור סניף של Git למשלוח והנפקה של Jira. וכמעט כל הכלים שבהם השתמשנו לבניית שרשרת DevOps היו קוד פתוח.

למעשה, השרשרת הייתה פשוטה, מכיוון שאפילו לא יישמנו תצורות מתקדמות באמצעות Jenkins או Ansible. אבל הצלחנו. אולי זו תוצאה של העיקרון פארטו (המכונה כלל 80/20).

תיאור קצר של שרשרת DevOps ו-CI/CD

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

אמנם כלים לבדם אינם מספיקים ליצירת סביבת DevOps, אך הם הכרחיים. החשוב שבהם הוא אינטגרציה מתמשכת ואספקה ​​מתמשכת (CI/CD). ישנם שלבים שונים בשרשרת עבור כל סביבה (למשל DEV (פיתוח), INT (אינטגרציה), TST (בדיקה), QA (הבטחת איכות), UAT (בדיקת קבלת משתמשים), STG (הכנה), PROD (שימוש)) , משימות ידניות הן אוטומטיות, מפתחים יכולים לייצר קוד איכותי, לספק אותו ויכולים לבנות מחדש בקלות.

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

בוא ניגש לעניין.

שלב 1: פלטפורמת CI/CD

קודם כל, אתה צריך כלי CI/CD. Jenkins הוא כלי CI/CD בעל רישיון MIT, שנכתב ב-Java, שהפך את תנועת DevOps לפופולריות והפך לתקן דה פקטו עבור CICD.

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

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

כך נראה תהליך DevOps עם כלי CI/CD

יש לך כלי CI/CD ב-localhost, אבל עדיין אין הרבה מה לעשות. בואו נעבור לשלב הבא.

שלב 2: בקרת גרסה

הדרך הטובה ביותר (וככל הנראה הקלה ביותר) לבדוק את הקסם של כלי CI/CD היא לשלב אותו עם כלי ניהול בקרת מקור (SCM). למה אתה צריך בקרת גרסאות? נניח שאתה מגיש בקשה. אתה כותב את זה ב-Java, Python, C++, Go, Ruby, JavaScript, או כל שפה אחרת שהיא עגלה ועגלה קטנה. מה שאתה כותב נקרא קוד מקור. בהתחלה, במיוחד אם אתה עובד לבד, אתה יכול לשמור הכל בספרייה מקומית. אבל ככל שהפרויקט גדל ויותר אנשים מצטרפים, אתה צריך דרך לשתף שינויי קוד אך למנוע התנגשויות בעת מיזוג שינויים. ואתה גם צריך איכשהו לשחזר גרסאות קודמות מבלי להשתמש בגיבויים ושימוש בשיטת העתק-הדבק עבור קובצי קוד.

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

ישנם כלים רבים של SCM, אבל Git הפך בצדק לסטנדרט דה פקטו. אני ממליץ לך להשתמש בו, אבל יש אפשרויות אחרות.

כך נראה צינור DevOps לאחר הוספת ה-SCM.

כלי ה-CI/CD יכול להפוך את ההעלאה וההורדה של קוד מקור אוטומטית ושיתוף פעולה בצוות. לא רע? אבל עכשיו איך לעשות מזה יישום עובד, אהוב על מיליארדי משתמשים?

שלב 3: בניית כלי אוטומציה

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

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

מושלם! כעת הבה נכניס את קבצי התצורה של כלי האוטומציה לבנות לתוך בקרת המקור כך שכלי ה-CI/CD יבנה אותם.

זה מרגיש טוב. אבל איפה כל זה צריך להתגלגל עכשיו?

שלב 4: שרת יישומי אינטרנט

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

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

ישנם מספר שרתי יישומי אינטרנט פתוחים.

כבר יש לנו שרשרת DevOps כמעט עובדת. עבודה טובה!

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

שלב 5: כיסוי מבחן

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

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

מסגרות בדיקה

כלים עם טיפים איכותיים

רוב הכלים והמסגרות הללו נכתבו עבור Java, Python ו-JavaScript מכיוון ש-C++ ו-C# הם קנייניים (אם כי GCC הוא קוד פתוח).

יישמנו את כלי כיסוי הבדיקה, ועכשיו צינור DevOps אמור להיראות כמו בתמונה בתחילת המדריך.

שלבים נוספים

מיכלים

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

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

עבור מכולות, בדרך כלל נלקחים Docker ו- Kubernetes, אם כי יש אפשרויות אחרות.

קרא מאמרים על Docker ו-Kubernetes בכתובת Openource.com:

• מה זה דוקר?
• היכרות עם Docker
• מה זה Kubernetes?
• Kubernetes מאפס

כלי אוטומציה של תוכנת אמצעית

שרשרת ה-DevOps שלנו מתמקדת בבנייה משותפת ואספקה ​​של אפליקציה, אבל יש דברים מעניינים נוספים שתוכלו לעשות עם כלי DevOps. לדוגמה, השתמשו בכלי Infrastructure as Code (IaC), הידועים גם בתור כלי אוטומציה של תוכנות ביניים. כלים אלה עוזרים להפוך התקנה, ניהול ומשימות אחרות לאוטומטיות עבור תוכנת ביניים. לדוגמה, כלי אוטומציה יכול לקחת יישומים (שרת יישומי אינטרנט, מסד נתונים, כלי ניטור) עם התצורות הנכונות ולדחוף אותם לשרת היישומים.

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

פרטים בכתבות Openource.com:

• מדריך תחילת העבודה של Ansible
• אסטרטגיות אוטומציה של פריסה עם Ansible
• 5 כלי ניהול התצורה המובילים

ועכשיו מה?

זה רק קצה הקרחון. רשת DevOps יכולה לעשות הרבה יותר. התחל עם כלי CI/CD וראה מה עוד אתה יכול להפוך לאוטומטי כדי להקל על העבודה שלך. אל תשכח כלי תקשורת פתוחים לשיתוף פעולה יעיל.

הנה עוד כמה מאמרי DevOps טובים למתחילים:

• מה זה DevOps
• 5 מיומנויות של מפתח DevOps
• DevOps לכולם
• מבוא לניתוח חזוי ב-DevOps

אתה יכול גם לשלב DevOps עם כלים זריזים פתוחים:

• מה זה זריז?
• 4 שלבים לשליטה בזריזות

מקור: www.habr.com