נתונים וקונפיג — Volumes, משתני סביבה, וסודות כמו שצריך

למה הנתונים שלכם נעלמים — ה-writable layer ה-ephemeral

זה הרגע שבו רוב ה-Vibe Coders נתקלים בפעם הראשונה ב"באג שאף אחד לא מדבר עליו." אתם מריצים את האפליקציה ב-Docker, יוצרים משתמש חדש, רושמים הערה, מוסיפים קובץ — הכל עובד נהדר. עוצרים את ה-container (docker stop), מריצים מחדש (docker start) — הכל עדיין שם. ואז מוחקים את ה-container (docker rm) ומריצים docker run שוב — והמסד ריק, המשתמשים נעלמו, והקבצים חזרו לנקודת האפס של ה-image.

הרגע הזה הוא ה-aha moment של הפרק. זו לא באג. זו ארכיטקטורה.

ה-writable layer: הסיבה הטכנית

כל container שרץ בנוי משתי חלקים:

1. Image layers (read-only): שכבות ה-image שיצרתם ב-docker build. אלה קבועות, חסרות-שינוי, ולא משתנות בריצה. כל הוראה ב-Dockerfile יוצרת layer (FROM, COPY, RUN, וכו').
2. Writable layer (ephemeral — זמני): שכבה דקה מעל ה-image layers, שבה נכתבים כל השינויים שהאפליקציה עושה בזמן ריצה. יצירת קבצים, כתיבה למסד נתונים, שינוי הגדרות — הכל הולך לכאן.

הבעיה: ה-writable layer חי בתוך ה-container. כשאתם עושים docker rm <container>, אתם מוחקים את ה-container — ואיתו את ה-writable layer. ה-image layers נשארים (הם לא שייכים ל-container), אבל כל מה שהיה בתוך ה-container — נמחק. Container הוא disposable by design (חד-פעמי בעיצובו): הוא נועד לרוץ, למות, ולהיות מוחלף באחד חדש שזהה לו.

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

שתי דרכים לשמור נתונים מחוץ ל-container

Docker נותן שתי דרכים עיקריות להוציא נתונים מה-container:

• named volume — תיקייה ש-Docker יוצר ומנהל ב-/var/lib/docker/volumes/ על המארח. אתם נותנים לה שם (pgdata, mydata), Docker מטפל בשאר. זה מה שתשתמשו בו למסדי-נתונים, ל-state של האפליקציה, ולכל מה שרץ בפרודקשן.
• bind mount — מיפוי של תיקייה ספציפית מהמארח (הלפטופ שלכם) לתוך ה-container. אתם בוחרים את הנתיב, הוא תלוי במבנה המארח שלכם, ויש לו גישה ישירה לקבצים. זה מה שתשתמשו בו לפיתוח — לעריכת קוד ב-host ולראות את השינוי ב-container מיד.

ההבחנה הזו — volume מנוהל מול mount של מארח — היא אחת ההחלטות הכי מבלבלות למתחילים. בואו נפרק אותה לעומק.

named volume — האחסון המנוהל ששורד גם אחרי docker rm

named volume (בקיצור — volume) הוא אזור אחסון ש-Docker יוצר ומנהל בעצמו. אתם נותנים לו שם, Docker יודע איפה לשמור את הנתונים במארח (ב-/var/lib/docker/volumes/<name>/_data), ואתם לא צריכים לדאוג לנתיבים. כשאתם מצמידים את ה-volume ל-container, כל מה שה-container כותב לנתיב המצוין — נשמר ב-volume, לא ב-writable layer.

התחביר בפועל

אתם משתמשים ב--v (או --volume, שניהם זהים) עם הפורמט:

docker run -v volume_name:/path/inside/container image_name

לדוגמה, להריץ PostgreSQL עם volume בשם pgdata שישמור את הנתונים ב-/var/lib/postgresql/data (הנתיב ש-PostgreSQL מצפה לו):

docker run -d --name my-postgres \
  -e POSTGRES_PASSWORD=secret123 \
  -v pgdata:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

החלק החשוב: pgdata הוא השם של ה-volume, ו-/var/lib/postgresql/data הוא הנתיב בתוך ה-container שבו PostgreSQL שומר את הנתונים. שני החלקים נדרשים: בלי שם ה-volume, Docker יוצר anonymous volume עם hash אקראי; בלי הנתיב, Docker לא יודע לאן לחבר.

הוכחה — הנתונים שורדים את המחיקה

הנה הסצנה הקלאסית שתעשו היום, בשלוש דקות:

1. מריצים את ה-container עם volume (הפקודה למעלה).
2. מתחברים למסד, יוצרים טבלה, מכניסים שורה, יוצאים.
3. עוצרים ומוחקים את ה-container: docker stop my-postgres && docker rm my-postgres.
4. מריצים מחדש עם אותה פקודה (כולל -v pgdata:/var/lib/postgresql/data).
5. מתחברים שוב — הטבלה והשורה שם.

הסיבה: ה-volume pgdata לא היה שייך ל-container שמחקתם. הוא חי בנפרד, במערכת הקבצים של המארח, ורק ה-container "ראה" אותו דרך ה-mount. כשמחקתם את ה-container, ה-volume נשאר. כשהרצתם container חדש והצמדתם את אותו volume — ה-container החדש ראה את אותם נתונים.

פקודות ניהול של volumes

כמה פקודות שימושיות שתחזרו עליהן:

• docker volume ls — רשימת כל ה-volumes במערכת.
• docker volume inspect pgdata — מידע מפורט על volume ספציפי: איפה הוא נמצא במארח, מתי נוצר, ואיזה containers השתמשו בו.
• docker volume create mydata — יצירה ידנית של volume (לרוב לא צריך — -v name:/path יוצר אוטומטית).
• docker volume rm pgdata — מחיקה של volume ספציפי. אזהרה: מוחק את כל הנתונים שלא ניתנים לשחזור.
• docker volume prune — מחיקה של כל ה-anonymous volumes שלא בשימוש. named volumes לא נמחקים אוטומטית.

named volume מול anonymous volume

כשאתם כותבים docker run -v /path/in/container image (בלי שם לפני הנקודתיים), Docker יוצר anonymous volume עם hash אקראי כמו a1b2c3d4e5f6. הוא עובד, אבל אין לכם שם ידידותי לזכור, וקשה לנהל אותו. תמיד תנו שם — זה עולה שתי אותיות וחוסך בלאגן אחר כך.

bind mount — הגשר בין המארח ל-container לפיתוח

bind mount עושה משהו שונה לגמרי: הוא ממפה תיקייה מהמארח שלכם (הלפטופ, המקום שבו אתם עורכים קוד עם VSCode) לתוך ה-container, בזמן אמת. כל שינוי בקבצים במארח — משתקף מיד ב-container. זה הבסיס של hot reload — עריכת קוד בלי לבנות מחדש.

תחביר ה-bind mount

הפורמט דומה ל-volume, אבל במקום שם — נתיב מוחלט במארח:

docker run -v /absolute/path/on/host:/path/in/container image_name

דוגמה קלאסית לפיתוח:

docker run -d --name myapp-dev \
  -v $(pwd):/app \
  -p 3000:3000 \
  myapp:latest

החלק $(pwd):/app אומר: "קח את התיקייה הנוכחית במארח (שבה רץ ה-Dockerfile), ומפה אותה ל-/app בתוך ה-container." אם אתם עורכים את app.py במארח עם VSCode, ה-container רואה את השינוי מיד — בלי docker build מחדש, בלי docker run מחדש. רוב ה-frameworks המודרניים (Next.js עם Fast Refresh, Flask עם debug mode, FastAPI עם --reload) רואים את השינוי וטוענים את הקוד מחדש אוטומטית.

מתי bind mount, מתי named volume

הכלל פשוט:

• bind mount — לקוד בפיתוח. אתם רוצים לערוך ב-VSCode במארח ולראות את השינוי ב-container מיד. לא למסדי-נתונים — הוא תלוי במבנה המארח שלכם, ואם תעבירו את ה-container ל-VPS אחר, הנתיב לא יעבוד.
• named volume — לכל דבר שצריך לשרוד: מסדי-נתונים, קבצי uploads, cache, state. גם בפיתוח וגם בפרודקשן. אינדיפרנטי למבנה המארח, נייד בין מכונות.

המלכודת הקלאסית: להריץ מסד-נתונים עם bind mount של תיקייה במארח. זה עובד בפיתוח, אבל ברגע שתעלו לשרת, התיקייה הזו לא קיימת — והמסד לא עולה. מסדי-נתונים תמיד על named volume.

הפקודה המעשית — dev מול prod על אותו Dockerfile

הנה ההבדל המעשי שתרגישו ממש בתרגיל 2:

# Production: image אפוי, אין קוד במארח בכלל
docker run -d --name myapp-prod \
  -v mydata:/var/lib/myapp \
  -p 3000:3000 \
  myapp:v1.0

# Development: bind mount לקוד, hot reload
docker run -d --name myapp-dev \
  -v $(pwd):/app \
  -p 3000:3000 \
  -e NODE_ENV=development \
  myapp:latest

אותו image (myapp:latest), שתי סביבות. בפיתוח, הקוד שלכם גלוי וניתן לעריכה. בפרודקשן, ה-image עומד בפני עצמו — אין תלות במבנה המארח.

הזהירות הקריטית: container הוא disposable

עכשיו, אחרי שאתם יודעים על volumes, הנה הכלל שיחסוך לכם שעות תסכול: אל תערכו קבצים בתוך container רץ עם docker exec -it <id> sh. גם אם זה עובד עכשיו, השינויים שלכם חיים ב-writable layer — וייעלמו ברגע שתעשו docker rm או docker pull של image חדש. אם אתם צריכים לשנות משהו — תקנו את ה-Dockerfile, תקנו את הקוד, או השתמשו ב-bind mount. לא ב-docker exec.

משתני סביבה ב-runtime — -e, --env-file, ו-ENV ב-Dockerfile

עכשיו עוברים לחצי השני של הפרק: config. כל אפליקציה אמיתית צריכה הגדרות — כתובת מסד נתונים, API key, פורט, feature flag, סיסמה. השאלה היא לא אם צריך config, אלא איך מעבירים אותו ל-container בלי לדלוף אותו למקום הלא נכון.

שלוש דרכים להעביר config

יש שלוש דרכים עיקריות, וכל אחת מתאימה למקרה אחר:

1. -e KEY=value — משתנה בודד. מועבר inline בפקודת ה-docker run. טוב לבדיקה מהירה, גרוע לפרודקשן כי הוא נראה בהיסטוריית ה-shell.

   docker run -e POSTGRES_PASSWORD=secret123 postgres

2. --env-file .env — קובץ שלם של משתנים. Docker קורא את הקובץ ומעביר כל שורה KEY=value כמשתנה סביבה. זו הדרך המומלצת לפרודקשן.

   # .env
   POSTGRES_PASSWORD=secret123
   API_KEY=sk-abc123
   DATABASE_URL=postgres://user:pass@db:5432/mydb
   
   # הרצה
   docker run --env-file .env myapp

3. ENV ב-Dockerfile — ערך שנקבע בבנייה. הערך נכנס ל-image ונשאר ב-layer. מתאים לערכים לא-רגישים שלא משתנים בין סביבות (למשל גרסת אפליקציה, תיקיית ברירת-מחדל).

   # Dockerfile
   ENV APP_VERSION=1.0.0
   ENV NODE_ENV=production
   ENV PORT=3000

הכלל שיעזור לכם לבחור:

• סודות (API keys, סיסמאות, tokens): תמיד --env-file .env או -e. לעולם לא ENV ב-Dockerfile.
• config שמשתנה בין סביבות (dev/staging/prod): --env-file .env, או environment: ב-compose (פרק 5).
• config קבוע שלא רגיש (port, תיקייה, הגדרת build): ENV ב-Dockerfile.

ה-Application קורא את המשתנים

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

# Python (Flask / FastAPI)
import os
db_url = os.environ.get("DATABASE_URL")
api_key = os.environ["API_KEY"]  # KeyError אם חסר

# Node.js
const dbUrl = process.env.DATABASE_URL;
const apiKey = process.env.API_KEY;

# Shell
echo "DB host is $DATABASE_HOST"

העיקרון: ה-container לא צריך לדעת איך המשתנים הגיעו. הוא רק רואה אותם בסביבה שלו. זה מה שהופך את --env-file לכל-כך גמיש: אותו image, קבצי .env שונים, סביבות שונות.

קובץ .env — המבנה הנכון

קובץ .env הוא פשוט רשימת שורות KEY=value, בלי רווחים סביב ה-=:

# .env — local development, NEVER commit
NODE_ENV=development
DATABASE_URL=postgres://myuser:mypass@localhost:5432/mydb
API_KEY=sk-test-abc123
JWT_SECRET=super-secret-token-rotation
PORT=3000

והקובץ המקבילה, .env.example, נשמר ב-Git בלי הסודות:

# .env.example — checked into git, no real values
NODE_ENV=development
DATABASE_URL=postgres://user:pass@localhost:5432/dbname
API_KEY=your-api-key-here
JWT_SECRET=generate-a-random-string
PORT=3000

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

build ARG מול runtime ENV — ההבחנה שמונעת אסון

זו ההבחנה שהכי קל לבלבל בה, והבלבול הזה הוא מקור מס' 1 לדליפת סודות. שני directives נראים דומים, אבל הם חיים במקומות שונים לגמרי:

• ARG — זמין רק בזמן build. מועבר עם --build-arg KEY=value. הערך נשמר ב-image layer וניתן לחילוץ עם docker history.
• ENV / -e / --env-file — זמין רק בזמן run. הערך לא נכנס ל-image, הוא רק "מוזרם" לסביבת ה-container בריצה.

ההבדל בפועל

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

# Dockerfile — שימוש לא נכון
ARG API_KEY
ENV API_KEY=$API_KEY     # ← הערך נכנס ל-image layer!

# Dockerfile — שימוש נכון
# אין ARG, אין ENV. הערך מועבר בריצה:
# docker run --env-file .env myapp

בגרסה הראשונה, מי שיריץ docker history myapp יראה את ה-ARG ואת ה-ENV, ויוכל לחלץ את ה-key מה-layers. ה-key "נאפה" לתוך ה-image. זו דליפה קבועה — גם אם תמחקו את השורה מה-Dockerfile אחר כך, ה-image שכבר נבנה מכיל את הסוד.

בגרסה השנייה, ה-image לא מכיר את ה-key. הוא מקבל אותו רק כשמריצים docker run --env-file .env. docker history לא יראה שום דבר רגיש.

טבלת ההבחנה המהירה

הכלל: ARG לדברים שמשפיעים על הבנייה (גרסה, target platform, flag של compiler). ENV/-e/--env-file לדברים שמשפיעים על הריצה (config, סודות, endpoints). אם אתם רואים ARG API_KEY ב-Dockerfile — זה אות אזהרה אדום.

הכלל הקרדינלי: אף פעם לא לאפות סודות ל-image

הגענו ללב הפרק. זה הכלל החשוב ביותר בקורס כולו — חשוב יותר מ-cache, יותר מ-multi-stage, יותר מ-non-root USER. אם תזכרו רק דבר אחד, שזה יהיה זה.

הבעיה: סודות ש"נאפים" ל-image

"אפיית סוד" (secret baking) זה המצב שבו משתנה רגיש — API key, סיסמת מסד, token — נכנס לתוך ה-image בזמן הבנייה, ונשאר שם לנצח. הסיבות הנפוצות:

1. ENV API_KEY=sk-abc123 ב-Dockerfile. הערך נכתב ל-layer ונשאר ב-image.
2. ARG API_KEY=sk-abc123 ואז ENV API_KEY=$API_KEY. אותה בעיה בשני שלבים.
3. COPY .env /app/.env ב-Dockerfile בלי .dockerignore. הקובץ כולו נכנס.
4. RUN curl -H "Authorization: Bearer $API_KEY" ... ב-Dockerfile — הערך מופיע בהיסטוריית ה-layer.
5. Private key, certificate, או credentials file שמועתקים עם COPY.

בכל המקרים האלה, docker history myapp יראה את הערך, וכל מי שיכול למשוך את ה-image — יכול לחלץ אותו.

המספר שצריך לזכור: 48%

מחקרים על אפליקציות שפורסמו לציבור (כולל אלה שנבנו עם כלי AI) מראים שכ-48% מהן מכילות סוד שדלף לתוך ה-image — API key של OpenAI, token של GitHub, סיסמת מסד. זו לא בעיה נדירה; זו ברירת המחדל כשלא מקפידים. רוב המקרים האלה קרו למי שפשוט לא ידע ש-ENV ב-Dockerfile שומר את הערך ב-layer. הם חשבו שזה רק "הגדרה זמנית." לא. זה קבוע.

ההגנה — ארבע שכבות

ההגנה הנכונה היא בת ארבע שכבות, והן חייבות לעבוד יחד:

1. אל תכתבו סודות ב-Dockerfile. בלי ENV, בלי ARG, בלי COPY .env בתוך ה-Dockerfile. אם צריך config בבנייה, תכתבו placeholder שמוחלף בריצה.

2. החריגו .env מ-.gitignore. הקובץ לא יכול להגיע ל-Git. הוסיפו .env ל-.gitignore בראש הפרויקט, וצרו .env.example כתבנית ציבורית.

3. החריגו .env מ-.dockerignore. גם אם הקובץ נשאר במארח (למשל במהלך פיתוח), docker build לא יעתיק אותו לתוך ה-build context. docker init יוצר .dockerignore עם .env כברירת-מחדל — אל תמחקו אותו.

4. העבירו את הסוד בריצה. docker run --env-file .env myapp, או environment: ב-compose (פרק 5). הערך נשאר במארח, מועבר ל-container רק כשצריך, ולא נכנס ל-image.

כל ארבע השכבות נדרשות. אם תפספסו אחת — דליפה.

file-based secrets — סודות ב-/run/secrets ו-best practices

העברת סודות דרך משתני סביבה היא הסטנדרט ברוב המקרים, אבל יש לה חיסרון: משתני סביבה יכולים להופיע בלוגים, ב-stack traces, וב-dumps של ה-process. cat /proc/1/environ מציג את כולם לכל מי שיש לו גישה ל-container. לפעמים — במיוחד בפרודקשן אמיתי — זה לא מספיק.

החלופה: secrets כקבצים זמניים

Docker תומך ב-mount של סודות כקבצים בתוך ה-container, בנתיב /run/secrets/<name>. הקבצים האלה:

• לא נמצאים ב-image — הם מגיעים מ-host בלבד.
• נשמרים בזיכרון (tmpfs) במקרים מסוימים, לא נכתבים לדיסק.
• לא מופיעים ב-docker inspect כמשתני סביבה.
• נעלמים כשה-container נעצר — אין residual files.

התחביר עם Docker Compose (פרק 5):

services:
  myapp:
    image: myapp:latest
    secrets:
      - api_key
      - db_password

secrets:
  api_key:
    file: ./secrets/api_key.txt
  db_password:
    file: ./secrets/db_password.txt

בתוך ה-container, הקבצים מופיעים ב-/run/secrets/api_key ו-/run/secrets/db_password. האפליקציה קוראת אותם עם open('/run/secrets/api_key').read().strip() במקום os.environ['API_KEY'].

מתי זה הכרחי?

לרוב ה-Vibe Coders, --env-file .env הוא מספיק. file-based secrets מתאימים ל:

• אפליקציות ב-production שמוגשות דרך HTTPS, עם משתמשים אמיתיים.
• רגולציה או דרישות compliance (פיננסים, בריאות).
• סביבות מרובות-שירותים שבהן secrets מנוהלים במקום אחד (HashiCorp Vault, AWS Secrets Manager, Doppler).

עבור הפרויקט הראשון שלכם, --env-file .env הוא הצעד הנכון. כשתעברו לפרודקשן אמיתי בעוד כמה חודשים, תוסיפו file-based secrets או Vault.

לאמת שאין דליפה — docker history ו-inspect

לפני שאתם דוחפים image ל-registry (פרק 6) או נותנים למישהו אחר למשוך אותו — תעצרו לבדיקה אמיתית. שתי פקודות חובה:

docker history — רואה את כל ה-layers

הפקודה docker history myapp:latest (או --no-trunc לראות את הפקודה המלאה) מציגה את כל ה-layers של ה-image, ולכל layer — את ההוראה שיצרה אותו. חפשו:

• ENV API_KEY=... → בעיה. הסוד אפוי.
• ARG SECRET=... → בעיה. הסוד אפוי.
• COPY .env /app/ → בעיה. הקובץ כולו הועתק.
• RUN curl -H "Authorization: Bearer ..." → בעיה. הסוד בהיסטוריה.
• ENV PORT=3000 → תקין. לא סוד.
• ENV NODE_ENV=production → תקין. לא סוד.

אם אתם רואים משהו רגיש — תבנו מחדש. אין דרך "למחוק" סוד מ-image קיים. כל מה שנכנס ל-layer — נשאר.

docker inspect — רואה env vars ו-mounts

הפקודה docker inspect myapp:latest (או docker inspect <running-container-id>) מחזירה JSON עם כל המטא-דאטה של ה-image או ה-container. חפשו את השדות:

• Config.Env — רשימת כל ה-ENV שנקבעו ב-Dockerfile. אם יש שם ערך רגיש — בעיה.
• Mounts — רשימת volumes ו-bind mounts. אם Source מצביע על קובץ סוד במארח — שימו לב שזה לא נכנס ל-image.

בדיקה מהירה למצוא סודות שדלפו:

docker history myapp:latest --no-trunc | grep -iE "key|secret|token|password"
docker inspect myapp:latest | grep -iE "key|secret|token|password"

אם ה-grep מחזיר שורות — תבדקו כל אחת. שורה תמימה כמו ENV NODE_VERSION=20 היא תקינה; ENV STRIPE_KEY=sk_live_... — אסון.

רשת הביטחון האוטומטית — docker scout cves

בפרק 6 נרחיב על docker scout (כלי סריקת חולשות שמגיע עם Docker Desktop). הוא בונה SBOM (Software Bill of Materials — רשימת כל החבילות ב-image) ומסמן חולשות אבטחה ידועות. הוא לא יתפוס סוד שדלף — לזה אתם צריכים docker history — אבל הוא יתפוס base image ישן עם חולשות.

Capstone — האפליקציה רצה עם volume ו-env בפועל

עכשיו הכל מתחבר. בואו נריץ את התרחיש האמיתי: אפליקציה שמתחברת למסד-נתונים, סודות מועברים ב-runtime, הכל שורד restart. זו הבסיס לכל מה שיבוא בפרק 5 (compose) ובפרק 6 (deploy).

המסגרת: שני containers, שיתוף env ו-volume

התרחיש המלא: PostgreSQL עם named volume למסד, ואפליקציה שמתחברת אליו עם סיסמה מ---env-file. שני ה-containers עצמאיים; הקישור ביניהם הוא רק דרך הרשת וה-config.

# 1. הרצת PostgreSQL עם volume
docker run -d --name my-postgres \
  -e POSTGRES_PASSWORD=secret123 \
  -e POSTGRES_DB=mydb \
  -v pgdata:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

# 2. הכנסת נתונים (psql מהמארח, או דרך container נוסף)
docker exec my-postgres psql -U postgres -d mydb \
  -c "CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);"
docker exec my-postgres psql -U postgres -d mydb \
  -c "INSERT INTO users (name) VALUES ('Alice'), ('Bob');"

# 3. הרצת האפליקציה עם env file
cat > .env << EOF
DATABASE_URL=postgres://postgres:secret123@host.docker.internal:5432/mydb
API_KEY=sk-test-abc123
EOF

docker run -d --name myapp \
  --env-file .env \
  -p 3000:3000 \
  myapp:latest

# 4. הוכחת השרידות
docker stop my-postgres && docker rm my-postgres
docker run -d --name my-postgres-v2 \
  -e POSTGRES_PASSWORD=secret123 \
  -e POSTGRES_DB=mydb \
  -v pgdata:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

docker exec my-postgres-v2 psql -U postgres -d mydb \
  -c "SELECT * FROM users;"
# Alice, Bob — שם.

הרגע הזה — ראיתם את הנתונים נשרדים אחרי מחיקת ה-container — הוא ה-aha moment של volumes. זה לא קסם; זה פשוט נתיב במערכת הקבצים של המארח ש-Docker שומר בין ריצות.

הקיצור לעתיד — bind mount בפיתוח

אותו Dockerfile, אבל בסביבת פיתוח, אתם מחליפים את ה-volume ב-bind mount של קוד המקור:

# Development — קוד מהמארח, hot reload
docker run -d --name myapp-dev \
  -v $(pwd):/app \
  -p 3000:3000 \
  --env-file .env \
  myapp:latest

# עריכה ב-VSCode → שינוי מיידי ב-container
# (בהנחה שהאפליקציה רצה עם --reload / nodemon / debug mode)

ההבדל היחיד: pgdata:/var/lib/postgresql/data (named volume) הפך ל-$(pwd):/app (bind mount). ה-image אותו image, הקונפיג אותו קונפיג, הסביבה שונה.

אימות סופי — האם הסודות באמת בחוץ?

לפני שאתם מסיימים את הפרק, שלוש בדיקות שלוקחות 30 שניות ומוכיחות שהקוד שלכם נקי:

# 1. האם .env מוחרג מ-Git?
cat .gitignore | grep "^\.env$"
# צריך להציג שורה אחת: .env

# 2. האם .env מוחרג מ-Docker build?
cat .dockerignore | grep "^\.env"
# צריך להציג שורה אחת: .env

# 3. האם ה-image נקי מסודות?
docker history myapp:latest --no-trunc | grep -iE "key|secret|token|password"
# צריך להציג רק ENV בטוחים (PORT, NODE_ENV) או רשימה ריקה

אם שלוש הבדיקות עוברות — אתם במקום הנכון. ה-volume ישמור, ה-config יזרום, הסודות יישארו במארח. אתם מוכנים לפרק 5.