שמירת מידע וניהול פיתוח מרובה קונטיינרים – דוקר

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

שמירת מידע בתוך קונטיינר

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

מידע משתמר – Volumes

באתר הרשמי של דוקר מוסבר כך:

ײ Volumes are the preferred mechanism for persisting data generated by and used by Docker containers.

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

אביא דוגמא מהאתר הרישמי כדי להבין יותר טוב את העניין, בדוגמה הבאה אני אריץ קונטיינר ואגדיר לו mount לvolume:

בעזרת הפרמטר -v אני מגדיר שהvolume בשם myvol2 יעשה mount לנתיב app בתוך הקונטיינר, מעכשיו כל דבר שיתווסף לתיקייה app יישמר בתוך הvolume.

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

יש דרך פשוטה להציג מידע לגבי הvolume,
מריצים את הפקודה docker inspect devtest על הקונטיינר ומקבלים את הפלט הבא, בתוכו מחפשים את החלק של Mounts:

אפשר לראות שדוקר יצר במחשב המארח תיקייה בשם /var/lib/docker/volumes/myvol2/_data ושם הוא שומר את המידע לקונטיינר בנתיב שנמצא במפתח source– תיקיית app.

אפליקציה מרובת קונטיינרים – Orchestration

בדוקר יש עיקרון נפוץ של “one process per container”,
הכוונה היא שלא רצוי לאכלס קונטיינר יחיד עם מספר אפליקציות וזאת ממספר סיבות:

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

שיתוף קונטיינרים תחת רשת אחת – Network

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

docker compose

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

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration. 

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

בהנחה שהקובץ נמצא בתיקיית myapp ונריץ את הפקודה docker-compose up יקרו הדברים הבאים:

  1. תיווצר רשת בשם myapp_default
  2. יווצר קונטיינר שישתמש בקונפיגורציה של web,
    הוא יצטרף לרשת myapp_default תחת השם web
  3. יווצר קונטיינר שישתמש בקונפיגורציה של db,
    הוא יצטרף לרשת myapp_default תחת השם db

כל קונטיינר יכול לחפש ע”פ השם web או db ויקבל חזרה את הכתובת IP של הקונטיינר.
למשל הקונטיינר web יוכל להתחבר עם הכתובת postgres://db:5432 ולהשתמש בבסיס נתונים.

חיבור פורטים – port binding

חשוב לשים לב להבדל בין הפורט של המחשב המארח לבין הפורט שבתוך הקונטיינר,
בדוגמה שלנו לקונטיינר של הdb יהיה אפשר לגשת מהמחשב המארח בפורט 8001 ובעצם הם יגיעו לפורט 5432 שבתוך הקונטיינר (הפורט ברירת מחדל של postgres).
אם קונטיינר אחר רוצה לגשת אל db הוא לא ייגש אליו בפורט 8001 אלא ב5432 כי כשקונטיינר יוצר בקשה ברשת הוא משתמש בפורט של הקונטיינר של של המחשב המארח.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *