הרצת קונטיינרים וניהול בסיסי

מה זה?#

יצרתם והרצתם קונטיינר — אבל מה קורה כשמשהו לא עובד? אי אפשר “לפתוח אותו” כמו IDE. צריך כלים ייעודיים לניהול קונטיינר רץ: לראות מה הוא מדפיס (לוגים), “להיכנס” אליו לבדיקה ידנית, ולנקות קונטיינרים/Images ישנים שנשארו מאחור. אלה בדיוק הכלים היומיומיים שיהיו הכרחיים ביחידות הבאות, כשעובדים עם כמה קונטיינרים (DB + API + עוד) בו-זמנית.

מילות מפתח שחשוב לזכור#

• docker logs — מציג את כל הפלט (Console) שהאפליקציה בתוך הקונטיינר הדפיסה, גם אם זה קרה בעבר

• docker exec — מריץ פקודה בתוך קונטיינר רץ, בלי לעצור אותו — בדרך כלל לפתיחת shell לבדיקה ידנית

• docker stop / docker rm — עצירת קונטיינר רץ, ומחיקתו לצמיתות (אחרי עצירה)

• Container Lifecycle — קונטיינר עובר בין מצבים: נוצר → רץ → נעצר → (אופציונלי) נמחק

docker logs <container-id>          # show all output so far
docker logs -f <container-id>       # "follow" in real time (like tail -f)

docker exec -it <container-id> bash # open an interactive shell inside the running container
# inside the shell: you can check files, run diagnostic commands, see that everything is really there

docker stop <container-id>          # stop a running container (sends SIGTERM)
docker rm <container-id>            # permanently delete a stopped container
docker rm -f <container-id>         # stop and delete in one action

docker images                       # list Images stored locally
docker rmi <image-id>               # delete an unused Image
docker system prune                 # general cleanup — unused Containers/Images/Networks

הסבר עיקרי#

docker logs הוא כלי הדיבוג הראשון תמיד — קונטיינר “רץ” (docker ps מראה אותו) לא אומר שהאפליקציה בפנים עובדת נכון. docker logs מראה בדיוק מה קרה — שגיאות קומפילציה, חריגות בזמן ריצה, או הודעות הצלחה — בדיוק כמו לצפות ב-Console המקומי, רק שהתוכנית רצה מבודדת בתוך הקונטיינר.

docker exec -it נותן גישה “בפנים” בלי לעצור כלום — -it (Interactive + TTY) פותח shell אינטראקטיבי אמיתי בתוך הקונטיינר הרץ, בלי להפריע לו. שימושי לבדיקות אבחון: “האם הקובץ שציפיתי שיועתק באמת שם?”, “מה ערך משתנה סביבה מסוים בפועל?” — בלי לעצור את השירות שרץ.

Container Lifecycle וניקוי — קונטיינרים שנעצרו (stop) עדיין “קיימים” (docker ps -a מראה אותם) עד שנמחקים במפורש (rm). עם הזמן, קונטיינרים ו-Images ישנים מצטברים ותופסים שטח דיסק — docker system prune הוא כלי ניקוי כללי שימושי, אך מוחק הכל שלא בשימוש נוכחי — יש להשתמש בזהירות.

יתרונות#

docker logs/exec נותנים כלי דיבוג מלאים לקונטיינר רץ, בלי לעצור אותו; ניהול Lifecycle מפורש (stop/rm) נותן שליטה מדויקת על מתי קונטיינר נעלם; ניקוי תקופתי (prune) מונע הצטברות שטח דיסק מיותר.

חסרונות#

docker system prune בלי זהירות עלול למחוק Images/Containers שעדיין נחוצים; ניהול ידני של קונטיינרים רבים (עצירה, מחיקה, לוגים) לכל אחד בנפרד הופך מסורבל ככל שהמערכת גדלה — בעיה ש-Docker Compose (ביחידת NoSQL) יפתור.

נקודות חשובות#

• docker logs מציג פלט Console; -f עוקב בזמן אמת

• docker exec -it <id> bash פותח shell בתוך קונטיינר רץ, בלי לעצור אותו

• docker stop עוצר; docker rm מוחק לצמיתות; rm -f עושה שניהם יחד

• docker system prune מנקה משאבים לא-בשימוש — משפיע רחב, להשתמש בזהירות

טעויות נפוצות#

• לנסות למחוק (rm) קונטיינר רץ בלי -f או בלי stop קודם — נכשל

• לשכוח -it ב-docker exec ולקבל שגיאה/התנהגות לא-אינטראקטיבית

• להריץ docker system prune בלי לבדוק מה יימחק, ולאבד Images שהיו עדיין נחוצים

סיכום#

docker logs מציג את פלט האפליקציה מתוך הקונטיינר — כלי הדיבוג הראשון תמיד. docker exec -it פותח גישת shell לקונטיינר רץ לבדיקה ידנית, בלי לעצור אותו. docker stop/rm מנהלים את מחזור החיים של הקונטיינר במפורש, ו-docker system prune מנקה משאבים ישנים לא-בשימוש. אלה הכלים היומיומיים שיהיו הכרחיים ביחידות הבאות, כשעובדים עם כמה קונטיינרים (DB, API, ועוד) בו-זמנית.

דוקומנטציה רשמית#

Docker — Container lifecycle

תרגילים#

תרגיל 1 — לוגים ו-exec#

המשימה: הריצו קונטיינר של ה-API שבניתם בשיעור הקודם, צפו בלוגים שלו עם docker logs -f, ואז פתחו shell עם docker exec -it ובדקו שקבצי האפליקציה אכן קיימים בתוכו.

בדיקה: הלוגים מציגים את הודעת ההפעלה של השרת; ה-shell מציג את קבצי ה-.dll שהועתקו ב-Dockerfile.

תרגיל 2 — ניהול Lifecycle#

המשימה: הריצו 3 קונטיינרים, עצרו אחד, מחקו אותו, והציגו docker ps -a לפני ואחרי כדי לראות את ההבדל.

בדיקה: אחרי המחיקה, הקונטיינר שנמחק לא מופיע יותר גם ב-docker ps -a, בעוד השניים האחרים עדיין מוצגים (רץ/עצור, לפי המצב).

פרויקט מסכם#

המשימה: כתבו “מדריך אבחון” קצר (רשימת פקודות מסודרת) לתרחיש: “הקונטיינר של ה-API רץ, אבל בקשות HTTP אליו נכשלות”.

דרישות:

1. סדר בדיקה מוצע: docker ps (הקונטיינר בכלל רץ?), docker logs (יש שגיאות?), docker exec (הקבצים הנכונים בפנים?), בדיקת מיפוי פורט
2. הריצו את התרחיש בפועל (למשל, שכחת מיפוי פורט בכוונה) ותעדו כיצד כל שלב בדק חשף את הבעיה
3. תקנו את הבעיה ואמתו שהיא נפתרה

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

מה בפרק הבא#

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