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

1. כי אתה לא יודע מספיק יוניקס

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

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

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

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

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

2. כי אתה לא יודע מספיק על רשתות

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

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

3. כי docker compose הוא באמת מבלבל

מכשול שלישי נוגע לכמות החומר ולשכבות השונות של חומר על Docker Compose (ועוד יותר גרוע על קוברנטיס). דוקר קומפוז הוא כלי עבודה שכמעט כל מי שעובד בדוקר משתמש בו, הוא וותיק וה API שלו עבר שינויים לאורך השנים. לכן נוצר מצב שבכל חברה יש Best Practices שונים לגבי העבודה עם docker compose, וגם אם למדתם אותו לעומק בעבר הרבה דברים אולי כבר לא רלוונטים. לדוגמה מאפיין restart ב docker-compose.yml מגדיר איך להפעיל מחדש קונטיינרים, וגם מאפיין deploy.restart_policy עושה בדיוק את אותו דבר (אבל לכל אחד מהם תחביר קצת שונה והשפעה קצת שונה).

אפילו אם החלטנו להשתמש בפורמט העדכני ביותר, עדיין יש אינסוף החלטות שצריך לקבל כמו האם להשתמש ב build או ב image, האם לקחת image מוכן ולהשתמש ב command או לבנות Dockerfile בעצמנו, האם לכתוב קובץ docker-compose.yml יחיד או קובץ נפרד לכל סרביס או קבוצה של סרביסים ועוד ועוד.

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

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