חשוב היטב לפני השימוש ב-Docker-in-Docker עבור CI או סביבת בדיקה

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

Docker-in-Docker: "טוב"

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

• פריצת פריצות;
• לִבנוֹת;
• עצירת דמון דוקר פועל;
• השקת דמון דוקר חדש;
• בדיקה;
• לחזור על המחזור.

אם רצית ליצור מכלול יפה וניתן לשחזור (כלומר, במיכל), אז זה נהיה יותר מורכב:

• פריצת פריצות;
• ודא שגרסת Docker פועלת;
• לבנות Docker חדש עם Docker הישן;
• עצור את דמון הדוקר;
• התחל דמון דוקר חדש;
• מִבְחָן;
• עצור דמון דוקר חדש;
• חזור.

עם כניסתו של Docker-in-Docker, התהליך הפך לפשוט יותר:

• פריצת פריצות;
• הרכבה + השקה בשלב אחד;
• לחזור על המחזור.

זה לא הרבה יותר טוב ככה?

Docker-in-Docker: "רע"

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

אחד מהם נוגע ל-LSMs (מודולי אבטחה של לינוקס) כגון AppArmor ו-SELinux: בעת הפעלת קונטיינר, ה-"Docker הפנימי" עשוי לנסות להחיל פרופילי אבטחה שיסתכסכו או יבלבלו את ה"Docker החיצוני". זוהי הבעיה הקשה ביותר לפתרון כאשר מנסים למזג את היישום המקורי של הדגל -פריבילגי. השינויים שלי עבדו וכל הבדיקות עברו על מכונת הדביאן שלי ו-VMs המבחן של אובונטו, אבל הם היו קורסים ונצרבים במחשב של מייקל קרוסבי (היה לו פדורה כזכור). אני לא זוכר את הסיבה המדויקת לבעיה, אבל יכול להיות שזה בגלל שמייק הוא בחור חכם שעובד עם SELINUX=enforce (השתמשתי ב-AppArmor) והשינויים שלי לא לקחו בחשבון פרופילי SELinux.

Docker-in-Docker: "רוע"

הבעיה השנייה היא עם מנהלי האחסון של Docker. כאשר אתה מפעיל Docker-in-Docker, Docker חיצוני פועל על גבי מערכת קבצים רגילה (EXT4, BTRFS, או כל מה שיש לך) ו-Docker פנימי פועל על גבי מערכת העתקה על כתיבה (AUFS, BTRFS, Device Mapper , וכו'). , בהתאם למה שמוגדר לשימוש ב-Docker חיצוני). זה יוצר שילובים רבים שלא יעבדו. לדוגמה, לא תוכל להריץ AUFS על גבי AUFS.

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

ישנן דרכים לעקיפת הבעיה כדי לפתור רבות מהבעיות הללו. לדוגמה, אם אתה רוצה להשתמש ב-AUFS ב-Docker הפנימי, פשוט הפוך את התיקיה /var/lib/docer לנפח ותהיה בסדר. Docker הוסיפה כמה מרחבי שמות בסיסיים לשמות יעד של Device Mapper כך שאם שיחות Docker מרובות פועלות על אותו מחשב, הן לא ידרכו אחת על השנייה.

עם זאת, הגדרה כזו אינה פשוטה כלל, כפי שניתן לראות מאלה מאמרים במאגר dind ב- GitHub.

Docker-in-Docker: זה מחמיר

מה לגבי ה-build cache? זה גם יכול להיות די קשה. אנשים שואלים אותי לעתים קרובות "אם אני מריץ את Docker-in-Docker, איך אוכל להשתמש בתמונות שמתארחות במארח שלי במקום למשוך הכל בחזרה ל-Docker הפנימי שלי"?

כמה אנשים יוזמים ניסו לאגד את /var/lib/docker מהמארח למיכל Docker-in-Docker. לפעמים הם חולקים /var/lib/docer עם מספר קונטיינרים.

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

הדמון Docker תוכנן בבירור כדי לקבל גישה בלעדית ל-/var/lib/docer. שום דבר אחר לא צריך "לגעת, לתקוע או לדרבן" בקבצי Docker שנמצאים בתיקייה זו.

למה זה כל כך? מכיוון שזו תוצאה של אחד השיעורים הקשים ביותר שנלמדו בזמן פיתוח dotCloud. מנוע הקונטיינר של dotCloud פעל על ידי גישה למספר תהליכים /var/lib/dotcloud בו זמנית. טריקים ערמומיים כמו החלפת קבצים אטומיים (במקום עריכה במקום), פלפל קוד עם מנעולים מייעצים וחובה, וניסויים אחרים עם מערכות מאובטחות כמו SQLite ו-BDB לא תמיד עבדו. כשעיצבנו מחדש את מנוע הקונטיינר שלנו, שהפך בסופו של דבר ל-Docker, אחת מהחלטות התכנון הגדולות הייתה לאחד את כל פעולות הקונטיינר תחת דמון אחד כדי לבטל את כל השטויות המקבילות.

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

המשמעות היא שאם תשתפו את ספריית /var/lib/docer בין מספר מופעי Docker, יהיו לכם בעיות. כמובן שזה יכול לעבוד, במיוחד בשלבים הראשונים של הבדיקה. "תקשיבי, אמא, אני יכול להריץ את אובונטו בתור דוקר!" אבל נסה משהו מורכב יותר, כמו למשוך את אותה תמונה משני מקרים שונים, ותראה את העולם נשרף.

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

הפתרון

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

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

במילים פשוטות, כשאתה מפעיל את מיכל ה-CI שלך (ג'נקינס או אחר), במקום לפרוץ משהו יחד עם Docker-in-Docker, התחל אותו בשורה:

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

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

נסה זאת באמצעות תמונת הדוקר הרשמית (המכילה את הקובץ הבינארי של Docker):

docker run -v /var/run/docker.sock:/var/run/docker.sock 
           -ti docker

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

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

אז אם אתה רוצה להשתמש ב-Docker מ-Jenkins CI, יש לך 2 אפשרויות:
התקנת Docker CLI באמצעות מערכת אריזת התמונות הבסיסית (כלומר אם התמונה שלך מבוססת על Debian, השתמש בחבילות .deb), באמצעות Docker API.

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com