מה זה דוקר: טיול קצר להיסטוריה והפשטות בסיסיות

התחיל ב-10 באוגוסט ב-Slurm קורס וידאו של דוקר, שבו אנו מנתחים אותו לחלוטין - מהפשטות בסיסיות ועד פרמטרים של רשת.

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

מה זה דוקר

בואו נסתכל על ההגדרה של Docker מוויקיפדיה.

Docker היא תוכנה לאוטומציה של פריסה וניהול של יישומים בסביבות מכולות.

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

עידן מונוליטי

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

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

מערכות וירטואליזציה מבוססות Hypervisor

כולם בטח שמעו על מערכות וירטואליזציה: VMware, VirtualBox, Hyper-V, Qemu KVM וכו'. הן מספקות בידוד יישומים וניהול משאבים, אבל יש להן גם חסרונות. כדי לבצע וירטואליזציה, אתה צריך היפרוויזר. וה-Hypervisor הוא משאב תקורה. והמכונה הוירטואלית עצמה היא בדרך כלל קולוסוס שלם - תמונה כבדה המכילה מערכת הפעלה, Nginx, Apache, ואולי גם MySQL. התמונה גדולה והמכונה הוירטואלית לא נוחה לתפעול. כתוצאה מכך, העבודה עם מכונות וירטואליות יכולה להיות איטית. כדי לפתור בעיה זו, נוצרו מערכות וירטואליזציה ברמת הקרנל.

מערכות וירטואליזציה ברמת ליבה

וירטואליזציה ברמת ליבה נתמכת על ידי מערכות OpenVZ, Systemd-nspawn, LXC. דוגמה בולטת לווירטואליזציה כזו היא LXC (Linux Containers).

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

בעצם LXC יוצר קונטיינרים. מה ההבדל בין מכונות וירטואליות למכולות?

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

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

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

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

מה משמש לקונטיינריזציה ברמת הקרנל

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

מרחבי שמות: PID, Networking, Mount ומשתמש. יש עוד, אבל כדי להקל על ההבנה נתמקד באלה.

מרחב שמות PID מגביל תהליכים. כאשר, למשל, אנו יוצרים PID Namespace וממקמים שם תהליך, הוא הופך ל-PID 1. בדרך כלל במערכות PID 1 הוא systemd או init. בהתאם לכך, כאשר אנו ממקמים תהליך במרחב שמות חדש, הוא מקבל גם PID 1.

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

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

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

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

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

מערכת Copy-on-write מאפשרת לנו לעבוד עם תמונות Docker ולהשתמש בהן בצורה יעילה יותר.

ל-Docker יש כרגע בעיות תאימות עם Cgroups v2, כך שמאמר זה מתמקד במיוחד ב-Cgroups v1.

אבל בואו נחזור להיסטוריה.

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

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

כדי לפתור את כל הבעיות הללו, הגיע העידן הבא.

עידן המכולות

כשהגיע עידן המכולות, הפילוסופיה של העבודה איתם השתנתה:

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

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

בשנים 2014-2015, דוקר פרחה - הטכנולוגיה עליה נדבר כעת.

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

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

סטייה לגבי תקורה

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

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

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

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

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

על הרעיון של דוקר

Docker מורכב ממספר מרכיבים:

1. Docker Daemon הוא אותו מנוע מיכל; משגר מכולות.
2. Docker CII הוא כלי עזר לניהול Docker.
3. Dockerfile - הוראות כיצד לבנות תמונה.
4. תמונה - התמונה שממנה מתגלגל המיכל.
5. מְכוֹלָה.
6. Docker registry הוא מאגר תמונות.

סכמטית זה נראה בערך כך:

Docker daemon פועל על Docker_host ומשגר קונטיינרים. יש לקוח ששולח פקודות: לבנות את התמונה, להוריד את התמונה, להפעיל את הקונטיינר. Docker daemon הולך לרישום ומבצע אותם. לקוח Docker יכול לגשת הן באופן מקומי (לשקע Unix) והן באמצעות TCP ממארח ​​מרוחק.

בואו נעבור על כל רכיב.

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

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

פקודות בסיסיות:

docker ps - הצג קונטיינרים הפועלים כעת על המארח של Docker.
תמונות docker - הצג תמונות שהורדו באופן מקומי.
docker search <> - חפש תמונה ברישום.
docker pull <> - הורד תמונה מהרישום למכונה.
docker build < > - אסוף את התמונה.
docker run <> - הפעל את המכולה.
docker rm <> - הסר את המיכל.
docker logs <> - יומני מיכל
docker start/stop/restart <> - עבודה עם המיכל

אם אתה שולט בפקודות אלה ובטוח בשימוש בהן, ראה את עצמך בקי ב-70% ב-Docker ברמת המשתמש.

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

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

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

תמונה - זוהי אריזת מיכל; מיכלים מופעלים מהתמונה. אם נסתכל על Docker מנקודת המבט של מנהל חבילות (כאילו אנחנו עובדים עם חבילות deb או rpm), אז תמונה היא בעצם חבילת rpm. באמצעות yum install נוכל להתקין את האפליקציה, למחוק אותה, למצוא אותה במאגר ולהוריד אותה. זה בערך אותו דבר כאן: קונטיינרים מופעלים מהתמונה, הם מאוחסנים ברישום של Docker (בדומה ל-yum, במאגר), ולכל תמונה יש Hash SHA-256, שם ותג.

התמונה בנויה לפי ההוראות מה- Dockerfile. כל הוראה מה- Dockerfile יוצרת שכבה חדשה. ניתן לעשות שימוש חוזר בשכבות.

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

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

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

כדי ללמוד את התכונות והתוכנית המלאה של הקורס ביתר פירוט, אנא היכנסו לקישור: "קורס וידאו של דוקר".

מחבר: מרסל איברייב, מנהל מוסמך של Kubernetes, מהנדס בפועל בסאות'ברידג', דובר ומפתח קורסי Slurm.

מקור: www.habr.com