במאמר הקודם התחלנו את תהליך העבודה עם Docker, אך נשאר לנו לא מעט לעשות – קדימה!
ניסיון שני
הפעם נשתמש בפרמטר d- על מנת להריץ את הקונטיינר ברקע, כמו שמתאים לתהליך שהוא "שרת" (שזמן הריצה שלו - מתמשך). הנה אנחנו הולכים ומתמקצעים:
1. אני משתמש בפרמטר d- (קיצור של detached) על מנת להריץ את ה-container ברקע. הפעם השתמשתי ב-Image id ולא ב-name:tag - שתי הדרכים אפשריות.
2. כפלט לפעולה קיבלנו את ה-container id (זהו ה-hash הארוך). זה הנוהג ברוב הפקודות - וזו התנהגות שימושית למדי עבור כתיבת shell scripts.
3. איך אני יכול לראות מה-קורה עם ה-container? בעזרת פקודת ה-docker logs (ברבים)
4. אני מפעיל את הפקודה כמה שניות מאוחר יותר - ורואה שהלוג אכן מתקדם (חתכתי את הטקסט בתמונה, כי הוא כבר נעשה ארוך).
יופי! הדברים באמת הולכים נהדר... נראה לי...
התחברות לשרת:
נתחיל לעבוד עם השרת. מכיוון שמדובר ב-MySQL ואני על מק, רק טבעי שאשתמש בכלי בשם SequelPro [ג].
אני לוחץ על כפתור ה-connect.... ו:
זה לא בסדר. מה ACCESS DENIED?
אני בודק שהקונטיינר רץ - אכן רץ.
אני בודק הלוגים (פקודת docker logs) - ואין שום דבר. שום זכר לתקלה.
אני מנסה ללחוץ עוד כמה פעמים על כפתור ה-"Connect", אולי המחשב התבלבל - אבל לא. התקלה חוזרת על עצמה בעקביות.
למה זה קורה לי?
ספציפית יש פה מקרה קצת מבלבל: אני מריץ מקומית שרת MySQL 5.7, על הפורט ה-default ועם משתמש בשם root - אבל לא סיסמה מגוחכת כמו "123". בעצם ניסיתי להתחבר לשרת הזה - ונדחיתי כי הסיסמה לא נכונה.
אם לא היה לי את השרת MySQL המקומי מותקן, הייתי מקבל הודעה קצת יותר אינפורמטיבית בנוסח "Server not found".
אנחנו יודעים ש Docker לא מריץ באמת VM אלא תהליך מקומי עם מגבלות / אמצעי בידוד מוגברים.
מה באמת יקרה אם אני מריץ גם MySQL 5.7 וגם כ Container שרת MySQL 8 על אותה המכונה? לאיזה שרת אני באמת אתחבר?
מה אתם חושבים?
כשאנחנו מבולבלים, זה זמן טוב ללכת ולהבין טיפה תאוריה.
אתם בוודאי זוכרים ש Docker היא טכנולוגיה "לינוקסית" המתבססת על טכנולוגיות ליבה של לינוקס (LXC, namespaces, cgroups וכו' [ב]). Docker לא באמת יכולה לרוץ ישירות על המק שלי, כי MacOS הוא וריאציה של Unix, לא Linux ואין לו את יכולות הליבה הנדרשות.
בכדי לרוץ על המק שלי, חבילת ה-Docker Desktop for Mac כוללת VM המריץ לינוקס ועליו רץ Docker:
בעבר (כאשר היה צורך ב-Docker Machine) היה עלי לכוון ל-ip address של ה-VM על מנת להתחבר ל-Containers שאני מריץ.
היום ב-Docker Desktop for Mac יש מיפוי אוטומטי של ports של ה-containers ל-localhost של ה-host OS. הבעיה היחידה שיש לי היא ש port מספר 3306 כבר תפוס ע"י MySQL 5.7, ולכן המיפוי האוטומטי לא עובד.
האם עשינו תרגיל מוזר בכדי להריץ את Docker על המק? משהו חריג ששונה מאיך שנרוץ ב-production? - לא ממש.
מכיוון שמטרת הפוסט היא להכיר Docker, ולא רק להריץ MySQL 8 מקומית, שווה להתייחס שניה לארכיטקטורה של Docker:
צהוב = תהליך, לבן = נתונים
הארכיטקטורה של Docker מתבסס/ת על 3 hosts:
1. ה-Docker Client - ממנו שולטים על הנעשה.
2. ה-Docker Host - המאחסן מקומית את ה-Images (להלן "local repository" - לא שם רשמי), ומריץ את ה-containers. מכונת לינוקס.
3. ה-Docker Registry - המאחסן ומשתף docker Images בין docker hosts שונים.
במקרה שלנו:
• Docker Client - ה-host הוא המק שלי. משם אני מריץ את ה-Docker CLI שהוא משמש כ client.
• Docker Host - ה-host הוא ה-VM של לינוקס שרץ על המק. זה בעצם מיפוי די אמיתי לאיך שהדברים ירוצו גם בפרודקשן.
• ה-Docker Registry - הוא Docker Hub ה"ציבורי".
• כפי שניתן לראות בתרשים, הוא אינו חלק מתסריט של docker run - ולכן לא רלוונטי כרגע.
נסכם:
• כשנרוץ ב-production יהיה עלינו לעשות publish ל-ports של ה-container - על מנת לאפשר גישה מבחוץ. אין מיפוי פורטים אוטומטי.
• הזכרנו את זה בתיאור של פקודת ה-EXPOSE ב-Dockerfile. חזרו והיזכרו.
• מכיוון שה-port כבר תפוס ב-localhost - עלי לעשות מיפוי לפורט שונה ולחשוף אותו (גם נעשה בפקודת publish).
בקיצור: בכל מקרה נצטרך לעשות port publishing. הגיע הזמן.
בואו נעשה את זה!
1. אני מבצע publish, כאשר ה-port הראשון שמופיע הוא זה של ה-HostOS והשני הוא זה של ה-container.
2. שווה לשים לב שפקודת P- (אות גדולה) עושה publish לכל ה-exposed ports (ולאותו מספר port על ה-HostOS).
3. אני יכול לראות את המיפוי מכל כתובת IP (סימון: 0.0.0.0) בפורט 53306 לפורט 3306 של הקונטיינר.
i. MySQL 8 חושף (expose) גם את פורט 33060 עבור עבודה ב-X-Protocol המאפשר API דומה ל-MongoDB. אין לנו כוונה להשתמש בו, ולכן אנו לא מפרסמים (publish) אותו.
זהו. אחרי כ"כ הרבה עבודה - מגיע לנו להתחבר כבר לקונטיינר שלנו.
נשנה את הפורט ב-SequelPro ל-55306, ונלחץ שוב על Connect על מנת להתחבר:
אז זהו. אפשר להכריז שהחיים אינם הוגנים! עבדנו קשה - ועדין לא סיימנו.
יש לנו משוכה נוספת לעבור. לפחות הפעם השגיאה השתנתה - כלומר: התקדמנו.
אל ייאוש - עוד צעד אחד ומסיימים!
הבטחתי תסריט "עולם אמיתי" עם כמה תקלות - ואני מקווה שאני מקיים.
המטרה: ללמוד על הדרך עבודה עם Docker.
אני מקווה שלא איבדתי 94% מהקוראים עד הנקודה הזו 😄
אני מחפש את הודעת השגיאה האחרונה ומוצאה פוסט ב-Stackoverflow שמסביר את הבעיה וכמה דרכי פתרון. בגדול שיטת ה-Authentication ברירת-המחדל של MySQL השתנתה בגרסה 8 (מה שקובע בהתקנה חדשה), והקליינט שלי SequelPro - לא תומך בשיטה הזו.
הפתרון שאני בוחר בו, הוא להפעיל את ה-MySQL console ולשנות את שיטת ה-Authentication למשתמש שלי. פעולה די פשוטה - אם היה מדובר בתהליך מקומי.
כאשר אתם עובדים עם Docker, תגיעו במוקדם או במאוחר לרגע שבו אתם צריכים לעשות "SSH לקונטיינר" ולשנות משהו. זה בלתי נמנע.
בעבר זה היה די סיפור. היום זה כבר פשוט מאוד - אז בואו נהנה מההתקדמות שנעשתה ב-Docker:
1. אני מוצא את ה-container id של הקונטיינר שרץ.
2. הפקודה docker exec מריצה פקודה נתונה בתוך ה-container. במקרה הזה, אני רוצה להריץ bash ולעבוד כפי שאני רגיל - אבל ב-console של ה-container.
3. הפרמטר t- (קיצור של tty שהוא קיצור של יוניקס ל-Terminal; אל תלמדו מיוניקס איך לבחור קיצורים!!) אומר שאנו רוצים לעבוד עם פרוטוקול של טרמינל, שמבוסס input/output טקסטואלי, אבל מממש עוד כמה פקודות i/o נוספות (ioctls, למשל הסיגנלים).
a. למען הדיוק: ה-console הוא מימוש של פרוטוקול ה-terminal, ו-shell הוא המפרשן של ה-console לפקודות. פעמים רבות אנו משתמשים ב-terminal/shell/console כשמות נרדפים לאותו הדבר - אבל זה לא מדויק.
4. הפרמטר i- (בקיצור interactive) שומר את ה-STDIN שלנו פתוח לאורך כל זמן הריצה.
5. נקצר ונאמר שברגע שאנו רוצים לעבוד עם console (כמו bash), יש להשתמש בצמד הפרמטרים it- אחרת ייתכן וניתקל בהתנהגות בלתי צפויה.
6. הנה נכנסתי ל-console ואני יכול לעבוד. אני רוצה לקרוא לפקודה ll ולראות את רשימת הקבצים, אבל ברור לי שהיא לא תהיה זמינה בהפצה מינימלית של לינוקס - ולכן אני קורא ל-ls -lah הבסיסית יותר (והשקולה). עובד.
עכשיו שאני ב-console, אני יכול להחיל את הפתרון שמצאתי ב-Stackoverflow:
exit ראשון יוצא מה-MySQL console, ו-exit שני יוצא מה-bash - ומחזיר אותי ל-Host OS console.
אני מנסה, ומצליח הפעם להתחבר ל-MySQL 8 שרץ על הקונטיינר.
אני יכול להתחיל ולהתנסות בפיצ'רים של MySQL 8! איזה כיף!
הפעולה שביצעתי בכדי לאפשר את החיבור היא אמנם פשוטה, אבל עדין נדרשת.
כפי שדיברנו, ה-state של ה-container נשמר גם אחרי שהוא נסגר.
אני יכול לסגור את ה-MySQL8, ואז להתחיל אותו מחדש - כאשר ה"תיקון" כבר מיושם בקונטיינר: בעזרת docker ps -a אני אמצא containers שנסגרו, ובעזרת docker start - אני יכול להריץ container הספציפי מהנקודה שבה נעצר.
אחרית דבר
נניח שאני רוצה להריץ כמה containers של MySQL8, עם נתונים שונים וכו'. האם אצטרך כל פעם לבצע את "התיקון" בצורה ידנית?
לא כ"כ מתחשק לי. אני רוצה לשמור את השינוי שביצעתי.
זוכרים שהוספנו Layers ל-Image ב-Dockerfile בעזרת פקודות RUN/ADD/COPY?
אז יש עוד דרך לייצר Layer בצורה דינאמית יותר. אני יכול לקחת את ה-layer/mount העליון ביותר, זה של הקונטיינר - וליצור ממנו Layer חדש (ומכאן: Image חדש). לפקודה הזו קוראים docker commit - והנה אני משתמש בה על מנת לשמור את השינויים שעשיתי בהגדרות ה-authentication של משתמש ה-root ב-container שלי....
מלבד החיסרון הברור של פקודת docker commit שאין תיעוד (כמו ב-Dockerfile) של מה-באמת נעשה בה, ואין יכולת לחזור ולשנות נקודתית חלק ממה שהיא עושה - זה עדין כלי שימושי.
האמת שלמקרה שלנו, הדרך הנכונה ביותר היא לבנות dockerfile שמוסיף את השינוי הקטן. בסה"כ אנו מריצים (RUN) עוד פקודה - ואני משוכנע שאתם כבר יכולים לעשות זאת לבד.
בשל ההתמכרות הקטנה שלי בפוסט לרוח הטלנובלה הטורקית (ארוכה ומלאת אסונות) - אני דווקא רוצה להשתמש ב-docker commit על מנת לעשות את השינוי הנ"ל.
אני יכול לעשות commit, ליצור Image חדש, ובאמת לראות שיש layer חדש שמוסיף מעט גודל - ולהריץ אותו. אבל אבוי: כשאני מריץ את ה-Image החדש - יש לי עדין בעיית authentication בחיבור.
לא שגיתי בצעדים. הכל נכון, לכאורה.
הבעיה (והפתרון) טמונים בעצם בשורה הזו ב-Dockerfile שלנו:
למה?
מה השורה הזו בעצם עושה?
נראה... זה נושא לפוסט המשך (אם יהיו לי הכוחות. בלי נדר!)
שיהיה בהצלחה!
----
[ב] Docker עצמה היא טכנולוגיה שמשתנה תדיר - וזו אחת הביקורות נגדה. מי שעבר עם Docker ב-2015 ולמד את ה-Internals, בוודאי יופתע שהרבה מאוד השתנה בכמה השנים שחלפו.
פקודות השתנו ונוספו, אני זוכר שרק לפני שנתיים - שנתיים וחצי עבדתי עם Docker על מק והיה Docker Machine שמריץ boot2docker. זה כבר לא נכון, וזה משנה את אופן החיבור ל-container, וכמה פקודות שהכרתי - וכבר חסרות שימוש (לפחות בתצורה הזו).
מנגנונים וטכנולוגיות התחלפו: aufs הוחלפה ב-overlayFS, אפילו מנגנון הליבה LXC (להלן: Linux Containers שהחל את כל המהומה) הוחלף במימוש בשם libcontainer, כעת הוא ככל הנראה רצים בכלל על containerd ו- runc.
מצד אחד, די לא סטנדרטי להחליף את הבסיס שעליו אתה רץ פעמיים בכמה שנים - מצד שני אני יכול גם להבין את החברה מאחורי Docker שגילתה מה-לא עובד שוב, וביצעה את השינויים הקשים הנדרשים על מנת לפתור בעיות יסוד, ולהישאר רלוונטית.
אני רוצה להאמין שהבגרות של Docker אכן מתרחשת, וניתן לצפות לפחות שינויים ופחות דרמטיים בשנתיים שלפנינו - מאשר בשנתיים שעברו.
[ג] בעת כתיבת הפוסט, הגרסה האחרונה של SequelPro אינה תומכת ב-MySQL 8. כמה מביך!
אני משתמש ב-nightly build כבר כמה חודשים - והוא יציב למדי.
מאת: ליאור בר-און, ארכיטקט ומנהל הבלוג http://www.softwarearchiblog.com
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
במאמר הקודם התחלנו את תהליך העבודה עם Docker, אך נשאר לנו לא מעט לעשות – קדימה!
ניסיון שני
הפעם נשתמש בפרמטר d- על מנת להריץ את הקונטיינר ברקע, כמו שמתאים לתהליך שהוא "שרת" (שזמן הריצה שלו - מתמשך). הנה אנחנו הולכים ומתמקצעים:
1. אני משתמש בפרמטר d- (קיצור של detached) על מנת להריץ את ה-container ברקע. הפעם השתמשתי ב-Image id ולא ב-name:tag - שתי הדרכים אפשריות.
2. כפלט לפעולה קיבלנו את ה-container id (זהו ה-hash הארוך). זה הנוהג ברוב הפקודות - וזו התנהגות שימושית למדי עבור כתיבת shell scripts.
3. איך אני יכול לראות מה-קורה עם ה-container? בעזרת פקודת ה-docker logs (ברבים)
4. אני מפעיל את הפקודה כמה שניות מאוחר יותר - ורואה שהלוג אכן מתקדם (חתכתי את הטקסט בתמונה, כי הוא כבר נעשה ארוך).
יופי! הדברים באמת הולכים נהדר... נראה לי...
התחברות לשרת:
נתחיל לעבוד עם השרת. מכיוון שמדובר ב-MySQL ואני על מק, רק טבעי שאשתמש בכלי בשם SequelPro [ג].
אני לוחץ על כפתור ה-connect.... ו:
זה לא בסדר. מה ACCESS DENIED?
אני בודק שהקונטיינר רץ - אכן רץ.
אני בודק הלוגים (פקודת docker logs) - ואין שום דבר. שום זכר לתקלה.
אני מנסה ללחוץ עוד כמה פעמים על כפתור ה-"Connect", אולי המחשב התבלבל - אבל לא. התקלה חוזרת על עצמה בעקביות.
למה זה קורה לי?
ספציפית יש פה מקרה קצת מבלבל: אני מריץ מקומית שרת MySQL 5.7, על הפורט ה-default ועם משתמש בשם root - אבל לא סיסמה מגוחכת כמו "123". בעצם ניסיתי להתחבר לשרת הזה - ונדחיתי כי הסיסמה לא נכונה.
אם לא היה לי את השרת MySQL המקומי מותקן, הייתי מקבל הודעה קצת יותר אינפורמטיבית בנוסח "Server not found".
אנחנו יודעים ש Docker לא מריץ באמת VM אלא תהליך מקומי עם מגבלות / אמצעי בידוד מוגברים.
מה באמת יקרה אם אני מריץ גם MySQL 5.7 וגם כ Container שרת MySQL 8 על אותה המכונה? לאיזה שרת אני באמת אתחבר?
מה אתם חושבים?
כשאנחנו מבולבלים, זה זמן טוב ללכת ולהבין טיפה תאוריה.
אתם בוודאי זוכרים ש Docker היא טכנולוגיה "לינוקסית" המתבססת על טכנולוגיות ליבה של לינוקס (LXC, namespaces, cgroups וכו' [ב]). Docker לא באמת יכולה לרוץ ישירות על המק שלי, כי MacOS הוא וריאציה של Unix, לא Linux ואין לו את יכולות הליבה הנדרשות.
בכדי לרוץ על המק שלי, חבילת ה-Docker Desktop for Mac כוללת VM המריץ לינוקס ועליו רץ Docker:
בעבר (כאשר היה צורך ב-Docker Machine) היה עלי לכוון ל-ip address של ה-VM על מנת להתחבר ל-Containers שאני מריץ.
היום ב-Docker Desktop for Mac יש מיפוי אוטומטי של ports של ה-containers ל-localhost של ה-host OS. הבעיה היחידה שיש לי היא ש port מספר 3306 כבר תפוס ע"י MySQL 5.7, ולכן המיפוי האוטומטי לא עובד.
האם עשינו תרגיל מוזר בכדי להריץ את Docker על המק? משהו חריג ששונה מאיך שנרוץ ב-production? - לא ממש.
מכיוון שמטרת הפוסט היא להכיר Docker, ולא רק להריץ MySQL 8 מקומית, שווה להתייחס שניה לארכיטקטורה של Docker:
צהוב = תהליך, לבן = נתונים
הארכיטקטורה של Docker מתבסס/ת על 3 hosts:
1. ה-Docker Client - ממנו שולטים על הנעשה.
2. ה-Docker Host - המאחסן מקומית את ה-Images (להלן "local repository" - לא שם רשמי), ומריץ את ה-containers. מכונת לינוקס.
3. ה-Docker Registry - המאחסן ומשתף docker Images בין docker hosts שונים.
במקרה שלנו:
• Docker Client - ה-host הוא המק שלי. משם אני מריץ את ה-Docker CLI שהוא משמש כ client.
• Docker Host - ה-host הוא ה-VM של לינוקס שרץ על המק. זה בעצם מיפוי די אמיתי לאיך שהדברים ירוצו גם בפרודקשן.
• ה-Docker Registry - הוא Docker Hub ה"ציבורי".
• כפי שניתן לראות בתרשים, הוא אינו חלק מתסריט של docker run - ולכן לא רלוונטי כרגע.
נסכם:
• כשנרוץ ב-production יהיה עלינו לעשות publish ל-ports של ה-container - על מנת לאפשר גישה מבחוץ. אין מיפוי פורטים אוטומטי.
• הזכרנו את זה בתיאור של פקודת ה-EXPOSE ב-Dockerfile. חזרו והיזכרו.
• מכיוון שה-port כבר תפוס ב-localhost - עלי לעשות מיפוי לפורט שונה ולחשוף אותו (גם נעשה בפקודת publish).
בקיצור: בכל מקרה נצטרך לעשות port publishing. הגיע הזמן.
בואו נעשה את זה!
1. אני מבצע publish, כאשר ה-port הראשון שמופיע הוא זה של ה-HostOS והשני הוא זה של ה-container.
2. שווה לשים לב שפקודת P- (אות גדולה) עושה publish לכל ה-exposed ports (ולאותו מספר port על ה-HostOS).
3. אני יכול לראות את המיפוי מכל כתובת IP (סימון: 0.0.0.0) בפורט 53306 לפורט 3306 של הקונטיינר.
i. MySQL 8 חושף (expose) גם את פורט 33060 עבור עבודה ב-X-Protocol המאפשר API דומה ל-MongoDB. אין לנו כוונה להשתמש בו, ולכן אנו לא מפרסמים (publish) אותו.
זהו. אחרי כ"כ הרבה עבודה - מגיע לנו להתחבר כבר לקונטיינר שלנו.
נשנה את הפורט ב-SequelPro ל-55306, ונלחץ שוב על Connect על מנת להתחבר:
אז זהו. אפשר להכריז שהחיים אינם הוגנים! עבדנו קשה - ועדין לא סיימנו.
יש לנו משוכה נוספת לעבור. לפחות הפעם השגיאה השתנתה - כלומר: התקדמנו.
אל ייאוש - עוד צעד אחד ומסיימים!
הבטחתי תסריט "עולם אמיתי" עם כמה תקלות - ואני מקווה שאני מקיים.
המטרה: ללמוד על הדרך עבודה עם Docker.
אני מקווה שלא איבדתי 94% מהקוראים עד הנקודה הזו 😄
אני מחפש את הודעת השגיאה האחרונה ומוצאה פוסט ב-Stackoverflow שמסביר את הבעיה וכמה דרכי פתרון. בגדול שיטת ה-Authentication ברירת-המחדל של MySQL השתנתה בגרסה 8 (מה שקובע בהתקנה חדשה), והקליינט שלי SequelPro - לא תומך בשיטה הזו.
הפתרון שאני בוחר בו, הוא להפעיל את ה-MySQL console ולשנות את שיטת ה-Authentication למשתמש שלי. פעולה די פשוטה - אם היה מדובר בתהליך מקומי.
כאשר אתם עובדים עם Docker, תגיעו במוקדם או במאוחר לרגע שבו אתם צריכים לעשות "SSH לקונטיינר" ולשנות משהו. זה בלתי נמנע.
בעבר זה היה די סיפור. היום זה כבר פשוט מאוד - אז בואו נהנה מההתקדמות שנעשתה ב-Docker:
1. אני מוצא את ה-container id של הקונטיינר שרץ.
2. הפקודה docker exec מריצה פקודה נתונה בתוך ה-container. במקרה הזה, אני רוצה להריץ bash ולעבוד כפי שאני רגיל - אבל ב-console של ה-container.
3. הפרמטר t- (קיצור של tty שהוא קיצור של יוניקס ל-Terminal; אל תלמדו מיוניקס איך לבחור קיצורים!!) אומר שאנו רוצים לעבוד עם פרוטוקול של טרמינל, שמבוסס input/output טקסטואלי, אבל מממש עוד כמה פקודות i/o נוספות (ioctls, למשל הסיגנלים).
a. למען הדיוק: ה-console הוא מימוש של פרוטוקול ה-terminal, ו-shell הוא המפרשן של ה-console לפקודות. פעמים רבות אנו משתמשים ב-terminal/shell/console כשמות נרדפים לאותו הדבר - אבל זה לא מדויק.
4. הפרמטר i- (בקיצור interactive) שומר את ה-STDIN שלנו פתוח לאורך כל זמן הריצה.
5. נקצר ונאמר שברגע שאנו רוצים לעבוד עם console (כמו bash), יש להשתמש בצמד הפרמטרים it- אחרת ייתכן וניתקל בהתנהגות בלתי צפויה.
6. הנה נכנסתי ל-console ואני יכול לעבוד. אני רוצה לקרוא לפקודה ll ולראות את רשימת הקבצים, אבל ברור לי שהיא לא תהיה זמינה בהפצה מינימלית של לינוקס - ולכן אני קורא ל-ls -lah הבסיסית יותר (והשקולה). עובד.
עכשיו שאני ב-console, אני יכול להחיל את הפתרון שמצאתי ב-Stackoverflow:
exit ראשון יוצא מה-MySQL console, ו-exit שני יוצא מה-bash - ומחזיר אותי ל-Host OS console.
אני מנסה, ומצליח הפעם להתחבר ל-MySQL 8 שרץ על הקונטיינר.
אני יכול להתחיל ולהתנסות בפיצ'רים של MySQL 8! איזה כיף!
הפעולה שביצעתי בכדי לאפשר את החיבור היא אמנם פשוטה, אבל עדין נדרשת.
כפי שדיברנו, ה-state של ה-container נשמר גם אחרי שהוא נסגר.
אני יכול לסגור את ה-MySQL8, ואז להתחיל אותו מחדש - כאשר ה"תיקון" כבר מיושם בקונטיינר: בעזרת docker ps -a אני אמצא containers שנסגרו, ובעזרת docker start - אני יכול להריץ container הספציפי מהנקודה שבה נעצר.
אחרית דבר
נניח שאני רוצה להריץ כמה containers של MySQL8, עם נתונים שונים וכו'. האם אצטרך כל פעם לבצע את "התיקון" בצורה ידנית?
לא כ"כ מתחשק לי. אני רוצה לשמור את השינוי שביצעתי.
זוכרים שהוספנו Layers ל-Image ב-Dockerfile בעזרת פקודות RUN/ADD/COPY?
אז יש עוד דרך לייצר Layer בצורה דינאמית יותר. אני יכול לקחת את ה-layer/mount העליון ביותר, זה של הקונטיינר - וליצור ממנו Layer חדש (ומכאן: Image חדש). לפקודה הזו קוראים docker commit - והנה אני משתמש בה על מנת לשמור את השינויים שעשיתי בהגדרות ה-authentication של משתמש ה-root ב-container שלי....
מלבד החיסרון הברור של פקודת docker commit שאין תיעוד (כמו ב-Dockerfile) של מה-באמת נעשה בה, ואין יכולת לחזור ולשנות נקודתית חלק ממה שהיא עושה - זה עדין כלי שימושי.
האמת שלמקרה שלנו, הדרך הנכונה ביותר היא לבנות dockerfile שמוסיף את השינוי הקטן. בסה"כ אנו מריצים (RUN) עוד פקודה - ואני משוכנע שאתם כבר יכולים לעשות זאת לבד.
בשל ההתמכרות הקטנה שלי בפוסט לרוח הטלנובלה הטורקית (ארוכה ומלאת אסונות) - אני דווקא רוצה להשתמש ב-docker commit על מנת לעשות את השינוי הנ"ל.
אני יכול לעשות commit, ליצור Image חדש, ובאמת לראות שיש layer חדש שמוסיף מעט גודל - ולהריץ אותו. אבל אבוי: כשאני מריץ את ה-Image החדש - יש לי עדין בעיית authentication בחיבור.
לא שגיתי בצעדים. הכל נכון, לכאורה.
הבעיה (והפתרון) טמונים בעצם בשורה הזו ב-Dockerfile שלנו:
למה?
מה השורה הזו בעצם עושה?
נראה... זה נושא לפוסט המשך (אם יהיו לי הכוחות. בלי נדר!)
שיהיה בהצלחה!
----
[ב] Docker עצמה היא טכנולוגיה שמשתנה תדיר - וזו אחת הביקורות נגדה. מי שעבר עם Docker ב-2015 ולמד את ה-Internals, בוודאי יופתע שהרבה מאוד השתנה בכמה השנים שחלפו.
פקודות השתנו ונוספו, אני זוכר שרק לפני שנתיים - שנתיים וחצי עבדתי עם Docker על מק והיה Docker Machine שמריץ boot2docker. זה כבר לא נכון, וזה משנה את אופן החיבור ל-container, וכמה פקודות שהכרתי - וכבר חסרות שימוש (לפחות בתצורה הזו).
מנגנונים וטכנולוגיות התחלפו: aufs הוחלפה ב-overlayFS, אפילו מנגנון הליבה LXC (להלן: Linux Containers שהחל את כל המהומה) הוחלף במימוש בשם libcontainer, כעת הוא ככל הנראה רצים בכלל על containerd ו- runc.
מצד אחד, די לא סטנדרטי להחליף את הבסיס שעליו אתה רץ פעמיים בכמה שנים - מצד שני אני יכול גם להבין את החברה מאחורי Docker שגילתה מה-לא עובד שוב, וביצעה את השינויים הקשים הנדרשים על מנת לפתור בעיות יסוד, ולהישאר רלוונטית.
אני רוצה להאמין שהבגרות של Docker אכן מתרחשת, וניתן לצפות לפחות שינויים ופחות דרמטיים בשנתיים שלפנינו - מאשר בשנתיים שעברו.
[ג] בעת כתיבת הפוסט, הגרסה האחרונה של SequelPro אינה תומכת ב-MySQL 8. כמה מביך!
אני משתמש ב-nightly build כבר כמה חודשים - והוא יציב למדי.
מאת: ליאור בר-און, ארכיטקט ומנהל הבלוג http://www.softwarearchiblog.com
רוצים להתעדכן בתכנים נוספים בנושאי ענן וטכנולוגיות מתקדמות? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר