למה Docker — מ-'רץ אצלי במחשב' ל-'רץ בכל מקום'

'רץ אצלי במחשב' — הבעיה האמיתית

תרחיש שכל מי שעבד או עבדה עם AI על אפליקציה מכיר/ה: בלפטופ הקוד רץ. npm run dev עולה בשנייה, הדף ב-localhost:3000 נטען, ה-API מחזיר תשובות. הכל ירוק. עכשיו אתם רוצים להעלות את זה לאוויר — ל-VPS של ארבעה דולר בחודש, או לשלוח לחבר שיראה על מה עבדתם. ופתאום:

• גרסת Node לא מתאימה. על הלפטופ שלכם יש Node 20, על ה-VPS יש Node 18 מה-image הדיפולטי של Ubuntu 22.04. Module not found על חבילה שדורשת Node 20+. האפליקציה לא עולה.
• dependency חסר. ה-AI יצר requirements.txt (פייתון) או package.json (Node), אבל שכח חבילה אחת. או שהוסיף חבילה שלא תועדה. על הלפטופ שלכם זה עובד כי ההתקנה הידנית שעשיתם אתמול בלילה נשארה ב-node_modules המקומי, וכלום לא תיעד אותה. ברגע שעולים למכונה נקייה — קריסה.
• OS שונה. האפליקציה שלכם רצה על macOS. חבר פתח את הריפו על Windows — וקיבל שגיאות על סלאשים בנתיבים (/ מול \), על line endings (\r\n מול \n), או על ספריית lib שלמה שלא נטענת על Windows בלי WSL.
• סוד שנחשף. מסתבר שה-AI הטמיע את ה-API key שלכם ישירות בקוד. עכשיו הוא ב-.env שדחפתם ל-Git, וגם ייכנס ל-image של ה-VPS. זה לא רק "לא מקצועי" — זה חור אבטחה שאפשר לסרוק אוטומטית.

אלה לא תרחישים היפותטיים. זה המצב ברוב האפליקציות ש-AI בונה. והסיבה שזה קורה היא לא באג ב-AI — זה הפער המבני בין "הקוד רץ אצלי" לבין "הקוד רץ בכל מקום". Docker הוא הכלי שסוגר את הפער הזה — לא בכוח brute force של "תתקין את כל הגרסאות", אלא בכך שהוא אורז את האפליקציה כולה — קוד, גרסת שפה, dependencies, קונפיגורציה — ליחידה אחת ניידת.

ההבטחה של Docker בשפה פשוטה

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

זה הופך "works on my machine" — הבדיחה הכי ישנה בהנדסת תוכנה — ממשפט שמסתיר בעיה לעובדה מוגמרת: "works on every machine". וב-2026, עם הכמות של אפליקציות ש-AI בונה לבד, זה הפך מבדיחה לסטנדרט.

שלושת הכשלים של אפליקציות AI במספרים

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

1. ~82% התנגשויות dependencies

מחקרים של קהילת vibe-coding ו-2026 practical reports (כולל vibe-to-docker style guides) מראים ש-82% מהאפליקציות ש-AI בונה סובלות מהתנגשויות dependencies — חבילה שדורשת גרסה X של ספרייה, בזמן שחבילה אחרת דורשת גרסה Y. על הלפטופ שלכם זה עובד כי ה-AI ניסה, ראה שזה עובד, ושמר את ה-package-lock.json עם הגרסאות הנכונות. אבל ברגע שמנסים להעתיק את הריפו למכונה אחרת — או לבנות image מה-Dockerfile שאותו AI יצר — הקסם נשבר.

2. 60-70% אי-התאמת סביבה

60-70% מהאפליקציות נופלות בגלל אי-התאמת סביבה — גרסת Node/Python שונה, משתנה סביבה חסר (DATABASE_URL שלא הועבר), או ספריית מערכת (system library) שלא קיימת ב-VPS. זה הכשל הכי שקט: על הלפטופ שלכם npm install עובד כי הספרייה כבר מותקנת, ואף אחד לא תיעד את זה ב-package.json. ב-VPS — node: cannot open shared object file או libpython not found.

3. 48% סודות מקובעים בקוד

והנתון המפתיע ביותר: 48% מהאפליקציות ש-AI בונה מכילות סודות מקובעים (hardcoded secrets) — API keys, passwords, connection strings — שנכתבו ישירות בקוד, הוכנסו ל-Git, ועכשיו גלויים לכל מי שיש לו גישה לריפו. זה הכשל הכי מסוכן מבין השלושה, כי הוא לא רק גורם לקריסה — הוא גורם לדליפה. ה-API key שלכם ל-OpenAI או ל-Stripe עלול להיחשף תוך שעות.

בדיוק מה ש-Docker סוגר

שלושת הכשלים האלה הם בדיוק מה ש-Docker נועד לפתור — כל אחד מהם בצורה שונה:

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

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

container מול Virtual Machine — למה זה משנה לכם

הרבה אנשים שמתחילים עם Docker חושבים שהוא "Virtual Machine קל". זו אחת הטעויות הראשונות שמייצרות בלבול, ולכן חשוב לסגור אותה כאן.

מה זה Virtual Machine (VM)

מכונה וירטואלית היא בעצם מחשב שלם שרץ בתוך המחשב שלכם — עם מערכת הפעלה אורחת משלה (guest OS): Ubuntu על Windows, או Red Hat על Mac. כדי להריץ VM צריך שכבה שנקראת hypervisor (כמו VirtualBox, VMware, או Hyper-V), שמדמה חומרה וירטואלית ל-OS האורח. ה-OS האורח לא יודע שהוא "בתוך" משהו; הוא חושב שהוא מחשב אמיתי. בגלל זה כל VM:

• שוקל גיגה-בייטים (3-10 GB בלי קוד, הרבה יותר עם אפליקציה) — בגלל שהוא כולל OS שלם.
• עולה בדקות (30 שניות עד 5 דקות) — בגלל שצריך לאתחל את כל ה-OS.
• מבודד לחלוטין — אם תקלקל משהו ב-VM, המכונה המארחת לא מושפעת, ולהפך.

מה זה container

container, לעומת זאת, חולק את ה-kernel של מערכת ההפעלה המארחת. ה-kernel (הליבה של ה-OS — מה שמדבר עם החומרה) הוא של המכונה שעליה רץ ה-container. מה שבתוך ה-container זה רק שכבה דקה של מערכת הפעלה (root filesystem) + האפליקציה + ה-dependencies שלה. בגלל זה כל container:

• שוקל מגה-בייטים (10-500 MB) — בגלל שאין בו OS שלם.
• עולה בשניות (50-500 אלפיות שנייה עד שתיים-שלוש שניות) — בגלל שאין אתחול OS.
• מבודד ברמת תהליך — אם תקלקלו container, הוא נופל; המכונה המארחת ו-containers אחרים לא נפגעים. הבידוד קל יותר מ-VM, אבל מספיק בשביל 99% מהצרכים של אפליקציה אחת.

ההשוואה בטבלה

הנה ההבדל במבט-על:

למה זה משנה ל-Vibe Coder

המספר שכדאי לזכור: אותו שרת שמחזיק 10-15 VMs מחזיק 100-200 containers. זה לא תאוריה — זה המצב בפועל. ב-VPS של 4-6 דולר בחודש (Hetzner, DigitalOcean, Vultr, Contabo), אתם יכולים להריץ את האפליקציה שלכם + מסד נתונים + cache (Redis) + reverse proxy — הכל בתוך containers נפרדים, על אותה מכונה. אם הייתם צריכים VM לכל אחד מהם, הייתם צריכים 3 שרתים. זה ההבדל בין $4 לחודש לבין $20 לחודש — רק בגלל הארכיטקטורה.

בנוסף, containers זולים יותר בזיכרון. הם לא מריצים OS כפול, הם לא טוענים kernel נפרד, הם לא צריכים hypervisor. זה אומר שאתם יכולים לפתח ולבדוק את האפליקציה על הלפטופ שלכם, בלי לחימום המחשב ובלי לחכות דקה ל-boot של VM.

ברגע שההבחנה הזו ברורה, רוב הפחד מ-Docker נמוג: זה לא "מכונה וירטואלית שצריך להגדיר", זה תהליך שמקבל מעטפת קלה ומובטחת. בפרק 2 תראו את זה בעיניים: container של nginx (שרת web פשוט) עולה בפחות משתי שניות, ומגיש דף ב-browser תוך שלוש.

image מול container — ההבחנה שמסדרת את כל הקורס

אם הייתי צריך לבחור רק הבחנה אחת שתישאר איתכם לכל 6 הפרקים, זאת היא: image ≠ container. שני המושגים האלה נשמעים דומים, הם מופיעים באותו תחום, ורוב האנשים מערבבים ביניהם. ברגע שתנעלו את ההבחנה, כל פקודה בהמשך תהיה הגיונית.

image = המתכון הקפוא

image הוא קובץ קפוא, read-only (לקריאה בלבד), שמכיל את כל מה שצריך כדי להריץ את האפליקציה שלכם: מערכת הפעלה בסיסית (למשל Alpine Linux או Debian slim), גרסת שפה (Node 20, Python 3.11), dependencies מותקנים, קוד האפליקציה עצמו, והגדרות ברירת-מחדל. ה-image הוא בדיוק כמו קובץ התקנה של תוכנה (חושבים על .dmg במק או .exe בחלונות) — קובץ סטטי שאפשר לשמור, להעתיק, להעלות, להוריד.

הוא נוצר פעם אחת, מ-Dockerfile (קובץ טקסט של הוראות בנייה — נלמד בפרק 3), על-ידי הפקודה docker build. אחרי שהוא נוצר, הוא לא משתנה. אי אפשר "לערוך" image; אפשר רק לבנות גרסה חדשה ולשמור את הישנה.

container = התבשיל הרץ

container הוא מופע רץ של image. כשאתם כותבים docker run myapp:latest, Docker לוקח את ה-image של myapp, יוצר ממנו שכבת כתיבה דקה (writable layer) מעליו, ומריץ את התהליך הראשי שלו. זה ה-container.

מ-image אחד אפשר להריץ כמה containers שרוצים, במקביל. כל אחד מהם מקבל מקום משלו בזיכרון, ב-CPU, ברשת. הם לא רואים את הקבצים של השני (אלא אם כן מחברים ביניהם ב-volume או network — נלמד בפרק 4).

אפשר להריץ, לעצור, למחוק container בלי לפגוע ב-image. זה כמו להריץ תוכנה ולסגור אותה: התוכנה עדיין מותקנת, אבל המופע הספציפי שלה נעלם. אם תמחקו container, ה-image נשאר. אם תמחקו image, כל ה-containers שנוצרו ממנו מאבדים את הבסיס שלהם (אלא אם כן דחפתם את ה-image ל-registry קודם).

טבלת ההשוואה המסכמת

למה ההבחנה הזו קריטית לקורס

בפרק 3 תלמדו docker build — זה יוצר image. בפרק 3 גם תלמדו docker run — זה יוצר container. בפרק 5 תכתבו compose.yaml שמגדיר כמה services (כלומר: כמה containers שרצים ביחד). בפרק 6 תדחפו image ל-registry ותמשכו אותו על שרת. אם תבלבלו בין המושגים, כל פקודה תרגיש כמו כישוף. אם ההבחנה ברורה, הכל מתיישר.

הסימן הראשון שמישהו מתבלבל: הוא אומר "הרצתי image של postgres" כשהוא בעצם הריץ container. או "מחקתי את ה-image הזה" כשהוא בעצם עצר container. שימו לב לעצמכם. תרגישו נוח לחזור לסעיף הזה בכל פעם שמשהו לא מסתדר.

האנלוגיה שתישאר לכם — class ו-instance

אם אתם מכירים תכנות, ההבחנה הזו דומה מאוד ל-class מול instance: ה-image הוא ה-class (ההגדרה, התוכנית), ה-container הוא ה-instance (האובייקט החי בזיכרון). אפשר ליצור מ-class אחד כמה instances. שינוי ב-instance לא משפיע על ה-class. מחיקת instance לא מוחקת את ה-class.

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

או באנלוגיה קרובה יותר לעולם התוכנה: image = קובץ התקנה צרוב (.iso, .dmg), container = התוכנה שרצה אחרי שהתקנתם אותה. את קובץ ההתקנה אתם שומרים במחסן; את התוכנה אתם מריצים, סוגרים, ומריצים שוב. מחיקת התוכנה לא מוחקת את קובץ ההתקנה.

העוגן המנטלי הזה יעזור לכם בכל פעם שתתבלבלו: "אני בונה image? או מריץ container? מה אני עושה עכשיו?"

איזו פקודה עושה מה — היכרות בלי להריץ

בפרק 2 נריץ פקודות. בפרק 3 נריץ הרבה יותר. אבל כבר עכשיו שווה להכיר את שתי הפקודות הבסיסיות שתשתמשו בהן יותר מכל:

docker build — מייצר image

docker build לוקחת Dockerfile (קובץ טקסט שמכיל הוראות בנייה) ויוצרת ממנו image. ה-image נשמר במחסן המקומי של Docker על המכונה שלכם. בסוף הבנייה תקבלו image עם "tag" (תווית), למשל myapp:v1 או myapp:latest. ה-tag הוא בעצם השם שאתם נותנים ל-image, והוא מה שתצטטו אחר כך כשתריצו container.

בפרק 3 תכתבו Dockerfile בפעם הראשונה, ותראו איך docker build -t myapp:v1 . הופך 20 שורות של הוראות ל-image בגודל 200 MB שאפשר להריץ בכל מקום.

docker run — מתחיל container

docker run לוקחת image (או מושכת אותו מ-registry אם הוא לא מקומי) ויוצרת ממנו container רץ. ברירת המחדל: רץ ב-foreground, מדפיס את הפלט שלו לטרמינל שלכם, ונחסם עד שה-container יסתיים. אפשר להריץ ברקע (-d, מ-detach), לחבר פורטים (-p 8080:80), להעביר משתני סביבה (-e KEY=value), ועוד.

הדוגמה הכי קלאסית להראות את Docker עובד בפעם הראשונה: docker run -p 8080:80 nginx. זה אומר ל-Docker "תמשוך את ה-image של nginx מ-Docker Hub (אם עוד לא משכת), תיצור ממנו container, ותחבר את פורט 8080 במכונה שלי לפורט 80 בתוך ה-container". תוך שלוש שניות, אתם פותחים http://localhost:8080 בדפדפן ורואים את דף הברירת-מחדל של nginx. זה הרגע שבו "Docker" הופך ממילה מפחידה למשהו שרץ לכם מול העיניים. פרק 2 יוקדש כולו לרגע הזה.

הפקודות שתכירו בהמשך (לתזכורת)

רק כדי שתרגישו את ההיקף — בקורס הזה תפגשו את כל הפקודות האלה, ועוד:

• docker ps / docker ps -a — רשימת containers רצים / כולל עצורים.
• docker logs <id> — הפלט של container (logs).
• docker stop / docker rm — עצירה ומחיקה.
• docker exec -it <id> sh — כניסה לתוך container רץ עם shell.
• docker compose up — הרצת מספר containers יחד מקובץ compose.yaml.
• docker push / docker pull — העלאה ל-registry / הורדה ממנו.

בפרק 2 נלמד את הראשונות מתוכן. בפרק 5 את המרכזית של הקבוצה (compose). בפרק 6 את ההעלאה ל-registry. אין צורך לשנן עכשיו — רק לדעת שהפקודות האלה קיימות ושיש לכן סדר הגיוני.

OCI — התקן הפתוח שהופך את ה-image לנייד

אחת השאלות הכי טבעיות אחרי "מה זה image" היא: "למה ה-image שלי ירוץ בכל מקום, ולא רק ב-Docker?" התשובה היא OCI — Open Container Initiative.

OCI הוא תקן פתוח (כמו HTML או PDF) שמגדיר איך image נראה ואיך runtime של container צריך להריץ אותו. הוא נוצר ב-2015 על-ידי Docker ושותפים (CoreOS, Red Hat, Google, Microsoft ועוד), ומאז הוא הסטנדרד של כל כלי ה-container המודרני: Docker, Podman, containerd, CRI-O, ועוד. זה אומר שכלי אחד יכול לבנות image, וכלי אחר לחלוטין יכול להריץ אותו.

ההשלכה המעשית: אתם לא נעולים על Docker. ה-image שלכם ירוץ גם על Podman (חלופה daemonless), גם על containerd (רכיב הליבה של Kubernetes), גם על כל ענן שתעלו אליו. זו לא טכנולוגיה קניינית של Docker; זה תקן בינלאומי.

ב-2026, אחרי שה-OCI התבסס, בנייה של multi-platform image (אותו image שרץ גם על Mac שלכם עם שבב M-series וגם על VPS עם מעבד amd64) היא פעולה סטנדרטית, לא תכנון מוקדם. תוצר הלוואי היחיד שכדאי להכיר: המונח OCI manifest list — רשימה של גרסאות ה-image לארכיטקטורות שונות, שה-registry שומר ושהמכונה המושכת בוחרת ממנה אוטומטית. זה מה שמאפשר לכם לדחוף image אחד שעובד בכל מקום. נחזור לזה לעומק בפרק 6.

registry — הגשר מהלפטופ לשרת

עד עכשיו דיברנו על המכונה המקומית שלכם. אבל ההבטחה האמיתית של Docker היא "רץ בכל מקום" — וה-"בכל מקום" הזה כולל גם שרתים. איך מעבירים image מהלפטופ לשרת? באמצעות registry — מחסן של images ברשת.

registry הוא בעצם GitHub של images: שרת מרכזי שאליו אתם דוחפים (docker push) וממנו אתם מושכים (docker pull). כל מכונה שיש לה Docker יכולה לדבר עם registry: לדחוף, למשוך, להריץ.

שני registries שתכירו

יש שני registries שכדאי להכיר כבר עכשיו, כי הם הרלוונטיים ביותר ל-Vibe Coder:

• Docker Hub (docker.io) — ה-registry הציבורי הגדול בעולם, ברירת המחדל של Docker. רוב ה-images הפופולריים יושבים שם: nginx, postgres, redis, node, python, ועוד אלפים. חשוב: ל-Docker Hub יש מגבלות pull (100 אנונימי ל-6 שעות לכל IP, 200 אם אתם מחוברים עם חשבון Personal חינמי) — נדבר על זה בפרק 6 לעומק.
• GitHub Container Registry (ghcr.io) — registry חינמי של GitHub, יושב ליד ה-repo שלכם. קל לדחוף אליו דרך docker push ghcr.io/your-username/your-app:v1. מתאים במיוחד ל-Vibe Coder שכבר משתמש ב-GitHub — אין צורך בחשבון נוסף, ואין מגבלות pull בעייתיות.

איך זה עובד בפועל

התהליך ייראה בערך כך בפרק 6:

1. על הלפטופ: אתם בונים image מקומי: docker build -t myapp:v1 ..
2. על הלפטופ: אתם נותנים ל-image tag נוסף שמצביע על registry: docker tag myapp:v1 ghcr.io/your-username/myapp:v1.
3. על הלפטופ: אתם נכנסים ל-registry ודוחפים: docker push ghcr.io/your-username/myapp:v1. ה-image עכשיו בענן.
4. על השרת: אתם נכנסים ב-SSH, מושכים את ה-image, ומריצים: docker pull ghcr.io/your-username/myapp:v1 && docker run -d -p 80:3000 ghcr.io/your-username/myapp:v1. האפליקציה רצה.

זה הכל. אין קסם, אין deploy מורכב. ה-image הוא האריזה; ה-registry הוא המעבורת; השרת הוא היעד. בפרק 6 נעבור את התהליך הזה צעד-צעד, כולל הבעיות הקלאסיות שעולות בדרך (image שלא רץ בגלל ארכיטקטורה שונה, למשל).

מה Vibe Coder צריך מ-Docker — ולמה זה מספיק

Docker הוא עולם גדול. אם תחפשו בגוגל, תמצאו 200 מאמרים על Kubernetes, 100 על Swarm, 50 על CI/CD, 30 על service mesh. כל זה לא בשבילכם — לפחות לא בקורס הזה.

ה-Vibe Coder צריך בדיוק ארבעה דברים מ-Docker, וכל הקורס מתמקד בהם:

1. לארוז אפליקציה אחת (או שתיים, אם יש גם מסד נתונים) לתוך image שאפשר להריץ בכל מקום. זה מה שפרק 3 ילמד אתכם.
2. לשמר נתונים שלא נעלמים כשה-container נכבה — במיוחד במסד נתונים. זה מה שפרק 4 (volumes) ילמד.
3. להעביר config ו-API keys ב-runtime — בלי לאפות סודות לתוך ה-image. נלמד בפרק 4 גם כן (env vars ו---env-file).
4. להריץ את ה-image על שרת אמיתי — ידנית עם SSH או דרך Coolify, עם HTTPS אוטומטי. זה מה שפרק 6 יסגור.

זה הכל. ארבע יכולות. שישה פרקים. בלי הרבה תיאוריה, בלי הרבה ארכיטקטורה, בלי microservices-32. אפליקציה אחת, ארוזה טוב, רצה בכל מקום.

למה ה-scope הצר הזה עובד

הרבה אנשים שמתחילים עם Docker נכנסים למלכודת של "ללמוד הכל". הם קוראים על Kubernetes, מנסים להבין איך replicas עובדים, מתקינים Helm, מסתבכים, ומוותרים. זה קורה כי הם פתרו בעיה שהם לא צריכים לפתור.

הגישה של הקורס הזה הפוכה: להתחיל מהבעיה האמיתית שלכם (אפליקציה אחת שצריכה לרוץ ביותר ממקום אחד), לבנות בדיוק מה שצריך, ולעצור. אם תרצו Kubernetes בעוד שנתיים כשיש לכם 50 services — מצוין, יש קורסים מצוינים לזה. אבל עכשיו, 4 היכולות למעלה הן מה שמשנה.

מה מחוץ ל-scope — ולמה זה בסדר גמור

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

Kubernetes — לא בשלב הזה

Kubernetes הוא מערכת לניהול אלפי containers במקביל, עם auto-scaling, healing, rolling updates, ועוד עשרות יכולות. זה לא רלוונטי לאפליקציה אחת. אם יש לכם אפליקציה אחת שרצה על שרת אחד — Kubernetes הוא כמו להזמין משאית 18 גלגלים להסעת סלולרי. אפשר, אבל זה לא מה שעושים.

Docker Swarm — הוצא משימוש בפועל

Docker Swarm היה ניסיון של Docker לעשות תחליף קל ל-Kubernetes. ב-2026, הוא כמעט לא בשימוש. אם תראו מדריך ישן שמציע "לעבור ל-Swarm בשביל קנה-מידה" — תדעו שזה מדריך מ-2018. האלטרנטיבה המודרנית היא או Kubernetes (לקנה-מידה גדול) או פשוט docker compose (לקנה-מידה קטן). אנחנו בקטגוריה השנייה.

service mesh, sidecars, distributed tracing

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

CI/CD מתקדם

יש הבדל בין "להריץ image על שרת" (זה כן בקורס, פרק 6) לבין "בנייה אוטומטית בכל push, deploy אוטומטי, rollback אוטומטי" (זה לא בקורס). בקורס הזה תדחפו image ידנית לאחר בנייה, ותריצו deploy ידני או דרך Coolify שעושה חצי מהעבודה בשבילכם. CI/CD מלא (GitHub Actions + deploy אוטומטי + staging environments) הוא קורס נפרד, ומגיע אחרי שיש לכם את הבסיס.

הסיבה העמוקה: scope creep הורס קורסים

הסיבה שהרבה קורסי Docker נכשלים: הם מנסים ללמד את הכל. הם מתחילים ב-"מה זה container", ותוך 3 פרקים מדברים על overlays, CNI plugins, ו-cgroup v2. באמצע הפרק 4 הלומד מרגיש אבוד, ובפרק 6 הוא כבר לא שם.

הקורס הזה נשבע לא ללכת לשם. אם תסיימו את 6 הפרקים ותרגישו שאתם יודעים לארוז אפליקציה אחת ולהריץ אותה בכל מקום — עשינו את שלנו. אם תרצו יותר, יש 6 קורסי-המשך טבעיים (production, scale, security, observability, CI/CD, multi-cloud). אבל זה אחר כך.

מבט קדימה — איך image הופך ל-cornerstone של deploy

ה-mental model של image-זה-האריזה, container-זה-הריצה, registry-זה-המעבורת — הוא לא רק "עוד דרך להריץ אפליקציה". זה הבסיס לכל מה שתעשו ב-2026 בעולם ה-deploy: ה-image הוא הנכס היחיד שעובר בין הלפטופ לשרת לענן.

כשתגיעו לפרק 6, התהליך ייראה כך: בונים image מקומי → דוחפים ל-registry → שרת מושך ומריץ. אם תרצו HTTPS — Coolify מוציא תעודה אוטומטית דרך Let's Encrypt. אם תרצו לעבור ספק ענן — מושכים את אותו image מאותו registry, בלי שינוי. אם תרצו rollback — מחזירים tag ישן (v0.9 במקום v1.0), בלי לבנות מחדש.

זה ה-cornerstone של קורס ה-production שיבוא אחרי זה. הרבה מהדברים שמסבירים בקורסי production (rolling updates, blue-green, canary) בנויים על ההנחה שיש לכם image שאפשר לתייג, לדחוף, ולהחליף. בלי הבסיס הזה, קורסי production הם אוויר. איתו — הם הגיוניים מאליהם.

ולכן השיעור של הפרק הזה הוא לא "תכיר את Docker" אלא "תבין שאתה בונה נכס שיחזיק לכם חודשים".

הפחד מול המציאות

הרבה אנשים שמתחילים עם Docker מתארים חוויה דומה: הם פותחים מדריך, רואים 200 עמודים, שומעים מושגים כמו "image layer", "cgroups", "namespace", "union filesystem", ומרגישים שזה מעבר להם. הפחד הזה הוא נורמלי — וברובו מוצדק רק אם אתם מנסים ללמוד הכל.

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

ב-Docker, המקבילה היא:

• מפתח = התקנה של Docker Desktop (פרק 2).
• מתנע = docker run.
• הגה = docker build (ה-Dockerfile).
• דוושות = docker stop, docker rm, docker logs.

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

מה שמפחיד אתכם בעיקר בלבול מושגים

הפחד מ-Docker הוא לרוב בלבול בין מושגים, לא קושי אמיתי. ברגע שאתם יודעים:

• image ≠ container,
• container ≠ VM,
• build עושה image, run עושה container,
• registry שומר, push/pull מעביר,
• Dockerfile = מתכון, image = המנה הקפואה, container = המנה המוגשת,

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