התקנה והרצה ראשונה — Desktop, ה-CLI, וה-container הראשון שלך

הפרק הזה הוא הסף המעשי של הקורס. אחרי שתסיימו אותו, "רץ אצלי במחשב" יהפוך ל"רץ גם אצלי במחשב, בלי שאני אכתוב שורת קוד". בפרק 3 כבר נארוז את האפליקציה שלכם לתוך image, ובפרק 6 נעלה אותו לשרת אמיתי. אבל הבסיס מתחיל כאן, בפקודה אחת של docker run.

התקנה על Windows — Docker Desktop דרך WSL2

על Windows, Docker Desktop לא רץ ישירות על הקרנל של Windows. הוא רץ בתוך מכונה וירטואלית קטנה שמבוססת על WSL2 (Windows Subsystem for Linux, גרסה 2) — שזה בעצם kernel של לינוקס אמיתי שמיקרוסופט בנו, ומשתלב בחלונות. למה זה חשוב? כי containers מעצם הגדרתם צריכים kernel של לינוקס (או Windows containers, אבל זה סיפור אחר לגמרי). בלי WSL2, Docker Desktop היה צריך להריץ VM כבד — איטי, זולל זיכרון, וחוסם אתכם מלהריץ קוד לינוקסאי מקומי. עם WSL2, ה-container שלכם רץ באותה סביבה שבה הוא היה רץ על שרת אמיתי, ואתם מקבלים ביצועים טובים בהרבה.

שלב 1: לוודא ש-WSL2 מותקן ומעודכן

ב-Windows 10/11 המודרני, WSL2 כבר מותקן, אבל לא תמיד בגרסה האחרונה. Docker Desktop דורש WSL בגרסה 2.1.5 ומעלה (עדיף עדכני). פתחו PowerShell או Terminal של Windows כמנהל (Run as Administrator) והריצו:

wsl --version
wsl --update

הפלט הראשון יראה לכם את הגרסה הנוכחית (למשל, "WSL version: 2.3.26.0"). השני יוריד ויתקין את הגרסה האחרונה. אחרי עדכון, הפעילו מחדש את Windows — לא מוותרים על זה. WSL2 הוא רכיב kernel; שינויים בו דורשים אתחול.

ודאו שהפצת לינוקס ברירת-מחדל מוגדרת ל-WSL2:

wsl --set-default-version 2
wsl --list --verbose

הפלט צריך להראות את ההפצה שלכם (Ubuntu היא ברירת המחדל) עם עמודת "VERSION" שמכילה "2". אם מופיע "1" — המירו עם wsl --set-version <DistroName> 2 (למשל, wsl --set-version Ubuntu 2).

שלב 2: הורדה והתקנה של Docker Desktop

היכנסו ל-docker.com/products/docker-desktop ולחצו "Download for Windows". הקובץ הוא Docker Desktop Installer.exe, שוקל כ-1.2 GB. הריצו אותו. ההתקנה לוקחת 2-5 דקות ותבקש מכם לסגור את כל החלונות הפתוחים בסוף (זה תוקף רכיבי מערכת, לא רק קבצים רגילים).

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

שלב 3: ההגדרות הראשונות ב-Docker Desktop

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

• Service agreement — אשרו (זה תנאי השימוש, לא מסמך משפטי שצריך לקרוא).
• האם להשתמש ב-WSL2 backend (מומלץ) או Hyper-V backend (ישן) — בחרו WSL2. זה ה-default המודרני, וזה מה שעובד הכי טוב.
• אילו הפצות WSL לשלב — סמנו את Ubuntu (או כל הפצה שאתם משתמשים בה).

תחת Settings → Resources → WSL Integration, ודאו שההפצה שלכם מסומנת. זה מה שמאפשר לכם להריץ docker מתוך ה-terminal של ההפצה (Ubuntu) בלי קונפיגורציה נוספת.

שלב 4: אימות ראשון

פתחו את ה-terminal של אובונטו (או PowerShell, אם הוספתם את Docker CLI ל-PATH), והריצו:

docker --version
docker run hello-world

הפלט הראשון יראה משהו כמו Docker version 27.x.x, build xxxxx — זה אומר שה-CLI מותקן. הפקודה השנייה תוריד image קטן בשם hello-world מ-Docker Hub, תריץ אותו, ותדפיס הודעת הצלחה. אם אתם רואים "Hello from Docker!" — סיימתם. המערכת שלכם מוכנה.

מלכודת מיקום הקבצים ב-WSL2 — לאן לשמור את הפרויקט

זו המלכודת הכי שכיחה ב-Windows, והיא גורמת לתלונה הנפוצה ביותר: "Docker איטי לי, ה-build לוקח 10 דקות במקום דקה". הפתרון פשוט, אבל צריך להכיר אותו לפני שמתחילים לעבוד.

שתי מערכות קבצים, שתי ביצועים

ב-WSL2 יש שתי מערכות קבצים:

• מערכת הקבצים של Windows (C:) — נגישה מ-WSL דרך /mnt/c/.... הקבצים שלכם נמצאים שם, והם נראים גם מ-WSL.
• מערכת הקבצים של לינוקס בתוך WSL2 — נגישה דרך \\wsl$\Ubuntu\home\<user>\... מ-Windows. הקבצים נשמרים ב-VHD של WSL2.

כשאתם עורכים קבצים בפרויקט שמקושר מ-WSL ל-Windows (למשל, פתחתם VSCode על C:\Users\me\myapp ומריצים docker build מתוך WSL שמסתכל על /mnt/c/Users/me/myapp), כל קריאה/כתיבה צריכה לעבור דרך גשר בין שתי מערכות הקבצים. זה מאוד איטי — במיוחד עבור file watching (המנגנון שבודק "האם קובץ השתנה?"). זה גם יוצר race conditions משונים שקשה לאבחן.

הכלל הפשוט

שמרו את קבצי הפרויקט בתוך מערכת הקבצים של לינוקס ב-WSL2, לא על C:. כלומר, עבדו עם ~/projects/myapp (או כל תיקייה בתוך ה-home של המשתמש באובונטו), ולא עם C:\Users\me\projects\myapp.

הדרך המעשית:

1. פתחו את terminal של אובונטו.
2. צרו תיקייה: mkdir -p ~/projects/myapp && cd ~/projects/myapp.
3. את קוד הפרויקט שלכם — העתיקו לכאן (או git clone <url>).
4. פתחו את VSCode דרך WSL: code . (הפקודה code מותקנת אוטומטית עם הרחבת "Remote - WSL" של VSCode).
5. הריצו docker build ו-docker run מה-terminal של אובונטו. הכל ירוץ במהירות מלאה.

אבל אני רגיל לעבוד ב-C:

אם אתם חייבים לעבוד ב-C: (למשל, הפרויקט מסונכרן עם OneDrive, או יש לכם סקריפטים שמתעדכנים מ-Windows), עדיין אפשר — פשוט צפו לביצועים נמוכים יותר. ה-build יעבוד, ה-image ייווצר, ה-container ירוץ, אבל הזמן יהיה ארוך פי 5-10. ברגע שתרגישו "Docker זה איטי", תדעו לבדוק קודם את מיקום הקבצים — וברוב המקרים זה יפתור את התלונה.

התקנה על Mac — Docker Desktop והחלופות הקלות

על Mac ההתקנה פשוטה יותר, כי macOS מבוסס על Unix ו-Docker Desktop רץ בתוך VM קל (המקבילה ל-WSL2 ב-Windows, אבל אפשר להתקין אותו בלי להפעיל שום רכיב מערכת).

אפשרות 1: Docker Desktop (הברירה הסטנדרטית)

הורידו מ-docker.com/products/docker-desktop את הגרסה ל-Apple Silicon (M1/M2/M3/M4) או Intel, תלוי בדגם שלכם. תבדקו ב-"About This Mac" → "Chip" אם אתם לא בטוחים. רוב המקינטושים מ-2021 ואילך הם Apple Silicon.

ההתקנה: גררו את Docker.app ל-Applications. בהרצה הראשונה macOS יבקש אישור לגישה לרשת (אשרו), ו-Docker Desktop יציג את ה-Service Agreement. קחו כוס קפה — ההורדה הראשונית של ה-runtime כברידה אולי 1-2 דקות.

אחרי ש-Docker Desktop רץ (תראו אייקון של לוויתן בתפריט העליון), פתחו Terminal והריצו docker --version ו-docker run hello-world. אם ההודעה המוכרת מופיעה — סיימתם.

אפשרות 2: OrbStack — חלופה קלה ומהירה יותר

OrbStack הוא כלי שעושה בדיוק את אותו דבר כמו Docker Desktop (GUI + CLI + container engine), אבל עם שתי יתרונות משמעותיים למקינטוש:

• זמן הרצה של container: ~1-2 שניות במקום 5-8 שניות. container קטן עולה ברגע, לא בכמה שניות.
• Footprint קטן בהרבה: OrbStack צורך כ-300-500 MB של זיכרון במצב idle, לעומת 1.5-2 GB של Docker Desktop. על Mac עם 8 GB זיכרון — זה ההבדל בין "עובד חלק" לבין "מתחיל להחליף לדיסק".

התקנה: הורידו מ-orbstack.dev, גררו ל-Applications, הריצו. ה-CLI של OrbStack מתחזה בתור docker — כלומר, אחרי ההתקנה, docker run nginx עובד בדיוק אותו דבר. אין צורך לשנות שום סקריפט.

OrbStack הוא חינמי לשימוש אישי. לעסקים יש רישיון בתשלום, אבל ל-Vibe Coder סולו הוא בחינם.

אפשרות 3: Rancher Desktop (חינמי לכל שימוש מסחרי)

אם אתם עובדים בחברה שעוברת את הסף של Docker Desktop (250 עובדים או $10M הכנסה — נדבר על זה בסעיף הבא), Rancher Desktop של SUSE הוא תחליף מלא שתמיד חינמי, גם לשימוש מסחרי (רישיון Apache-2.0). הוא גם מגיע עם k3s (קוברנטיס קל) בנוסף ל-Docker Engine, אבל לא חייבים להשתמש בזה.

הורידו מ-rancherdesktop.io. ה-CLI שלו גם מתחזה בתור docker, כך שהפקודות בפרק הזה עובדות בדיוק אותו דבר.

אז מה לבחור?

המלצה מעשית: Docker Desktop הוא הבחירה הבטוחה ל-Vibe Coder סולו. הוא חינמי, הוא רשמי, התיעוד של Docker מתייחס אליו ישירות. התקינו אותו, המשיכו הלאה. OrbStack — אם המק שלכם חזק אבל הזיכרון צמוד, או אם אתם מתעצבנים מ-5 שניות boot. Rancher Desktop — אם המעסיק שלכם ביקש רישיון מסחרי.

מיתוס העלות — מתי Docker Desktop חינמי ומתי לא

אחת השאלות שאני שומע הכי הרבה: "אבל Docker Desktop עולה כסף, נכון?" התשובה הקצרה: לא, לא בשבילכם. התשובה הארוכה דורשת להבין את הסף הרשמי.

הסף הרשמי (נכון ל-2026)

לפי docs.docker.com/subscription/desktop-license, Docker Desktop חינמי עבור:

• שימוש אישי (personal use).
• חינוך (education).
• פרויקטי open source לא-מסחריים.
• עסקים קטנים שעומדים בשני התנאים הבאים ביחד: פחות מ-250 עובדים וגם פחות מ-$10M הכנסה שנתית.

הקריטי כאן הוא ה-וגם. אם לחברה שלכם יש 200 עובדים אבל $20M הכנסה — אתם מעל הסף, וצריך רישיון. אם יש 300 עובדים אבל $5M — גם מעל הסף. רק עסקים שמתחת לשתי הספים ביחד זכאים לחינם.

מה עולה וכמה

התוכניות המסחריות (מחירים ל-2026, לחודש, חיוב חודשי — שנתי זול יותר):

מה עם Vibe Coder סולו?

המצב הרגיל שלכם: אתם אדם אחד, אולי עם עוד חבר או שניים שעובדים אתכם. אתם רחוקים מאוד מ-250 עובדים, והכנסה של $10M שנתית זו חלום רחוק לרוב הפרויקטים האישיים. ברירת המחדל שלכם: Docker Desktop חינמי.

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

Docker Engine (בלי Desktop) הוא OSS תמיד

חשוב להפריד: Docker Engine (ה-daemon שמריץ containers, dockerd) הוא קוד פתוח תמיד, בנפרד מ-Docker Desktop. על Linux, אתם מתקינים רק את Docker Engine וזהו — חינמי לכל שימוש, תמיד. הרישוי של Docker Desktop קיים רק על המוצר הספציפי הזה (האפליקציה הגרפית ל-Windows/Mac).

בקיצור: ה-Vibe Coder הישראלי הממוצע לא ישלם על Docker לעולם. המיתוס ש-"Docker זה כלי יקר" הוא בעיקר חוסר היכרות עם הסף.

הניצחון המיידי — docker run hello-world

הפקודה הזו תעבוד או לא תעבוד. אין באמצע. אם היא עובדת — יש לכם Docker פעיל, חיבור לרשת, ו-image registry פתוח. אם לא — יש לכם בעיה שצריך לפתור לפני שממשיכים. בואו נראה מה היא עושה.

מה קורה שלב אחר שלב

כשאתם מריצים docker run hello-world בפעם הראשונה, מאחורי הקלעים קורים ארבעה דברים:

1. Docker בודק אם ה-image hello-world קיים מקומית. הוא לא (אין לכם image כזה במחשב), אז Docker ממשיך לשלב הבא.
2. Docker פונה ל-Docker Hub (registry ציבורי ברירת מחדל) ומוריד את ה-image. הוא שוקל 13 KB — זה image של "Hello World" שעושה כלום חוץ מלהדפיס הודעה. ההורדה לוקחת פחות משנייה.
3. Docker יוצר container מה-image ומריץ את הפקודה הראשית שלו (במקרה הזה, סקריפט שמדפיס את ההודעה).
4. ה-container מסיים את עבודתו ויוצא. ה-image נשאר במחשב שלכם, מוכן לריצה חוזרת בלי הורדה.

הפלט אמור להיראות בערך כך:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

מה זה אומר עליכם

אם אתם רואים את ההודעה הזו, זה אומר ש-4 דברים עובדים אצלכם במקביל:

1. ה-CLI של Docker תקין — הפקודה זוהתה.
2. ה-Docker daemon (השרת הפנימי) רץ — יש לכם "מנוע" שמריץ containers.
3. הרשת שלכם פתוחה ל-Docker Hub — הורדה עברה.
4. ה-registry פתוח — Docker Hub הגיב.

אם משהו נשבר, ההודעת השגיאה תספר לכם איפה. "Cannot connect to Docker daemon" → ה-daemon לא רץ, צריך להפעיל את Docker Desktop. "Timeout pulling image" → בעיית רשת, צריך לבדוק proxy או חומת אש. "Permission denied" → בלינוקס, צריך להוסיף את המשתמש לקבוצת docker.

ה-container הראשון שלכם — nginx עם port mapping

עכשיו, אחרי שה"Hello World" עבר, הגיע הזמן להריץ משהו אמיתי. לא סקריפט שמדפיס הודעה, אלא שרת web שמגיש דף אמיתי ב-browser. ה-image הזה נקרא nginx (מבוטא "engine-x") — שרת HTTP פופולרי שמשרת כ-30% מהאתרים בעולם.

הפקודה

docker run -p 8080:80 nginx

זה הכל. פקודה אחת. הפלט יראה הורדה של ה-image (כ-50 MB, לוקח 5-20 שניות תלוי ברשת), ואז הודעות של nginx שמתחיל לרוץ. ה-container לא יוצא — הוא ממשיך לרוץ ב-foreground, מדפיס לכם logs של בקשות HTTP. זה הסימן שהוא חי.

עכשיו: פתחו browser (Chrome, Firefox, Safari — מה שבא לכם), ובשורת הכתובת הקלידו:

http://localhost:8080

אם אתם רואים את הדף המפורסם של nginx ("Welcome to nginx!"), זה הרגע שבו הבנתם את Docker. הרצתם שרת web אמיתי, בלי להתקין שום דבר על המחשב שלכם, בלי להגדיר אף קובץ קונפיגורציה, בלי לפתוח פורט ב-firewall של המערכת. הכל קרה בתוך container סגור, מבודד מהמערכת שלכם.

למה -p 8080:80?

הפלאג -p הוא port mapping — זה החלק הכי חשוב בפרק הזה, ונחזור אליו בסעיף נפרד. בקצרה: ה-container של nginx מאזין על פורט 80 בתוך עצמו (כי כל שרת HTTP ברירת-מחדל). המכונה שלכם לא יכולה לגעת בפורט הזה ישירות — ה-container הוא מכונה וירטואלית מבודדת. -p 8080:80 אומר ל-Docker: "כל בקשה שמגיעה לפורט 8080 אצלי, תעביר לפורט 80 בתוך ה-container."

ה-8080 הוא הפורט הציבורי שלכם (אתם בחרתם 8080 כי הוא פנוי, וכי הוא לא דורש הרשאות admin ברוב המערכות). ה-80 הוא הפורט הפנימי של ה-container. שמאל=המארח שלכם, ימין=ה-container. נחזור לזה בהרחבה.

מה עכשיו?

ה-container רץ ב-foreground ב-terminal. כדי לעצור אותו: Ctrl+C בחלון ה-terminal. ה-container ייסגר, אבל ה-image יישאר במחשב. אם תריצו שוב את אותה פקודה, הורדה לא תקרה — ה-image כבר שם.

אם תרצו להריץ את ה-container ברקע (לא תופס את ה-terminal), הוסיפו -d (detached):

docker run -d -p 8080:80 nginx

הפלט יהיה מחרוזת ארוכה — זה ה-container ID. השתמשו בו כדי לעצור את ה-container: docker stop <container-id>. נלמד את זה בסעיף הבא.

6 הפעלים היומיומיים — run, ps, logs, stop, rm, exec

יש ~70 פקודות Docker שונות, אבל בפועל 6 פקודות מכסות 90% מהצרכים שלכם. הכירו אותן, השתמשו בהן, ותוכלו להריץ כל container שתרצו. נעבור עליהן אחת-אחת, בדיוק בסדר שבו תשתמשו בהן ביום עבודה רגיל.

1. docker run — להריץ container מ-image

כבר הכרתם: docker run -p 8080:80 nginx. הפקודה הזו עושה 4 דברים ברגע אחד:

• בודקת אם ה-image קיים מקומית; אם לא — מושכת מ-registry.
• יוצרת container חדש מה-image.
• מריצה את הפקודה הראשית של ה-image (CMD ב-Dockerfile).
• ברירת מחדל: מציגה את הפלט של ה-container ב-terminal.

הפלאגים הכי שימושיים:

• -d — detached, רץ ברקע ולא תופס את ה-terminal.
• -p host:container — port mapping (נפרט בסעיף הבא).
• --name mycontainer — נותן ל-container שם במקום מחרוזת רנדומלית.
• -e KEY=VALUE — מעביר env var (נשתמש בזה בפרק 4).
• --rm — מוחק את ה-container אוטומטית כשהוא נעצר. שימושי לטסטים.

2. docker ps ו-docker ps -a — מי רץ, מי עצר

docker ps מציג את ה-containers שרצים עכשיו. הפלט הוא טבלה עם 7 עמודות:

CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                  NAMES
a1b2c3d4e5f6   nginx     "/docker-entrypoint.…"   2 minutes ago   Up 2 minutes   0.0.0.0:8080->80/tcp   wonderful_elion

הסבר על העמודות:

• CONTAINER ID — מזהה ייחודי. 12 תווים מתוך hash מלא. מספיק בשביל כל פקודה אחרת.
• IMAGE — ה-image שממנו ה-container רץ.
• COMMAND — הפקודה הראשית של ה-container.
• CREATED — מתי נוצר.
• STATUS — "Up X minutes" אם רץ, "Exited (0) X minutes ago" אם עצר.
• PORTS — port mapping (כאן: 8080 אצלי → 80 ב-container).
• NAMES — שם ידידותי. אם לא קבעתם, Docker ייתן שם אקראי כמו "wonderful_elion".

docker ps -a (הדגל -a = all) מציג גם containers שעצרו. זה הכלי הראשון שתריצו כשמשהו "נעלם" — הוא יגיד לכם "Exited (0)" (יצא תקין) או "Exited (1)" (קרס עם שגיאה).

3. docker logs <id-or-name> — מה ה-container אומר

כש-container רץ ברקע (-d), אתם לא רואים את הפלט שלו. docker logs מציג אותו: כל שורה שה-container הדפיס ל-stdout/stderr.

docker logs a1b2c3d4e5f6

פלאגים שימושיים:

• -f — follow, ממשיך להציג logs חדשים כשהם מגיעים (כמו tail -f).
• --tail 50 — רק 50 השורות האחרונות (לא כל ההיסטוריה).
• -t — מוסיף timestamps.

טיפ: אם container קרס ואתם רואים "Exited (1)", docker logs הוא הצעד הראשון שלכם. ברוב המקרים הודעת השגיאה האמיתית נמצאת שם.

4. docker stop <id-or-name> — לעצור בנימוס

docker stop שולח SIGTERM ל-container, נותן לו 10 שניות לסיים בנימוס, ואז שולח SIGKILL אם הוא לא מסיים. זו הדרך הנכונה לעצור container.

docker stop a1b2c3d4e5f6

אפשר לעצור כמה containers בבת אחת:

docker stop a1b2c3d4e5f6 f6e5d4c3b2a1 wonderful_elion

5. docker rm <id-or-name> — למחוק container שעצר

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

docker rm a1b2c3d4e5f6

כדי למחוק את כל ה-containers שעצרו בבת אחת:

docker container prune

Docker ישאל אישור, וימחק את כל מה שלא רץ. זה שווה ערך לפקודה "נקה הכל" במטבח — זהירים.

חשוב: docker rm מוחק container. docker rmi (עם i של image) מוחק image. אל תבלבלו. זו אחת הטעויות הכי שכיחות של מתחילים.

6. docker exec -it <id-or-name> sh — להיכנס פנימה

זו הפקודה הכי כיפית והכי מפחידה בו-זמנית. היא פותחת shell בתוך container רץ. אתם בתוך ה-container כאילו אתם SSH-ים לתוך מכונה קטנה.

docker exec -it a1b2c3d4e5f6 sh

הפירוט: -i = interactive (קלט מהמקלדת), -t = tty (terminal אמיתי), sh = ה-shell שתריצו. בתוך רוב ה-images (כולל nginx) זה shell קל (sh, לא bash). לצאת: exit או Ctrl+D.

למה זה שימושי? כי container הוא "קופסה שחורה" מבחוץ. docker exec מאפשר לכם:

• לראות את מערכת הקבצים של ה-container (ls /, cat /etc/nginx/nginx.conf).
• לבדוק אם process רץ (ps aux).
• להריץ פקודה ידנית שעוזרת לאבחן בעיה.
• לבדוק env vars (env), networking (cat /etc/hosts), ועוד.

אזהרה: שינויים שתעשו בתוך ה-container (עריכת קובץ, התקנת חבילה) יימחקו כשה-container ייעצר. ה-container הוא disposable — לא לערוך בפנים, אלא לתקן ב-image. נחזור לזה בפרק 4.

port mapping מפוענח — host:container

זה החלק שמבלבל 80% מהמתחילים. ברגע שתבינו את הכיוון, הכל יסתדר. בואו נפרק את -p 8080:80 לגורמים.

הרעיון: שתי מכונות, שני עולמות

container הוא כמו מכונה קטנה שרצה בתוך המחשב שלכם. היא:

• יש לה מערכת קבצים משלה (/, /etc, /usr...).
• יש לה רשת משלה. היא לא רואה את המארח ישירות, והמארח לא רואה אותה ישירות.
• יש לה פורטים משלה, מספרים 1-65535. אפסילון רץ על 80 בתוך ה-container, אבל אם תפתחו localhost:80 בדפדפן — לא יקרה כלום.

-p הוא ה"גשר". הוא אומר ל-Docker: "תאזין בפורט 8080 אצלי במכונה האמיתית. כל בקשה שתגיע לשם — תעביר לפורט 80 בתוך ה-container."

התחביר: host:container

תמיד שמאל=מארח, ימין=container. זה החוק היחיד שצריך לזכור.

• docker run -p 8080:80 nginx — "8080 על המארח → 80 ב-container." אתם ניגשים ב-browser ל-localhost:8080.
• docker run -p 3000:3000 myapp — "3000 על המארח → 3000 ב-container." אתם ניגשים ב-localhost:3000.
• docker run -p 80:3000 myapp — "80 על המארח → 3000 ב-container." (האפליקציה רצה על 3000 בפנים, אבל חשופה ב-80 בחוץ — שימושי כשרוצים URL נקי בלי :פורט.)

למה הכיוון מבלבל?

כי רוב האנשים חושבים "אני רוצה לחשוף את 80 של ה-container" — אז הם כותבים -p 80:something בלי לחשוב. אבל האסימטריה ברורה אם חושבים על זה ככה: ה-container כבר מאזין על 80 בפנים. השאלה היא איזה פורט במכונה שלי יחשוף אותו.

עוד דרך לחשוב על זה: -p הוא כמו מתאם לחשמל בנסיעה לחו"ל. ה-container זה המכשיר שלכם (תקע אירופאי, רץ על 220V). המארח זה הקיר המקומי (תקע אמריקאי, 110V). ה--p הוא המתאם: "תקע אמריקאי → תקע אירופאי". הוא לא משנה את המכשיר; הוא מאפשר לו לדבר עם הקיר.

מה קורה אם לא כותבים -p?

אם תריצו docker run nginx בלי -p, ה-container ירוץ, יאזין על 80 בתוך עצמו, אבל אף אחד מבחוץ לא יוכל להגיע אליו. זה שימושי לפעמים (למשל, כשה-container מתקשר עם containers אחרים ברשת פנימית), אבל לרוב תרצו גישה מהדפדפן שלכם.

אימות שהמיפוי עובד

הריצו:

docker run -d -p 8080:80 --name web1 nginx
docker ps

בעמודה PORTS תראו: 0.0.0.0:8080->80/tcp. המשמעות: Docker מאזין על 0.0.0.0:8080 (כל הממשקים, פורט 8080) במארח, ומעביר ל-80/tcp ב-container. פתחו http://localhost:8080 — תראו את ה-Welcome של nginx.

עכשיו הריצו:

docker run -d -p 9090:80 --name web2 nginx
docker ps

הוספתם container שני, על פורט שונה במארח (9090 במקום 8080) — אבל אותו פורט ב-container (80). עכשיו http://localhost:9090 יפתח את ה-container השני. שני containers, אותו image, שתי כתובות שונות. זו ההמחשה הכי טובה לכך ש-image ≠ container.

מלכודת ה-0.0.0.0 — למה האפליקציה חייבת להאזין נכון

עד עכשיו השתמשנו ב-nginx, שמאזין על 0.0.0.0 כברירת מחדל. אבל כשתריצו את האפליקציה שלכם (Next.js, Flask, FastAPI, Express, Streamlit), אתם עלולים להיתקל בתופעה הזו:

• הרצתם docker run -p 3000:3000 myapp.
• ה-container רץ (docker ps מראה "Up").
• אבל http://localhost:3000 מציג דף ריק, או "Connection refused", או נתקע.
• docker logs מראה: "Listening on http://127.0.0.1:3000".

זה הרגע שבו 50% מהמתחילים מוותרים על Docker ומחליטים שזה "לא עובד". הפתרון הוא הבנה של שני כתובות IP.

127.0.0.1 מול 0.0.0.0

שתי הכתובות האלה נראות דומות אבל מתנהגות הפוך:

• 127.0.0.1 (localhost) — "רק אני." האפליקציה שמאזינה על 127.0.0.1 מקבלת חיבורים מאותו process בלבד. בתוך container, זה אומר "רק מ-process-ים בתוך אותו container." היא לא מקבלת חיבורים מבחוץ, גם אם -p מוגדר נכון.
• 0.0.0.0 (any address) — "כולם." האפליקציה שמאזינה על 0.0.0.0 מקבלת חיבורים מכל ממשק רשת — מהקיר המקומי של ה-container, מהמארח דרך -p, ומ-containers אחרים באותה רשת.

המלכודת של אפליקציות AI

הרבה אפליקציות ש-AI כותב עובדות בריצה מקומית (npm run dev, flask run, uvicorn app:app). הן לא בנויות להיות בתוך container. הן מאזינות על 127.0.0.1 — כי ל-AI לא אכפת שהאפליקציה תהיה נגישה מבחוץ; הוא רק רוצה שהיא תעבוד על המכונה שלכם.

כשאתם עוטפים את האפליקציה ב-container, ה-127.0.0.1 הופך לבעיה: הוא אומר ל-container "אל תקבל חיבורים מהעולם החיצון" — וזה בדיוק מה שאתם כן רוצים כשאתם משתמשים ב--p.

הפתרון: האזינו על 0.0.0.0

הדרך הנכונה להריץ את האפליקציה שלכם ב-container (או בכל סביבה שרוצה גישה מבחוץ):

• Next.js / Node.js: next dev -H 0.0.0.0 או npm run dev -- -H 0.0.0.0.
• Flask: flask run --host=0.0.0.0.
• FastAPI / Uvicorn: uvicorn app:app --host 0.0.0.0.
• Express: app.listen(3000, '0.0.0.0') בקוד.
• Streamlit: streamlit run app.py --server.address 0.0.0.0.

אם אתם בונים את האפליקציה שלכם ב-Dockerfile (פרק 3), הפקודה שתרוץ ב-CMD צריכה לכלול את 0.0.0.0. למשל:

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "3000"]

איך לאבחן את הבעיה

אם http://localhost:8080 לא עובד:

1. docker ps — ה-container רץ?
2. docker logs <id> — ראו על איזה address הוא מאזין. אם אתם רואים "127.0.0.1" במקום "0.0.0.0", זו הבעיה.
3. אם זו הבעיה, תקנו את הפקודה שמריצה את האפליקציה (או את ה-Dockerfile בפרק 3).
4. docker exec -it <id> sh ואז netstat -tlnp (או ss -tlnp) — ראו את כל ה-ports הפתוחים ב-container.

הכלל: ה-container חייב להאזין על 0.0.0.0 כדי ש--p יעבוד. ה--p פותח פורט במארח, אבל אם ה-container לא מאזין על הפורט הנכון בפנים — אין לו לאן להעביר.

מה לגבי EXPOSE?

תראו ב-Dockerfile של images רבים שורה כמו EXPOSE 80 או EXPOSE 3000. זו לא פקודה שמפרסמת את הפורט. זו רק תיעוד. היא אומרת ל-Docker "ה-container הזה מתכוון להאזין על פורט 80", אבל לא עושה כלום ברשת.

כדי שהפורט באמת יהיה נגיש מבחוץ, אתם תמיד צריכים -p host:container ב-docker run, או ports: ב-compose (פרק 5). EXPOSE זה כמו הערה בקוד — מתעדת כוונה, לא מבצעת.

אז אל תסתמכו על EXPOSE. תמיד כתבו -p בפקודה שלכם.

ניקיון וסדר — stop, rm, ps -a

אחרי שעבדתם קצת עם containers, תגלו שנוצר לכם "מחסן" של containers שעצרו, images שלא בשימוש, ו-volumes זמניים. Docker נותן לכם כלים לסדר את זה — אבל חשוב להבין מה כל אחד מוחק, כדי לא למחוק משהו חשוב.

שלוש פקודות הניקיון המרכזיות

docker container prune — מוחק את כל ה-containers העצורים. לא נוגע ברצים, לא נוגע ב-images, לא נוגע ב-volumes. זו הפקודה הבטוחה ביותר להריץ כשאתם רוצים לסדר.

docker image prune — מוחק images שאין להם שום container שמשתמש בהם ("dangling images"). שימושי כש-pull-יתם image חדש עם אותו שם, או כשבניתם image מקומי שכבר לא רלוונטי.

docker system prune — מוחק הכל: containers עצורים, images שלא בשימוש, networks לא בשימוש, ו-build cache. זו פקודה "גרעין" — שימושית אחרי ניסויים רבים, אבל מסוכנת אם לא זוכרים מה היה שם. תמיד תעברו על הפלט לפני שתקישו Y.

פקודת "הכל בבת אחת"

אם אתם רוצים לסגור הכל ולהתחיל מאפס:

docker stop $(docker ps -q)
docker rm $(docker ps -aq)

הסבר: docker ps -q מחזיר רק IDs של containers רצים. docker ps -aq מחזיר IDs של כל ה-containers (כולל עצורים). $(...) מחליף את הרשימה לפקודה. שימו לב: הפקודה השנייה תנסה למחוק גם containers רצים — לכן ה- stop לפני.

מה לא למחוק

volumes (פרק 4). docker volume prune מוחק volumes שאינם בשימוש — כלומר, volumes שאף container לא מצביע עליהם. אם הפעלתם מסד נתונים ב-container, הווליום שלו יישאר גם אחרי docker rm — וזה בכוונה, כי הוא מכיל את הנתונים שלכם. אל תריצו volume prune בלי לבדוק קודם.

images עם tag. docker image prune בלי דגלים ימחק רק dangling images. אם תריצו docker image prune -a — הוא ימחק גם images שיש להם tag אבל אף container לא משתמש בהם כרגע. זה הגיוני לפעמים (אם אתם יודעים שלא תצטרכו אותם), אבל זה גם ימחק לכם את ה-image של nginx שלקח לכם 20 שניות להוריד. היזהרו.

רשימת containers שעצרו

תריצו את זה מדי פעם כדי לראות מה תקוע:

docker ps -a --filter "status=exited"

הפלט יראה לכם רק containers שעצרו. אם יש שם משהו שאתם לא מזהים — זה הזמן לחקור. אם זה ניסוי ישן — docker rm <id> ולהמשיך.

הגדרת המסך — מה לוודא לפני שממשיכים

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

4 הבדיקות לפני המעבר

1. Docker Desktop רץ. האייקון של הלוויתן בתפריט (Mac) או ב-system tray (Windows) לא מציג שגיאה. אם הוא אדום/כתום/אפור — לחצו ובדקו מה חסר.
2. docker --version עובד. פלט כמו Docker version 27.x.x, build xxxxx. אם לא — ה-CLI לא ב-PATH, צריך להפעיל מחדש את ה-terminal.
3. docker run hello-world עובד. הודעת "Hello from Docker!" מופיעה. זה מאמת שיש לכם engine, רשת, ו-registry.
4. docker run -p 8080:80 nginx + browser עובדים. ה-Welcome של nginx מופיע ב-localhost:8080. זה מאמת את כל המיומנויות של הפרק: image pull, container run, port mapping, ו-0.0.0.0.

אם כל 4 עובדים — אתם מוכנים לפרק 3. בו נלמד לארוז את האפליקציה שלכם לתוך image, לא רק להריץ images של אחרים.

מה לא צריך לבדוק (עדיין)

אל תבדקו את הדברים האלה בשלב הזה — הם לפרק 3+:

• בניית image מ-Dockerfile (פרק 3).
• Volumes ו-persistence של נתונים (פרק 4).
• Secrets ב-runtime (פרק 4).
• Compose עם מסד נתונים (פרק 5).
• Push ל-ghcr.io או deploy ל-VPS (פרק 6).

הפרק הזה הוא הבסיס. אם הוא יציב — השאר ייבנה עליו.