🥇 פרקטיקות של משלוח רציף עם Docker (סקירה ווידאו)

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

31 במאי בכנס RootConf 2016, שנערך במסגרת הפסטיבל "טכנולוגיות אינטרנט רוסיות" (RIT++ 2016), נפתח המדור "פריסה ופריסה מתמשכת" בדו"ח "שיטות עבודה מומלצות של משלוח מתמשך עם Docker". הוא סיכם וסידר את השיטות המומלצות לבניית תהליך משלוח מתמשך (CD) באמצעות Docker ומוצרי קוד פתוח אחרים. אנו עובדים עם הפתרונות הללו בייצור, מה שמאפשר לנו להסתמך על ניסיון מעשי.

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

משלוח רציף עם Docker

תחת משלוח רציף אנו מבינים את שרשרת האירועים שכתוצאה ממנה קוד האפליקציה ממאגר Git מגיע לראשונה לייצור, ולאחר מכן מגיע לארכיון. היא נראית כך: Git → Build → Test → Release → Operate.

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

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

דפוס פריסה ראשי

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

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

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

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

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

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

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

יכולת שחזור

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

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

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

תשתית היא קוד

אם דרישות התשתית (זמינות תוכנת השרת, גרסתה וכו') אינן פורמליות ו"מתוכנתות", אזי השקת כל עדכון אפליקציה עלולה לגרום לתוצאות הרות אסון. לדוגמא, בסטייג'ינג כבר עברתם ל-PHP 7.0 ושכתבתם את הקוד בהתאם - אז הופעתו בהפקה עם איזה PHP ישן (5.5) בהחלט תפתיע מישהו. אולי לא תשכחו משינוי גדול בגרסת המתורגמן, אבל "השטן נמצא בפרטים הקטנים": ההפתעה עשויה להיות בעדכון מינורי של כל תלות.

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

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

תמונות דוקר, תקשורת עם Git

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

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

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

דפ

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

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

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

קוברנט

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

לצורך השקה, Kubernetes מציע:

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

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

המלצות סופיות

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

סרטונים ושקופיות

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

הצגת הדו"ח:

נ.ב.

דיווחים נוספים בנושא בבלוג שלנו:

«werf - הכלי שלנו עבור CI / CD ב-Kubernetes (סקירה כללית ודוח וידאו)» (Dmitry Stolyarov; 27 במאי 2019 ב-DevOpsConf);
«מסדי נתונים ו-Kubernetes» (דמיטרי סטוליארוב; 8 בנובמבר 2018 ב-HighLoad++);
«שיטות עבודה מומלצות ל-CI/CD עם Kubernetes ו-GitLab» (דמיטרי סטוליארוב; 7 בנובמבר 2017 ב-HighLoad++);
«הניסיון שלנו עם Kubernetes בפרויקטים קטנים» (דמיטרי סטוליארוב; 6 ביוני 2017 ב-RootConf).

מקור: www.habr.com

שיטות משלוח רציפות עם Docker (סקירה ווידאו)