תהליך פיתוח ובדיקה עם Docker ו-Gitlab CI

אני מציע לקרוא את תמליל הדו"ח של אלכסנדר סיגאצ'ב מ-Inventos "תהליך פיתוח ובדיקה עם Docker + Gitlab CI"

מי שרק מתחיל ליישם את תהליך הפיתוח והבדיקה המבוסס על Docker + Gitlab CI שואל לעתים קרובות שאלות בסיסיות. איפה להתחיל? איך לארגן? איך לבדוק?

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

למי אכפת, בבקשה מתחת לחתול.

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

נושא המצגת: תהליך פיתוח באמצעות Docker ו-Gitlab CI.

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

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

המוטו שלנו הוא: עגן כל מה שאנחנו יכולים לשים עליו את היד.

אילו בעיות אנחנו פותרים?

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

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

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

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

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

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

בעיה נוספת היא גרסאות שונות של ספריות. לעתים קרובות קורה שמפתח עובד עם פרויקטים שונים. יש פרויקט Legacy שהחל לפני חמש שנים (משנת 2017 - הערה עורך). בזמן ההשקה, התחלנו עם MySQL 5.5. ישנם גם פרויקטים מודרניים שבהם אנו מנסים ליישם גרסאות מודרניות יותר של MySQL, למשל, 5.7 ומעלה (ב-2017 - הערה הערה)

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

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

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

למפתח פרונדנד, המפתח ב-JS, אין כמעט השפעה על Backend. מפתח הקצה האחורי, בתורו, מפתח, במקרה שלנו, Ruby on Rails ואינו מפריע לפרונדנד. האינטראקציה מתבצעת באמצעות ה-API.

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

כלים. במה אנחנו משתמשים?

• דוקר עצמו. ה-Dockerfile מתאר את התלות של יישום יחיד.
• Docker-compose הוא חבילה המאגדת כמה מיישומי Docker שלנו.
• אנו משתמשים ב-GitLab כדי לאחסן את קוד המקור.
• אנו משתמשים ב-GitLab-CI לשילוב מערכות.

הדו"ח מורכב משני חלקים.

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

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

Docker היא טכנולוגיה המאפשרת (באמצעות גישה הצהרתית) לתאר את הרכיבים הדרושים. זהו Dockerfile לדוגמה. כאן אנו מצהירים שאנו יורשים מהתמונה הרשמית של Ruby:2.3.0 Docker. הוא מכיל Ruby גרסה 2.3 מותקנת. אנו מתקינים את ספריות הבנייה הנדרשות ואת NodeJS. אנו מתארים שאנו יוצרים ספרייה /app. הגדר את ספריית האפליקציה כספריית העבודה. בספרייה זו אנו מניחים את Gemfile המינימלי הנדרש ואת Gemfile.lock. לאחר מכן אנו בונים את הפרויקטים המתקינים תמונת תלות זו. אנו מציינים שהמכולה תהיה מוכנה להאזנה ביציאה חיצונית 3000. הפקודה האחרונה היא הפקודה שמפעילה ישירות את האפליקציה שלנו. אם נבצע את פקודת התחל של הפרויקט, האפליקציה תנסה להפעיל ולהפעיל את הפקודה שצוינה.

זוהי דוגמה מינימלית לקובץ docker-compose. במקרה זה, אנו מראים שיש קשר בין שני מכולות. זה ישירות לתוך שירות מסד הנתונים ושירות האינטרנט. יישומי האינטרנט שלנו דורשים ברוב המקרים סוג של מסד נתונים בתור קצה עורפי לאחסון נתונים. מכיוון שאנו משתמשים ב-MySQL, הדוגמה היא עם MySQL - אבל שום דבר לא מונע מאיתנו להשתמש במסד נתונים אחר (PostgreSQL, Redis).

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

אנו מתארים גם שעלינו להעביר יציאה במחשב המארח המפתח שלנו מ-3000 ל-3000 ביציאת המכולה. זה נעשה באופן אוטומטי באמצעות iptables והמנגנון שלו, המוטמע ישירות ב-Docker.

המפתח יכול גם, כמו קודם, לגשת לכל כתובת IP זמינה, לדוגמה, 127.0.0.1 היא כתובת ה-IP המקומית או החיצונית של המחשב.

השורה האחרונה אומרת שמיכל האינטרנט תלוי במיכל db. כאשר אנו קוראים להתחלה של קונטיינר האינטרנט, docker-compose יתחיל תחילה את מסד הנתונים עבורנו. כבר בתחילת המאגר (למעשה, לאחר השקת הקונטיינר! זה לא מבטיח את מוכנות המאגר) תפעיל את האפליקציה, ה-backend שלנו.

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

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

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

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

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

ב-Frontend אנו משתמשים ב-JavaScipt וב-NodeJS.

עכשיו יש לנו את הפרויקט האחרון ב-ReacJS. היזם הריץ את הכל במיכל ופיתח באמצעות Hot-Reload.

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

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

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

מה עשינו בשביל זה?

חילקנו לאפליקציה רכיבים כמו: חלק הניהול ב-JS, ה-backend, שעובד דרך ממשק REST תחת Ruby on Rails. הקצה האחורי מקיים אינטראקציה עם מסד הנתונים. התוצאה שנוצרת ניתנת ללקוח. פאנל הניהול מקיים אינטראקציה עם הקצה האחורי ומסד הנתונים באמצעות ממשק REST.

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

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

הודעות דחיפה מקיימות אינטראקציה עם רכיב אחר שמיושם ב-NodeJS.

נבנים תורים ואז נשלחות הודעות בהתאם למנגנון שלהן.

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

אותו דבר אבל במספרים. זה המקום שבו שימוש חוזר בקוד חשוב.

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

באותו זמן, השתמשנו בגרסה 4 של NodeJS. כעת (בשנת 2017 - הערה הערה) בהתפתחויות האחרונות אנו משתמשים בגרסה 7 של NodeJS. אין בעיה ברכיבים חדשים לערב גרסאות חדשות של ספריות.

במידת הצורך, תוכל לשנות ולהעלות את גרסת ה-NodeJS משירות ההודעות Push.

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

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

בעת יצירת פרויקט חדש, אנו יוצרים Dockerfile, מתארים את המערכת האקולוגית הרצויה (Python, Ruby, NodeJS). ב-docker-compose, הוא מתאר את התלות הדרושה - מסד הנתונים. אנחנו מתארים שאנחנו צריכים מסד נתונים של גרסה כזו ואחרת, מאחסנים נתונים שם ושם.

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

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

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

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

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

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

אם יש צורך באינטגרציה עם הודעות דחיפה, מופעלות docker-compose.yaml ו-docker-compose-push.yaml.

מכיוון ש-docker-compose.yaml ו-docker-compose-push.yaml נמצאים בתיקייה, נוצרת אוטומטית רשת וירטואלית אחת.

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

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

עבור סביבת הפיתוח, אנו משתמשים בדומיין .dev - api.informer.dev. יישומים עם דומיין .dev זמינים במחשב המקומי של המפתח.

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

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

מאזן שמות הדומיין קובע לאיזה מיכל לפנות.

זה יכול להיות nginx, שנותן למנהל JS. זה יכול להיות nginx, שנותן את ה-API, או קבצים סטטיים, הניתנים ל-nginx בצורה של העלאות תמונות.

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

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

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

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

Hub.docer.com מכיל בדרך כלל קישורים ל-github.com, המכיל נתונים גולמיים ישירות שמהם תוכלו לבנות את התמונה בעצמכם.

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

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

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

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

זוהי דוגמה לאיך נראית גרסה ספציפית של MySQL ב-github.com. אתה יכול לפתוח את Dockerfile ולראות איך ההתקנה מתרחשת שם.

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

נעבור לחלק השני.

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

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

שיחת Gitlab CI 2 https://goo.gl/uohKjI - דיווח ממועדון רובי רוסיה - די מפורט ואולי זה יעניין אותך.

כעת נבחן מה נדרש על מנת להפעיל את Gitlab CI. כדי להפעיל את Gitlab CI, אנחנו רק צריכים לשים את הקובץ .gitlab-ci.yml בשורש הפרויקט.

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

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

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

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

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

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

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

יש הערה שזה חל רק על סניף המאסטר.

בעת שינוי סניפים אחרים אינו מבוצע.

אפשר לארגן השקות לפי סניפים.

כדי לארגן זאת עוד יותר, עלינו להתקין את Gitlab Runner.

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

בעת ההפעלה, אנו רושמים את Gitlab Runner.

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

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

הגדר את Gitlab Runner באופן אינטראקטיבי (Shell, Docker, VirtualBox, SSH)

הקוד ב- Gitlab Runner יבוצע בכל commit, בהתאם להגדרת .gitlab-ci.yml.

איך זה נראה ויזואלית ב-Gitlab בממשק האינטרנט. לאחר שחיברנו את GItlab CI, יש לנו דגל שמראה את מצב ה-build כרגע.

אנחנו רואים שנעשתה commit לפני 4 דקות שעבר את כל הבדיקות ולא גרם לבעיות.

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

אם נלחץ על build ספציפי, אז יהיה פלט מסוף של הפקודות שהופעלו בתהליך לפי .gitlab-ci.yml.

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

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

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

לאחר שעשינו זאת, הייתה לנו בעיה עם העובדה ש-Docker-compose יוצר שטח רשת משלו עבור כל אבא ואינו רואה את הרכיבים של השכן.

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

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

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

מכיוון שכדי שכל זה יראה יפה וכמה שיותר קרוב לייצור, כדאי להשתמש בפורט 80 או 443, המשמשים בכל מקום ב-WEB.

איך פתרנו את זה? הקצאנו את Gitlab Runner אחד לכל הפרויקטים הגדולים.

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

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

העברנו את nginx-proxy לסקריפט הפעלה נפרד והוספנו רשתות עבור כל הפרויקטים שבו.

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

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

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

עם זאת, אם תזין את הקונטיינר, זה יהיה root והקובץ שאנו יוצרים במיכל זה מקבל זכויות root.

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

איך אפשר לפתור את זה? אתה יכול להוסיף משתמשים שיהיו במיכל.

אילו בעיות התעוררו כאשר הוספנו את המשתמש?

בעת יצירת משתמש, לעתים קרובות אין לנו את אותו מזהה קבוצה (UID) ומזהה משתמש (GID).

כדי לפתור בעיה זו במיכל, אנו משתמשים במשתמשים עם מזהה 1000.

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

יש לנו תוכניות?

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

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

אז אני רוצה ללכת רחוק כבר כדי ללכת ישירות לתזמור.

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

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

מקור: www.habr.com