מדריך למתחילים: יצירת צינור DevOps

אם אתה חדש ב-DevOps, עיין במדריך בן חמשת השלבים ליצירת הצינור הראשון שלך.

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

מסע ה-DevOps שלי

עבדתי בעבר בצוות הענן של קבוצת Citi בפיתוח אפליקציית אינטרנט ב-Infrastructure-as-a-Service (IaaS) לניהול תשתית הענן של Citi, אך תמיד התעניינתי כיצד להפוך את תהליך הפיתוח ליעיל יותר ולהביא לשינוי תרבותי חיובי. צוות פיתוח. מצאתי את התשובה בספר שהומלץ על ידי גרג לבנדר, CTO של Cloud Architecture and Infrastructure ב-Citi. הספר נקרא פרויקט עוף החול (פרויקט הפניקס), והוא מסביר את העקרונות של DevOps, אבל הוא קורא כמו רומן.

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

אמזון: 23 ליום
גוגל: 5 ליום
נטפליקס: 500 ליום
פייסבוק: פעם ביום
טוויטר: 3 פעמים בשבוע
חברה טיפוסית: אחת ל-9 חודשים

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

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

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

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

מבוא קצר ל-DevOps ול-CI/CD Pipeline

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

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

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

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

שלב 1: שיטות CI/CD

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

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

Jenkins הוא רק אחד מכלי קוד פתוח רבים של CI/CD שבהם אתה יכול להשתמש כדי לבנות צינור DevOps שלך.

ג'נקינס: Creative Commons ו-MIT
Travis CI: MIT
בקרת שיוט: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
קאבי: גנו

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

יש לך כלי CI/CD פועל על המארח המקומי שלך, אבל אין הרבה שאתה יכול לעשות כרגע. בואו נעבור לשלב הבא של מסע ה-DevOps.

שלב 2: ניהול מערכות בקרת מקור

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

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

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

Git: GPLv2 ו-LGPL v2.1
חתרנות: Apache 2.0
מערכת גרסאות במקביל (CVS): GNU
וסטה: LGPL
Mercurial: GNU GPL v2+

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

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

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

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

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

שם
רישיון
שפת תכנות

Maven
Apache 2.0
Java

נמלה
Apache 2.0
Java

סלע
Apache 2.0
Java

זל
Apache 2.0
Java

לעשות
גנה
N / A

לִנְחוֹר
MIT
JavaScript

גאלפ
MIT
JavaScript

בּוֹנֶה
אַפָּשׁ
אוֹדֶם

לִגרוֹף
MIT
אוֹדֶם

AAP
גנה
פיתון

SCons
MIT
פיתון

BitBake
GPLv2
פיתון

עוּגָה
MIT
C#

ASDF
Expat (MIT)
ליספ

קְנוּנִיָה
BSD
האסל

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

הכל בסדר, לא? אבל היכן לפרוס את האפליקציה שלך?

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

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

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

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

שם
רישיון
שפת תכנות

חתול בר
Apache 2.0
Java

מזח
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

דג זכוכית
CDDL & GNU פחות ציבורי
Java

ג'נגו
3-סעיף BSD
פיתון

טורנדו
Apache 2.0
פיתון

גוניקהורן
MIT
פיתון

פיתון
MIT
פיתון

ריילס
MIT
אוֹדֶם

Node.js
MIT
Javascript

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

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

שלב 5: כיסוי בדיקת קוד

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

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

מערכות בדיקת קוד

שם
רישיון
שפת תכנות

JUnit
רישיון
Java

EasyMock
אַפָּשׁ
Java

מוקיטו
MIT
Java

PowerMock
Apache 2.0
Java

פיטסט
MIT
פיתון

השערה
מוזילה
פיתון

טוקס
MIT
פיתון

מערכות המלצות לשיפור קוד

שם
רישיון
שפת תכנות

סיקור
גנה
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
פיתון

אמה
רישיון ציבורי משותף
Java

ג'קוקו
רישיון
Java

השערה
מוזילה
פיתון

טוקס
MIT
פיתון

יַסמִין
MIT
JavaScript

קארמה
MIT
JavaScript

מוקה
MIT
JavaScript

יש
MIT
JavaScript

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

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

שלבים נוספים

מיכלים

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

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

אמנם יש אפשרויות מכולה אחרות, אבל הפופולריות ביותר הן Docker ו-Kubernetes.

דוקר: Apache 2.0
Kubernetes: Apache 2.0

כלי אוטומציה בינוניים

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

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

Ansible: GNU Public
SaltStack: Apache 2.0
שף: Apache 2.0
בובה: אפאצ'י או GPL

גלה פרטים על איך להשיג מקצוע מבוקש מאפס או Level Up מבחינת מיומנויות ושכר על ידי לקיחת קורסים מקוונים בתשלום מ-SkillFactory:

• קורס DevOps (12 חודשים)

קורסים נוספים

• קורס למידת מכונה (12 שבועות)
• מלמדת את מקצוע הנתונים מאפס (12 חודשים)
• מקצוע אנליסט בכל רמה מתחילה (9 חודשים)
• קורס פייתון לפיתוח אתרים (9 חודשים)

שימושי

• 450 קורסי ליגת הקיסוס בחינם
• מגמות במדעי הנתונים 2020
• Data Science מת. יחי מדעי העסקים
• מדע נתונים על סטרואידים: מבוא לאינטליגנציה של החלטות
• פרויקט Data Science המצליח והשערורייתי ביותר: Cambridge Analytica

מקור: www.habr.com