אפליקציות מרובות-Containers — Docker Compose ל-Web + מסד-נתונים

למה צריך את זה — הבעיה שפקודות docker run לא פותרות

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

# טרמינל 1: מסד-נתונים
docker run -d --name myapp-db \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

# טרמינל 2: האפליקציה
docker run -d --name myapp-web \
  -e DATABASE_URL=postgres://postgres:secret@host.docker.internal:5432/mydb \
  -p 3000:3000 \
  myapp:latest

# ואם האפליקציה לא התחברה — לבדוק, לעצור, להפעיל מחדש
docker logs myapp-web
docker restart myapp-web

זה עובד, אבל יש בזה ארבע בעיות:

1. שתי פקודות, שני טרמינלים, וסדר לא מובטח. הרצתם את ה-web לפני ה-db? הוא יקרוס. הפעלתם את שניהם ביחד? תקבלו connection refused באקראי.
2. host.docker.internal הוא קסם לוקלי. זה עובד רק ב-Docker Desktop על Mac/Windows, ולא ב-Linux ולא ב-VPS. אם תעתיקו את הפקודה לשרת — היא תישבר.
3. הגדרות ה-stack חיות רק בראש שלכם. אין קובץ שמתעד איזה port, איזה volume, איזה env var. חבר שירצה להריץ את הפרויקט? תצטרכו לשלוח לו את הפקודות ב-DM.
4. אין דרך פשוטה להפעיל חלק מה-stack. רוצים רק את ה-db בלי ה-web לבדיקה? תצטרכו לזכור את הפקודה הראשונה.

Docker Compose פותר את כל ארבע. קובץ compose.yaml אחד מגדיר את כל ה-stack (web + db, או web + db + cache, או כל שילוב שתרצו). פקודה אחת (docker compose up) מרימה הכל בסדר הנכון, מחברת את השירותים ברשת פנימית, ויוצרת קובץ שאפשר לשמור ב-Git. זה הפורמט הסטנדרטי לשיתוף פרויקטים שמורכבים מכמה שירותים — בלי שום קסם, בלי כתובות IP קשיחות, בלי סדר ידני.

רוב האפליקציות ש-AI בונה לכם הן לפחות web + db. הרבה מהן web + db + Redis (cache) או web + db + worker. בלי Compose, אתם מנהלים N פקודות docker run במקביל. עם Compose — N שורות YAML בקובץ אחד.

מבנה compose.yaml — services, image, build, ports, volumes, environment

קובץ compose.yaml הוא קובץ טקסט בפורמט YAML (YAML Ain't Markup Language) — שפת סידור נתונים שמשתמשת בהזחה (indentation) במקום סוגריים. כל שורה בקובץ היא key: value, וההזחה קובעת מה שייך למה. זה לא קוד — זה הגדרת תצורה (configuration).

המבנה הבסיסי

הנה ה-compose.yaml הקטן ביותר שעדיין עושה משהו אמיתי — שירות אחד שמריץ nginx:

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"

ארבע שורות, ואתם מקבלים את nginx רץ על http://localhost:8080. אבל הכוח של Compose הוא כמה services, אז בואו נראה stack אמיתי — web + database:

services:
  web:
    build: .                              # בנה image מה-Dockerfile בתיקייה הנוכחית
    ports:
      - "3000:3000"                       # host:container
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
    depends_on:
      db:
        condition: service_healthy       # חכה שה-db בריא

  db:
    image: postgres:16                    # משוך image מוכן מ-Docker Hub
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=mydb
    volumes:
      - pgdata:/var/lib/postgresql/data   # named volume למסד
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  pgdata:                                 # הצהרה על named volume ברמת ה-stack

זה הקובץ שמחליף את שתי פקודות ה-docker run מהסעיף הקודם. תשע עשרה שורות במקום שתי פקודות ארוכות — והמשמעות ברורה.

המפתחות שתכירו הכי טוב

בכל service יש כמה שדות עיקריים. הנה מה כל אחד עושה:

• image — שם ה-image ש-Compose ימשוך מ-registry (Docker Hub, ghcr.io, וכו'). דוגמאות: postgres:16, redis:7-alpine, nginx:latest.
• build — נתיב לתיקייה עם Dockerfile. Compose יריץ docker build בשבילכם. build: . אומר "התיקייה הנוכחית" (כמו docker build -t web .).
• ports — מיפוי port מ-host ל-container, בפורמט "host:container" (אותו כלל כמו -p ב-docker run).
• volumes — רשימת mounts. pgdata:/var/lib/postgresql/data = named volume. ./src:/app = bind mount. אותם כללים מפרק 4.
• environment — רשימת משתני סביבה. KEY=value inline, או רשימה עם - KEY=value (שתי הצורות תקפות).
• env_file — נתיב לקובץ .env עם משתנים. בדיוק כמו --env-file ב-docker run.
• depends_on — סדר הפעלה. בלי תנאי = "חכה שיתחיל". עם condition: service_healthy = "חכה שיהיה בריא".
• healthcheck — הגדרת probe שבודקת אם השירות באמת מוכן. נפרט בסעיף 8.

שתי רמות: services ו-volumes

שימו לב שיש שתי רמות בקובץ: services: (רשימת הקונטיינרים) ו-volumes: (רשימת ה-volumes המנוהלים). כשאתם כותבים - pgdata:/var/lib/postgresql/data בתוך service, אתם משתמשים ב-volume; כשאתם כותבים pgdata: ברמה העליונה, אתם מצהירים עליו. בלי ההצהרה, Compose יוצר anonymous volume — שעובד, אבל קשה לנהל. עם ההצהרה — יש לכם שם ידידותי.

זה ה-contract הבסיסי עם Compose: קובץ אחד, תיאור שלם של ה-stack. אם תראו קובץ compose.yaml ב-Git repo של פרויקט — אתם יודעים בדיוק איך הוא בנוי, בלי לקרוא שורה של docker run.

docker compose (רווח) מול docker-compose (מקף) — המעבר שכולם מפספסים

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

• docker compose (עם רווח) — Docker Compose v2. זה plugin שמובנה ב-Docker CLI מגרסה 20.10 ומעלה, וב-Docker Desktop. זו הצורה הנתמכת היום.
• docker-compose (עם מקף) — Docker Compose v1. זה היה Python script נפרד שהותקן בנפרד. הוא deprecated מאז 2023, ו-הוסר לחלוטין מ-Docker Desktop ב-2024. בהתקנות חדשות הוא בכלל לא קיים.

ההבדל בפועל:

# ✅ הצורה הנכונה (v2)
docker compose up
docker compose down
docker compose ps
docker compose logs

# ❌ הצורה הישנה (v1) — ב-Docker Desktop חדש תקבלו:
docker-compose up
# docker: 'docker-compose' is not a docker command
# או command not found

אז למה זה עדיין רלוונטי? כי מדריכים ישנים, פלט AI, Stack Overflow, ואפילו תיעוד רשמי שלא עודכן ממשיכים לפלוט docker-compose עם מקף. אם תעתיקו פקודה כזאת — היא תישבר.

הסימנים שהמדריך ישן

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

• docker-compose up (מקף) במקום docker compose up (רווח).
• הוראה להתקין עם pip install docker-compose או curl ... docker-compose — זה היה רלוונטי ב-2018, לא היום.
• קובץ docker-compose.yml עם מקף בשם (במקום compose.yaml). שני השמות עובדים ב-v2, אבל השם המומלץ בתיעוד הרשמי הוא compose.yaml בלי מקף.
• פקודות עם --build בלי ערך אחריו, או docker-compose --compatibility — דגלים של v1.

ההגירה בפועל

אם יש לכם docker-compose.yml ישן — אין צורך למחוק אותו. Docker Compose v2 תומך גם בשם הישן (עם מקף) וגם בחדש. אבל אם אתם כותבים חדש — תכתבו compose.yaml בלי מקף, ותשתמשו בפקודות עם רווח.

הרגל פשוט שיחסוך לכם שעות תסכול: תמיד חפשו את הרווח. docker compose = נכון. docker-compose = ישן.

image מול build באותו קובץ — לערבב image מוכן ו-image מקומי

אחד הדברים היפים ב-Compose הוא שאתם לא צריכים לבחור: או build או image. אתם יכולים לערבב באותו קובץ — שירות אחד שאתם בונים מקוד שלכם, ושירותים אחרים שאתם פשוט מושכים מ-registry.

הסיטואציה הקלאסית:

• web — זה הקוד שלכם, שאתם כותבים/עורכים. צריך build: . כי אין image מוכן ב-Docker Hub לאפליקציה הספציפית שלכם.
• db — זה PostgreSQL סטנדרטי. מישהו כבר בנה, תייג, ודחף ל-Docker Hub. אתם רק צריכים image: postgres:16.
• cache (אופציונלי) — Redis. באותו הגיון: image: redis:7-alpine.

ההפרדה הזו חשובה: אתם לא בונים PostgreSQL. אתם רק משתמשים בו. הקוד של האפליקציה שלכם הוא מה שאתם בונים. הכל השאר — כלים, ספריות, services סטנדרטיים — נמשך מ-registry.

build עם context

ברירת המחדל של build: . היא "תיקייה נוכחית" (התיקייה שבה נמצא ה-compose.yaml, או ה-relative path ממנה). אבל לפעמים ה-Dockerfile במקום אחר:

services:
  web:
    build:
      context: ./web              # תיקייה עם ה-Dockerfile
      dockerfile: Dockerfile.dev   # קובץ Dockerfile חלופי
    ports:
      - "3000:3000"

זה שימושי כשיש כמה סביבות (dev Dockerfile עם dev dependencies, prod Dockerfile רזה) או כשהקוד בתת-תיקייה.

image עם tag מותאם

כשאתם כותבים image: postgres:16, Compose מושך postgres:16 מ-Docker Hub. אבל image יכול לקבל גם שם של image פרטי שאתם בניתם:

services:
  web:
    build: .
    image: myapp:1.0              # בנה, וגם תייג ב-myapp:1.0
    ports:
      - "3000:3000"

בלי image אחרי build, Compose נותן שם זמני כמו project-web-1. עם image — הוא משתמש בשם שאתם נותנים, וגם docker images יראה אותו. שימושי כשרוצים לעקוב אחרי גרסאות.

service discovery — איך ה-web מוצא את ה-db בלי IP

זה אחד הקסמים של Compose. כשאתם מגדירים כמה services באותו קובץ, Compose יוצר רשת פנימית אוטומטית ומחבר את כולם אליה. ברשת הזו, כל שירות מקבל שם-מארח (hostname) שהוא שם ה-service שלו.

הנה הקסם בפועל. ה-service של ה-db נקרא db. ה-web רוצה להתחבר אליו. במקום לכתוב IP או host.docker.internal, פשוט:

# בתוך ה-web, החיבור למסד:
DATABASE_URL=postgres://user:pass@db:5432/mydb
#                                          ^^^
#                                          זה לא localhost, לא IP, לא host.docker.internal
#                                          זה פשוט "db" — שם ה-service

וזה עובד. תמיד. בלוקל, ב-VPS, ב-CI, בכל מקום. כי db הוא לא מחרוזת — הוא שם מארח ש-Compose רושם ב-DNS הפנימי שלו. כשה-container של ה-web פותח חיבור ל-db:5432, ה-DNS הפנימי אומר לו "ה-IP של db הוא 172.18.0.2" (או משהו דומה), והחיבור מתבצע.

למה זה עדיף על host.docker.internal

בפרק 4 השתמשנו ב-host.docker.internal בתור "קסם" שעובד רק ב-Mac/Windows Docker Desktop — זה שם מארח שמצביע על המארח מתוך ה-container. עם Compose, אנחנו לא צריכים את זה: ה-db רץ בתוך container משלו, באותה רשת כמו ה-web, ויש לו hostname משלו. אנחנו מדברים איתו container-to-container, לא container-to-host.

היתרון המעשי: אותו compose.yaml עובד על הלפטופ שלכם, על ה-VPS שלכם, ועל הלפטופ של חבר. בלי שינוי. בלי קסם תלוי-OS.

בדיקה מהירה — hostname resolution בפועל

אחרי שתריצו docker compose up, תוכלו להיכנס ל-web ולוודא שה-DNS עובד:

# היכנסו ל-container של ה-web
docker compose exec web sh

# בתוך ה-container, בדקו:
nslookup db
# Server:    127.0.0.11
# Address:   127.0.0.11#53
# Non-authoritative answer:
# Name:      db
# Address:   172.18.0.2

# או בלי nslookup, פשוט:
ping -c 1 db
# PING db (172.18.0.2): 56 data bytes
# 64 bytes from 172.18.0.2: ...

ה-127.0.0.11 הוא ה-DNS resolver הפנימי של Docker. הוא מכיר את כל ה-services ברשת. אתם לא צריכים לדעת את ה-IP האמיתי של ה-db — רק את השם.

מגבלה: רק בתוך אותה רשת

service discovery עובד רק בתוך הרשת ש-Compose יוצרת. אם תריצו docker run חיצוני ל-Compose (container "זר"), הוא לא יראה את db כ-hostname. בקובץ compose.yaml תוכלו להגדיר רשתות מותאמות (networks:) ולחבר רק services מסוימים — אבל זה מתקדם יותר, ולרוב לא תצטרכו את זה.

ports, volumes, ו-environment בקובץ אחד

הסעיף הזה הוא ה"תרגום" הישיר של מה שאתם כבר יודעים מפרק 4 (volumes, env vars) לעולם של Compose. הכלל פשוט: כל flag של docker run שאתם מכירים, יש לו מקבילה ב-Compose.

ports — מ-(-p) ל-(ports:)

ב-docker run הייתם כותבים -p 3000:3000. ב-Compose:

services:
  web:
    image: myapp:latest
    ports:
      - "3000:3000"   # host:container

אותו פורמט, אותו כלל host:container, אותה מלכודת של כיוון. 3000:3000 = "ב-host, port 3000 יוציא ל-container port 3000". אם תכתבו הפוך — החיבור יישבר.

יש גם וריאציות:

ports:
  - "3000:3000"          # host:container
  - "127.0.0.1:3000:3000" # רק מ-localhost, לא מהרשת
  - "8080:80"             # host port אחר

הצורה הראשונה היא מה שתשתמשו ב-99% מהמקרים. 127.0.0.1:3000:3000 שימושי כשאתם רוצים שרק המכונה המקומית תוכל לגשת ל-container (לא חושפים לרשת).

volumes — שלוש צורות

ב-Compose, volumes: יכול לקבל שלוש צורות:

services:
  db:
    image: postgres:16
    volumes:
      # 1. named volume (למסד-נתונים, production-ready)
      - pgdata:/var/lib/postgresql/data

      # 2. bind mount (לקוד בפיתוח)
      - ./src:/app

      # 3. anonymous volume (בלי שם, נדיר)
      - /var/lib/postgresql/data

volumes:
  pgdata:  # הצהרה על ה-named volume ברמת הקובץ

הצורה הראשונה (named volume) — בדיוק כמו -v pgdata:/var/lib/postgresql/data ב-docker run. הצורה השנייה (bind mount) — בדיוק כמו -v $(pwd)/src:/app. השלישית (anonymous) — נדירה, ועדיף להימנע.

environment — שתי דרכים

העברת config דרך הסביבה ב-Compose נראית ככה:

services:
  web:
    image: myapp:latest
    environment:
      # צורה 1: inline, בלי מרכאות (פשוט)
      NODE_ENV: production
      DEBUG: "false"

      # צורה 2: inline, עם רשימה (כמו CLI)
      - DATABASE_URL=postgres://user:pass@db:5432/mydb

      # צורה 3: הפניה למשתנה מהמארח
      - API_KEY=${API_KEY}

    # צורה 4: קובץ .env שלם (עדיף לסודות)
    env_file:
      - .env

ארבע צורות, אותה תוצאה. הכלל מפרק 4: ערכים לא-רגישים (NODE_ENV, ports, hostnames) יכולים להיות environment: inline. ערכים רגישים (סיסמאות, API keys) הולכים ל-env_file: שמצביע על .env, ו-.env ב-.gitignore וב-.dockerignore.

טבלת תרגום: docker run ↔ compose.yaml

הנה התרגום הישיר, לטיסה:

אם אתם זוכרים את הפקודה ב-docker run, אתם יודעים את המקבילה ב-Compose. זה אותו Docker, רק עם תחביר שונה.

הבעיה ש-depends_on לבדו לא פותר — connection refused

עד עכשיו דיברנו על איך לחבר services. עכשיו נדבר על מתי. וזה המקום שבו הרבה מתחילים נתקלים ב-flakiness שמטריד אותם שבועות.

התסריט הקלאסי

אתם מריצים docker compose up. Compose רואה שיש שני services: web ו-db. הוא רואה שיש depends_on: db ב-web. אז הוא עושה את מה שאתם מצפים: מריץ את ה-db לפני ה-web. נכון?

לא בדיוק. Compose מתחיל את ה-db לפני ה-web. זה נכון. אבל "מתחיל" לא אומר "מוכן לקבל חיבורים". PostgreSQL לוקח 2-5 שניות מהרגע שה-container עלה עד שהוא באמת מאזין ל-5432 ומוכן ל-authentication. באותו זמן, ה-web כבר מתחיל, מנסה להתחבר למסד, ומקבל connection refused.

web-1  | Error: connect ECONNREFUSED 172.18.0.2:5432
web-1  |   at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1661:16)
db-1   | PostgreSQL init process complete; ready for start up.
# ↑ ה-db סיים לעלות רק אחרי שה-web כבר ניסה להתחבר

אם תריצו שוב (docker compose restart web) — הפעם זה יעבוד, כי ה-db כבר רץ. אבל זה flakiness — בפעם הראשונה זה נשבר, בפעם השנייה זה עובד, ואתם לא יודעים למה.

הסיבה הטכנית

depends_on בלי תנאי אומר: "התחל את ה-dependency לפני שאתה מתחיל אותי". לא יותר. Compose לא בודק שה-process בתוך ה-container באמת פעיל, שהוא מאזין לפורט, או שהוא מוכן לקבל חיבורים. הוא רק מתחיל את ה-container.

הבעיה הזו ייחודית ל-environments שבהם ה-service צריך זמן "להתחמם" — מסדי-נתונים, caches, services שעושים migration, וכל דבר שמאזין לפורט. depends_on לבדו הוא סדר הפעלה, לא המתנה למוכנות.

הפתרון: healthcheck + condition: service_healthy

הסעיף הבא מראה איך healthcheck פותר את הבעיה הזו. אבל הנה spoiler — אתם צריכים שני דברים:

1. healthcheck: על ה-db, שמגדיר איך לבדוק אם ה-db באמת מוכן.
2. depends_on: db: { condition: service_healthy } על ה-web, שאומר "אל תתחיל אותי עד שה-db בריא".

בלי שני אלה יחד — ה-flakiness נשאר.

healthcheck — ה-probe שאומר "אני מוכן באמת"

healthcheck הוא probe (בדיקה) ש-Docker מריץ בתוך ה-container כל כמה שניות. אם ה-probe מחזיר 0 (הצליח) — ה-container מסומן healthy (בריא). אם הוא מחזיר ערך אחר או נכשל — unhealthy (לא בריא). אם הוא עדיין לא סיים probe ראשון — starting (מתחיל).

המבנה של healthcheck

הנה healthcheck ל-PostgreSQL:

healthcheck:
  test: ["CMD-SHELL", "pg_isready -U user -d mydb"]
  interval: 5s
  timeout: 5s
  retries: 5
  start_period: 10s

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

• test — הפקודה שרצה בתוך ה-container. pg_isready -U user -d mydb בודק אם PostgreSQL מקבל חיבורים לדטבייס הספציפי. exit 0 = בריא.
• interval — כל כמה זמן רץ ה-probe. 5s = כל חמש שניות.
• timeout — כמה זמן לחכות לפני שה-probe נחשב נכשל. 5s = אם לא סיים תוך חמש שניות, הוא נכשל.
• retries — כמה כשלונות רצופים לפני שה-container מסומן unhealthy. 5 = חמש פעמים שלא ענה, ואז בריאות ירודה.
• start_period — זמן חסד בהתחלה, שבו probes כושלים לא נספרים. 10s = תן למסד 10 שניות לעלות לפני שמתחילים לבדוק ברצינות.

probes נפוצים ל-services שתכירו

הנה רשימה קצרה של probes שתזדקקו להן. העתיקו והתאימו:

• PostgreSQL: test: ["CMD-SHELL", "pg_isready -U $POSTGRES_USER -d $POSTGRES_DB"]
• MySQL: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$MYSQL_ROOT_PASSWORD"]
• Redis: test: ["CMD", "redis-cli", "ping"]
• MongoDB: test: ["CMD", "mongo", "--eval", "db.adminCommand('ping')"]
• RabbitMQ: test: ["CMD", "rabbitmq-diagnostics", "ping"]
• HTTP (Next.js, FastAPI, Flask, Express): test: ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"] (דורש endpoint בריאות באפליקציה)
• nginx: test: ["CMD-SHELL", "curl -f http://localhost/ || exit 1"]

איך לראות את הסטטוס

אחרי docker compose up, תוכלו לראות את ה-health של כל service:

docker compose ps
# NAME        SERVICE   STATUS              PORTS
# myapp-db-1  db        Up (healthy)        5432/tcp
# myapp-web-1 web       Up                  0.0.0.0:3000->3000/tcp

# או עם docker ps:
docker ps --format "table {{.Names}}\t{{.Status}}"
# myapp-db-1   Up 2 minutes (healthy)
# myapp-web-1  Up 2 minutes

כשה-db עולה לראשונה, תראו Up (health: starting) במשך כמה שניות, ואז Up (healthy). הרגע שבו הוא עובר ל-healthy — זה הרגע שבו depends_on: condition: service_healthy מתחיל את ה-web.

למה CMD-SHELL ולא סתם CMD?

שימו לב לצורה ["CMD-SHELL", "..."] — זו הצורה הנכונה לרוב ה-probes. CMD-SHELL אומר "הרץ את זה דרך sh -c". זה מאפשר שימוש במשתני סביבה ($POSTGRES_USER), ב-pipes (||), וב-constructs של shell. הצורה ["CMD", "..."] (בלי SHELL) מריצה את הפקודה ישירות, בלי shell — טוב לפקודות פשוטות שלא צריכות expansion.

condition: service_healthy — החיבור שמסיר את ה-flakiness

עכשיו, אחרי שה-db יודע להגיד "אני בריא", אפשר לגרום ל-web להקשיב. ב-depends_on של ה-web, במקום הצורה הפשוטה:

# ❌ הצורה הפשוטה — רק "התחל לפני"
depends_on:
  - db

נכתוב את הצורה המפורשת:

# ✅ הצורה הנכונה — "חכה שיהיה בריא"
depends_on:
  db:
    condition: service_healthy

זה ההבדל בין "התחל את ה-db לפני שאתה מתחיל אותי" לבין "אל תתחיל אותי בכלל עד שה-db בריא".

מה קורה עכשיו בפועל

תרחיש מלא עם השניים ביחד:

1. אתם מריצים docker compose up.
2. Compose רואה שיש שני services. רואה שה-web תלוי ב-db עם תנאי service_healthy.
3. Compose מתחיל את ה-db.
4. ה-db מתחיל לעלות. ה-healthcheck probe רץ כל 5 שניות. עד שהוא מחזיר 0 (בריא) — הסטטוס הוא starting.
5. ברגע שה-probe מצליח (בדרך כלל תוך 3-8 שניות ל-PostgreSQL), ה-db מסומן healthy.
6. עכשיו, ורק עכשיו, Compose מתחיל את ה-web.
7. ה-web עולה, מתחבר ל-db ב-db:5432 דרך הרשת הפנימית, והחיבור מצליח מהפעם הראשונה.

אפס connection refused. אפס flakiness. אפס restart-ים ידניים.

condition: service_started לעומת service_healthy

יש עוד אפשרות: condition: service_started. זה אומר "חכה שה-container של ה-dependency התחיל" — שזה בערך כמו depends_on הפשוט (רק סדר). הצורה המועילה באמת היא service_healthy, והיא זו שתשתמשו בה לכל service שצריך זמן לעלות.

מתי כן מספיק service_started? כשה-dependency עולה מיידית ומוכן מיד — למשל, קובץ config server, או service פנימי שלכם שלא צריך warmup. ברוב המקרים — service_healthy.

מה קורה אם ה-db נופל?

healthcheck לא רק עוזר באתחול — הוא גם מנטר את ה-service במהלך הריצה. אם ה-db יקרוס באמצע הריצה, ה-probe יחזיר 1, הסטטוס יהפוך ל-unhealthy, ו-Compose יודיע על זה בפלט של docker compose ps (תראו Up (unhealthy)). עם restart: on-failure בקונפיג, ה-container יופעל מחדש אוטומטית.

אבל שימו לב: depends_on: condition: service_healthy בודק את התנאי רק בהפעלה. הוא לא יעצור את ה-web אם ה-db נופל תוך כדי ריצה. לזה צריך כלים אחרים (health monitoring, restart policies, observability).

docker compose up / down / logs / ps — טבלת ההפעלה

אחרי שיש לכם compose.yaml, רוב העבודה שלכם עם ה-stack תהיה עם חמש פקודות. הנה טבלה מלאה, ואחריה הסבר של כל אחת.

ה-flow היומי בפיתוח

הנה איך תעבדו ביום-יום עם ה-stack:

# בוקר — להרים את ה-stack
docker compose up -d
docker compose logs -f web   # לראות מה קורה

# אחרי שינוי בקוד של ה-web
docker compose up -d --build web   # בונה מחדש רק את ה-web
docker compose logs -f web

# אחרי שינוי ב-Dockerfile
docker compose up -d --build       # בונה מחדש את כל מה ש-build

# לבדוק מה רץ
docker compose ps
docker ps                          # רואה גם containers שלא ב-Compose

# דיבאג — להיכנס ל-container
docker compose exec web sh
# עכשיו אתם בתוך ה-web. תריצו ls, env, cat, או מה שצריך.
# exit כדי לצאת.

# סוף יום — לסגור
docker compose stop
# או:
docker compose down   # מוחק containers + רשתות, volumes נשמרים

חמש פקודות. up -d, up -d --build, ps, logs, down. זה ה-90% של העבודה היומית.

טעות שכולם עושים בהתחלה

כשה-web לא מתחבר, רוב המתחילים מיד עושים docker compose restart web. זה עובד? לפעמים. אבל זה לא דיבאג — זה קסם. במקום:

1. docker compose ps — מה הסטטוס? ה-db healthy או starting/unhealthy?
2. docker compose logs db — מה ה-db אומר?
3. docker compose logs web — מה השגיאה האמיתית?
4. docker compose exec web sh — היכנסו ובדקו env | grep DATABASE (האם ה-URL נכון?), ping db (האם ה-DNS עובד?).

ארבע פקודות אבחון במקום restart-ים עיוורים. זה ההבדל בין "אני מקווה שזה יעבוד" לבין "אני יודע למה זה לא עובד".

compose profiles בקצרה — הפעלה חלקית של ה-stack

זה קצר, ואתם לא חייבים להשתמש בזה עכשיו — אבל כשתצטרכו, זה יחכה לכם. profiles הם דרך להגיד ל-Compose: "ה-service הזה רץ רק אם ביקשתי אותו במפורש".

התסריט: יש לכם web, db, adminer (כלי web לניהול מסד), ו-mailhog (שרת דואר לפיתוח). ה-web וה-db אמורים לרוץ תמיד. adminer ו-mailhog רק בפיתוח, לא בפרודקשן.

services:
  web:
    build: .
    ports: ["3000:3000"]
    depends_on:
      db: { condition: service_healthy }

  db:
    image: postgres:16
    volumes: [pgdata:/var/lib/postgresql/data]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user"]
      interval: 5s
      timeout: 5s
      retries: 5

  adminer:
    image: adminer:latest
    ports: ["8080:8080"]
    profiles: ["dev"]   # רץ רק אם הפעלנו עם profile של dev

  mailhog:
    image: mailhog/mailhog:latest
    ports: ["1025:1025", "8025:8025"]
    profiles: ["dev"]   # גם רץ רק ב-dev

volumes:
  pgdata:

עכשיו, כשאתם מריצים docker compose up — רק web ו-db עולים. כדי להפעיל גם את ה-dev tools:

docker compose --profile dev up

או לכמה profiles ביחד:

docker compose --profile dev --profile debug up

השימוש העיקרי: להפריד "מה רץ בפיתוח" מ"מה רץ בפרודקשן" באותו compose.yaml. בפרודקשן (פרק 6) תריצו docker compose -f compose.yaml -f compose.prod.yaml up — אבל זה כבר שימוש מתקדם יותר. הכלל: אם הפרויקט שלכם פשוט (web + db), אתם לא צריכים profiles. אם הוא מורכב (כלי dev, multi-environment, observability), profiles יעזרו.

Capstone — אפליקציה + Postgres בקובץ אחד

עכשיו הכל ביחד. הנה compose.yaml שלם שמחבר את האפליקציה שלכם (נניח Node/Next.js או Python/Flask) עם PostgreSQL, כולל healthcheck, depends_on, named volume, ו-env file. זה הקובץ שאתם תשתמשו בו לאורך שארית הקורס.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: production
    env_file:
      - .env
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s

volumes:
  pgdata:

ולקובץ .env (כזכור — ב-.gitignore וב-.dockerignore):

POSTGRES_USER=appuser
POSTGRES_PASSWORD=changeme-in-production
POSTGRES_DB=myapp
DATABASE_URL=postgres://appuser:changeme-in-production@db:5432/myapp

שימו לב לשני דברים:

1. ה-DATABASE_URL ב-web מצביע על db:5432 — לא על localhost, לא על host.docker.internal. רק db, שם ה-service. זה עובד בלוקל, ב-VPS, ב-CI, בכל מקום.
2. ה-username/password ב-healthcheck מגיעים מה-.env דרך ${POSTGRES_USER}. ה-healthcheck רץ בתוך ה-container, אבל ה-substitution של המשתנים קורה ב-Compose לפני שה-container מתחיל — אז ה-probe רואה את הערכים האמיתיים.

הרצה

בתיקיית הפרויקט, עם Dockerfile, compose.yaml, ו-.env:

docker compose up -d
# מחכה 5-10 שניות
docker compose ps
# אתם אמורים לראות:
# NAME            SERVICE   STATUS              PORTS
# myapp-db-1      db        Up (healthy)        5432/tcp
# myapp-web-1     web       Up                  0.0.0.0:3000->3000/tcp

curl http://localhost:3000
# או פתחו ב-browser

זה ה-stack. כל ה-stack. שתי שורות (אחת ל-Compose, אחת לבדיקה) ויש לכם web + db רץ, בריא, מחובר, ומוכן.

לסגור, להפעיל מחדש, לאמת

docker compose down
# containers נמחקו, named volume pgdata נשמר

docker compose up -d
# חוזר. ה-db עולה, ה-web מחכה לו, הכל מתחבר.

# עכשיו — צרו נתונים באפליקציה דרך ה-browser.
# אחר כך:
docker compose down
docker compose up -d
# האם הנתונים שם? כן — כי ה-volume שרד.

זה ה-flow. זה הסוף של הקורס בעולם הלוקלי. כל מה שעשיתם בפרקים 1-4 — image, volume, env, healthcheck, service discovery — מתחבר לקובץ אחד. בפרק 6 תיקחו בדיוק את הקובץ הזה ל-VPS, וזה יעבוד.