תמלול הפרק (לחצו לפתיחה)
דוקר פרק 6 - Storage בדוקר
בהרצאות הקודמות למדנו שמעבר לשכבות הקיימות של ה-Image, יש שכבה שהיא Writable – שכבה שאפשר לכתוב עליה ולשם הקונטיינר יכול בזמן ריצה לכתוב כל מיני דברים לתוך הפייל סיסטם הזה שלו בקונטיינר. הרי הקונטיינר מקבל הרגשה, מקבל איזה אשליה כאילו שהוא מחשב בפני עצמו, אז הוא יכול לכתוב לפייל סיסטם במחשב הזה, במחשב המדומה הזה.
אז למה זה לא טוב? למה בעצם יש לנו עכשיו הרצאה פה על דוקר, על סטורג' בדוקר? למה זה לא מספיק לכתוב לשכבה הזאת? משתי סיבות.
הסיבה הראשונה שכדי לכתוב לשכבה הזאת אנחנו צריכים לעבור דרך הסטורג' דריבר של דוקר, שזה פעולה שיש לה Overhead מסוים והיא איטית יותר, אבל זאת לא הסיבה העיקרית.
הסיבה העיקרית היא שברגע שהקונטיינר ימות, המידע הזה שהוא כתב ימות יחד איתו. אם זה מידע שהוא חשוב לנו ואנחנו רוצים שהוא יישאר עבור הקונטיינר הבא שיגיע אחריו, אז הפתרון הזה של לכתוב לשכבה הזאת של הקונטיינר זה לא פתרון מספיק טוב.
אז זו המגבלה של השכבה הזאת שאנחנו מכירים. ועכשיו בהרצאה הזאת אנחנו נלמד איזה אפשרויות יש לנו כדי להתגבר על הבעיה הזאת ובכל זאת לאפשר שיהיה לנו סטורג' בדוקר. אז יש בעצם שלוש דרכים כדי לשמור על דאטה, לשמור על מידע בין קונטיינרים ואנחנו עכשיו נדבר על שלושת הדרכים, נכיר אותם.
1. ווליום (Volume):
נתחיל בדרך הראשונה שהיא נקראת ווליום. זאת הדרך המועדפת, המומלצת, הנוחה, הדרך שקודם כל אנחנו פונים לעבוד בצורה הזאת. ואחר כך, אם יש לנו צרכים אחרים, צרכים מיוחדים, אז אנחנו עוברים לדרכים האחרות. אז מה זה ווליום? ווליום זה אזור בזיכרון שמנהל דוקר. כלומר זה אזור בזיכרון שרק ישויות של דוקר יכולים לכתוב ולקרוא מהאזור הזה. כשאני אומר ישויות של דוקר אז כמובן שזה קונטיינרים. זה מאפשר לנו לחלוק מידע רק בין קונטיינרים. הדוקר אנג'ין יכול לאפשר את הכתיבה והקריאה הזאת וכל קונטיינר שרוצה להיות משויך לווליום יכול. או בזמן שאנחנו מריצים את הקונטיינר אנחנו יכולים להוסיף פלאגים מסוימים ב-Command Line ולשייך את הקונטיינר לווליום, או שאם אנחנו עובדים ב-Docker Compose אנחנו יכולים כבר בדוקר קומפוז להגדיר עם איזה ווליום יעבוד הקונטיינר הספציפי או הסרויס הספציפי. ואם הווליום הזה הוא לא קיים, אם אנחנו מריצים דוקר קומפוז עם שם של ווליום שלא קיים, אז הווליום הזה ייווצר. צריך להיזהר מהנושא של Typos כי אם אנחנו נכתוב בטעות שם טיפה שונה מהווליום הקיים, הווליום שאנחנו רוצים לכתוב אליו, אז לא נקבל איזה שגיאה שעשינו טייפו ואין כזה ווליום, הוא פשוט ייווצר ווליום אחר והמידע ייכתב לא למקום שבאמת התכוונו שהוא ייכתב אליו. אז חשוב לשים לב לזה.
אמרנו ווליום אפשר להריץ אותו על ידי פקודה ממש מפורשת docker volume create ואז אנחנו יוצרים את הווליום, או לכלול אותו ביצירה של Docker Compose או docker run והוא ייווצר בפני עצמו. ברגע שאנחנו מוחקים קונטיינר שמשתמש בווליום, הקונטיינר מת אבל הווליום עצמו נשאר עדיין חי. אין לו שום השפעה. ההפך הוא לא נכון. כלומר אם יש קונטיינר שמשתמש בווליום מסוים ואנחנו ננסה למחוק את הווליום בזמן ריצה, בזמן שהקונטיינר רץ ומשתמש בו, אנחנו נקבל שגיאה. לא נוכל לעשות את זה. גם אם יש כמה קונטיינרים שמשתמשים באותו ווליום, אנחנו לא נוכל למחוק את הווליום כל עוד אחד הקונטיינרים האלה עדיין למעלה ומשתמש בו.
ווליום זה הדרך הנוחה, הפשוטה, הקלה. חשוב לזכור שרק קונטיינרים יכולים לכתוב לתוך הווליום ולקרוא מהווליום, וזאת מגבלה שלפעמים גורמת לנו לעבור לדרכים אחרות. ווליום גם תומכים במה שנקרא Volume Driver. כלומר אם אנחנו עובדים בדוקר ב-Swarm mode, כלומר במוד שמאפשר לדוקר לעבוד עם כמה שרתים במקביל, אז אנחנו יכולים שקונטיינר שרץ על שרת א' יכתוב לווליום שנמצא על שרת ב'. כלומר, זה לא חייב להיות על המכונה הפיזית שהקונטיינר רץ עליה.
2. Bind mount:
הדרך הבאה שנלמד עליה שבעזרתה אפשר לממש סטורג' בדוקר נקראת Bind mount. זה למעשה מיפוי בין תיקייה בתוך הקונטיינר לתיקייה על ההוסט, על המחשב המארח, המחשב שעליו הקונטיינרים רצים. אנחנו מייצרים את המיפוי הזה ומאותו רגע כל קריאה וכתיבה לאחת התיקיות למעשה תבצע קריאה וכתיבה לתיקייה שממופה אליה. מה שזה מצריך מאיתנו זה ידע על המחשב שעליו אנחנו רצים. אנחנו צריכים לדעת שבאמת יש תיקייה כזאת או שבאמת אפשר ליצור אותה. אנחנו צריכים לדעת מה יהיה שם, אם יהיה שם איזה מידע שהוא רלוונטי לנו. בהמשך נלמד על יוז-קייסים לדבר כזה, זה יתבהר, אבל זה מצריך מאיתנו ידע על המחשב שמארח אותנו. המיפוי הזה הוא מיפוי Hard-coded, כלומר אנחנו ממפים Path ספציפי בתוך הקונטיינר ל-Path בתוך ההוסט. אם אנחנו ניתן Path מסוג תיקייה של לינוקס ואנחנו רצים על ווינדוס אז יש פה איזה בעיה. אנחנו ממפים לתיקייה שלא רק שהיא לא קיימת היא גם לא יכולה להיווצר. אם אנחנו נעשה Bind mount לתיקייה שהיא לא קיימת, התיקייה הזאת תיווצר בזמן ריצה, אבל אם אנחנו ניתן Path שהוא לא מתאים למערכת ההפעלה או שאולי אנחנו כתבנו אותו לתוך אזור שאין לנו הרשאות לייצר שם תיקיות, אז יש פה בעיה.
היתרון של Bind mount שבעצם בניגוד לווליום, זאת תיקייה שכל אפליקציה על המחשב יכולה לכתוב ולקרוא ממנה, לא רק קונטיינרים. אז אם אנחנו רוצים לשתף מידע, לחלוק מידע עם אפליקציה אחרת על ההוסט, אפליקציה שהיא לא קונטיינר, אז אנחנו צריכים ללכת על האופציה של Bind mount. ווליום לא יעזור לנו פה.
3. tmpfs mounts:
נעבור לנושא הבא שנקרא tmpfs mounts. מה שזה אומר, אפשר לשמוע כבר בשם. זה מכיל את המילה Temp וזה למעשה יחידת מידע שלא נכתבת לדיסק, היא נכתבת לזיכרון. למה הכוונה? ברגע שהקונטיינר ימות, המידע הזה ימות איתו ביחד. אין לנו, זה לא יישמר על הדיסק אם תהיה לנו הפסקת חשמל למשל, המידע הזה הולך לאיבוד. וזה שימושי מאוד כשאנחנו רוצים לשמור סיסמאות, Secrets או כל דבר שהוא לא רלוונטי מחוץ להקשר של קונטיינר.
יוז-קייסים (Use Cases):
נדבר על יוז-קייסים עבור כל אחת מהדרכים למימוש של סטורג' בדוקר.
ווליום (Volume): בואו נבין איזה קייסים יש לו.
קייס ראשון זה הקייס הברור: אם אנחנו רוצים שמידע מסוים יהיה משותף לכמה קונטיינרים, אנחנו ניצור ווליום והם כולם יכתבו ויקראו מהווליום הזה.
קייס נוסף זה אם אנחנו לא יודעים אם הקונטיינרים שלנו ירוצו על מחשבים שבהם תהיה להם גישה לאזורים מחוץ לדוקר. כלומר אם אנחנו לא בטוחים שנוכל לכתוב למקום כלשהו, אנחנו לא יודעים איזה הרשאות יהיו לנו, אנחנו נכתוב לווליום. זה המקום שבו אנחנו נבחר לממש את הסטורג' שלנו.
אם אנחנו רוצים לגבות את המידע שקיים בכל הקונטיינרים ואנחנו עובדים בסורם מוד, כלומר במוד שבו יש כמה הוסטים ואנחנו לא רוצים שהמידע הזה יישמר בכל הוסט והוסט. אם יש לנו 20 סרברים שדוקר עכשיו מנהל ואנחנו רוצים שהקונטיינרים שלנו יכתבו איזה מידע שהוא חשוב, למשל לוגים אולי אנחנו רוצים במקרה של בעיה לעשות איזה חקירה. אנחנו לא רוצים ללכת ל-20 סרברים ולאסוף את כל הלוגים האלה. אז ביוז-קייס כזה אנחנו ניצור ווליום בעזרת הווליום דריבר, ניצור ווליום אחד שכל ההוסטים יוכלו לכתוב אליו ואז במקרה של תקלה לא נצטרך ללכת ל-20 סרברים, נוכל לגשת לווליום הזה ולחקור את מה שמעניין אותנו.
קייס נוסף הוא קייס של ביצוע מיגרציה בין נניח דאטבייס אחד לדאטבייס אחר. אנחנו יכולים להרים קונטיינר אחד שיקרא מהסורס ויכתוב לווליום, ואחר כך להרים קונטיינר אחר שיקרא מהווליום ויכתוב לטרגט. כשהסורס והטרגט יכולים להיות מקומות שונים, דאטבייסים שונים, קבצים שונים, כל דבר אחר. אנחנו יכולים למעשה להשתמש בווליום כמעין תחנת ביניים כזאת כדי לעשות מיגרציה.
Bind mount: אמרנו שווליומים הם בעצם הדרך המומלצת, אבל יש מקרים מסוימים שבהם אנחנו נשתמש ב-Bind mount. המקרים האלה הם די מצומצמים ואני מהניסיון שלי תמיד נתקל בשני יוז-קייסים מאוד עיקריים.
היוז-קייס הראשון זה כשאנחנו רוצים להשתמש בקבצי קונפיגורציה. זה יכול להיות Certificate של AWS, זה יכול להיות קבצים שמאפשרים DNS resolve, זה יכול להיות כל קובץ שהוא חיצוני שנמצא על המערכת, נמצא על ההוסט, ואנחנו רוצים שהקונטיינרים שלנו ייחשפו למידע הזה וישתמשו בו. אנחנו לא יכולים להשתמש בווליום כי אמרנו שווליומים הם מיועדים להיות רק בשימוש של הדוקר אנג'ין. אם הקובץ נמצא על ההוסט, הקונטיינר יכול תמיד לגשת לתיקייה הזאת ולעשות את הפעולות שהוא רוצה. זה קייס מאוד נפוץ.
קייס נוסף הוא קייס של builds. כלומר אם יש לנו על ההוסט בילד שרץ פעם בכמה זמן ומייצר ארטיפקטים שונים ואנחנו רוצים שהקונטיינרים תמיד יקחו את הארטיפקטים הכי מעודכנים, אז אנחנו נוכל לייצר Bind mount אל התיקייה של הבילד. תיקייה שאליה הבילד שופך את הארטיפקטים ברגע שהוא מסיים לבנות אותם, ותמיד אנחנו נוכל לקחת משם את המידע הכי עדכני. זה יוז קייס מאוד נפוץ.
לגבי tmpfs שדיברנו עליו כבר, בעצם אמרנו את היוז קייס שלו. אנחנו משתמשים בו בגלל שהוא כותב לזיכרון ולא לדיסק. אנחנו נשתמש בו כשאנחנו רוצים לשמור על סיסמאות, על Secrets, על דברים שהם לא רלוונטיים מחוץ להקשר של קונטיינר. הקונטיינר משתמש בהם וברגע שהוא נופל, ברגע שהוא יורד, אין שום צורך במידע הזה.
זהו, בזה בעצם סיימנו גם את ההרצאה הזאת ולמעשה את כל הקורס על דוקר. מקווה שנהניתם, נתראה בהרצאה הבאה.