פקודות Docker Compose חיוניות לניהול שרתים

פקודות Compose שבאמת תשתמש בהן

Docker Compose מפיץ יותר מארבעים פקודות משנה. עבודה יומיומית על שרת דורשת כעשר מהן. דף זה מקבץ אותן לפי המשימה שאתה מבצע, מספק סיבה פשוטה לכל אחת, ומפנה להסבר מעמיק כאשר פקודה מסוימת טומנת בחובה מלכודת.

הכל כאן משתמש ב-Compose V2: docker compose עם רווח, ולא בסקריפט הישן docker-compose. V2 הוא תוסף Go המותקן עם Docker Engine, ו-V1 הוסר מהחבילות הנוכחיות, לכן docker-compose: command not found על מכונת Ubuntu חדשה נכון ליולי 2026 הוא צפוי ולא תקלה. בדוק זאת עם docker compose version. אם הפקודה לא מציגה דבר, התקן את החבילה docker-compose-plugin.

כל פקודה להלן מורצת מהספרייה שמכילה את ה-compose.yaml שלך, כיוון ש-Compose גוזר את שם הפרויקט מאותה ספרייה ומוצא את הקובץ ביחס אליה. הרצת אותה פקודה רמה אחת למעלה תגרום ל-Compose לעצור עם no configuration file provided: not found. אם פורמט הקובץ עצמו חדש לך, התחל עם קובץ Compose ראשון על שרת VPS וחזור לכאן עבור הפקודות.

מחזור חיים: ארבע הפקודות שאתה מקיש, והאחת שמסירה קונטיינרים

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d יוצר את הרשת, יוצר את הקונטיינרים, מפעיל אותם ומחזיר שליטה. הוא חוזר ברגע שהקונטיינרים נוצרו, וזו הסיבה שתסריט פריסה שמבצע אחריו בדיקת curl נכשל לעיתים קרובות בניסיון הראשון. up -d --wait חוסם את התהליך עד שכל שירות שמגדיר healthcheck מדווח על מצב תקין, ומחזיר קוד יציאה שאינו אפס אם אחד מהם לא מגיע למצב זה. הדגל יעיל רק כמידת הבדיקה שעומדת מאחוריו, לכן כתוב בדיקת תקינות ש-Compose יכול לסמוך עליה לפני שתסתמך עליה באוטומציה.

stop עוצר את הקונטיינרים ושומר אותם, כך ש-start מחזיר את אותם הקונטיינרים עם אותה שכבת כתיבה. down עוצר אותם ולאחר מכן מסיר את הקונטיינרים ואת רשת הפרויקט. כל מידע שנכתב בתוך הקונטיינר ומחוץ ל-volume אובד יחד איתם. זוהי אי-ההבנה היקרה ביותר ב-Compose, והמאמר ההבדל המלא בין down ל-stop מסביר היכן היא גורמת לבעיות.

restart אינו טעינה מחדש (reload). הוא עוצר ומפעיל את אותו קונטיינר עם ההגדרות הקיימות שלו, לכן שינוי במשתנה סביבה, תגית image חדשה או מיפוי פורטים ערוך לא ישפיעו כלל. כדי להחיל שינוי בקובץ עליך להריץ שוב את up -d. Compose משווה כל שירות מול הקונטיינר הרץ שלו ויוצר מחדש רק את אלו שהגדרתם השתנתה.

החלת שינויים: יצירה מחדש, משיכה או בנייה מחדש

docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build web

הפקודה up -d כשלעצמה אינה מבצעת דבר כאשר לא חלו שינויים, וזה מה שהופך אותה לבטוחה להרצה חוזרת. הפקודה --force-recreate עוקפת את ההשוואה הזו ומחליפה כל קונטיינר גם כאשר הקונפיגורציה זהה, לכן זו הדרך המהירה ביותר לניקוי מצב חריג בתוך הקונטיינר.

עדכון אימג' דורש שתי פקודות מכיוון שהן מבצעות פעולות שונות. הפקודה pull מורידה את האימג' העדכני עבור כל תג המצוין בקובץ. לאחר מכן, up -d מזהה שמזהה האימג' של השירות אינו תואם עוד לקונטיינר הרץ ויוצרת אותו מחדש. דילוג על המשיכה יגרום לכך ש-up -d ימשיך להריץ את ה-latest של החודש שעבר ללא שגיאה.

הפקודה build חלה על שירותים שמגדירים סעיף build: במקום image:. הפקודה up -d --build בונה ומפעילה בשלב אחד, וזהו מחזור העבודה הרגיל בזמן שינוי קוד. השתמש ב---no-cache רק כאשר שכבה שמורה במטמון אינה מעודכנת בבירור, מכיוון שהיא בונה מחדש כל שכבה מאפס.

הצגת תהליכים רצים

docker compose ps
docker compose ps -a
docker compose logs -f --tail=100
docker compose logs --since 15m --timestamps db
docker compose top
docker compose ls

הפקודה ps מציגה רק קונטיינרים פעילים. שירות שקרס במהלך העלייה לא יופיע שם, אלא אם תוסיף את הדגל -a. לכן, מצב שבו קונטיינר חסר ב-ps בעוד ש-ps -a מציג אותו כ-Exited (1) הוא תופעה תקינה המעידה על כשל בעליית השירות. בדוק את קוד היציאה ולאחר מכן את הלוגים.

הפקודה logs -f עוקבת אחר כל השירותים בו-זמנית ומוסיפה תחילית של שם השירות לכל שורה. זהו המבט הדרוש כאשר שירותים מתקשרים זה עם זה וסדר האירועים הוא קריטי. ציין שם של שירות כדי לצמצם את התוצאות. הדגל --tail=100 חשוב עבור קונטיינר שרץ כבר חודש, שכן ברירת המחדל מדפיסה את כל ההיסטוריה ומציפה את הטרמינל. הדגל --since 15m עונה על השאלה הנפוצה ביותר: מה קרה במהלך ההפעלה מחדש שביצעת זה עתה.

הפקודה top מציגה את התהליכים בתוך כל קונטיינר, מה שמאפשר להבחין בין "הקונטיינר רץ" לבין "התהליך שבתוכו רץ". הפקודה ls יוצאת מחוץ לספרייה הנוכחית ומציגה את כל פרויקטי ה-Compose על המארח יחד עם הסטטוס שלהם, כך שתוכל למצוא את ה-stack שהפעלת לפני שלושה חודשים.

קבלת גישה למעטפת (Shell) בתוך שירות

docker compose exec web sh
docker compose exec -u root web sh
docker compose run --rm web env
docker compose run --rm --no-deps web sh

הפקודה exec מריצה פקודה בתוך קונטיינר שכבר פעיל. הפקודה run מפעילה קונטיינר חדש מאותה הגדרת שירות, וזהו הפתרון הנדרש כאשר השירות אינו נשאר פעיל מספיק זמן כדי לבצע אליו run. תמיד יש להשתמש ב-run יחד עם --rm, שכן ללא דגל זה, כל הרצה מותירה אחריה קונטיינר עצור, ואלו מצטברים עד ש-docker compose ps -a הופך לבלתי קריא.

נסה את sh לפני bash. אימג'ים המבוססים על Alpine אינם כוללים את bash, והשגיאה שתוצג תהיה exec: "bash": executable file not found in $PATH. הוספת --no-deps ל-run מדלגת על התלויות של השירות, מה שמונע מבדיקת קונפיגורציה מהירה להפעיל את כל בסיס הנתונים שלך.

הפקודה run --rm web env היא הדרך המהירה ביותר לראות את סביבת העבודה שקיבל השירות בפועל, לאחר שכל קובץ .env, בלוק environment: ומשתני המעטפת אוחדו. כאשר ערך מסוים אינו תקין, סדר האיחוד הוא בדרך כלל הסיבה לכך, והקישור כיצד Compose פותר קבצי סביבה וסודות מפרט איזה מקור מקבל עדיפות.

רשתות, פורטים ופתרון שמות

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

‏Compose מציב כל שירות על רשת פרויקט אחת, וכל שם שירות משמש כשם DNS בתוכה. הרצת getent hosts db בתוך web מדפיסה את כתובת ה-IP של הקונטיינר כאשר פתרון השמות תקין, ולא מדפיסה דבר כאשר הוא נכשל; כך ניתן לענות על השאלה "האם הקונטיינרים הללו יכולים לראות זה את זה" תוך שתי שניות. אם השם נפתר אך החיבור מסורב, התהליך בתוך db מאוגד ל-127.0.0.1 במקום ל-0.0.0.0, ולכן הוא לעולם לא יקבל חבילות מידע מקונטיינר אחר. שאר המודל הזה מפורט ב-אופן הפעולה של רשתות Compose ו-DNS של שירותים.

port web 80 מדפיס את כתובת המארח והפורט שעליהם פורסם פורט של קונטיינר, מה שחוסך ניחושים כאשר המיפוי הגיע ממשתנה. פרסום פורט גם כותב חוק חומת אש ש-Docker מנהל בעצמו, וחוק זה ממוקם לפני החוקים שלך, כך ששירות שחשבת שהוא פרטי עלול להיות חשוף לאינטרנט. מקרה זה מכוסה ב-מדוע פורטים של Docker שפורסמו עוקפים את ufw.

כרכים ונתונים

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes מדפיס את הכרכים בעלי השם שהפרויקט מגדיר, אחד בכל שורה. רשימה זו היא מה שעליך לגבות. cp מעתיק קובץ אל תוך או מתוך קונטיינר ללא פתיחת מעטפת (shell), תוך שימוש בתבנית service:path בצד שבו נמצא הקונטיינר.

down -v מסיר את אותם כרכים בעלי שם יחד עם הקונטיינרים. זוהי הפקודה הנכונה לפירוק מחסנית בדיקה (test stack), והיא הפקודה השגויה עבור כל דבר המכיל נתונים שחשובים לך, כיוון שאין אישור ואין אפשרות ביטול. Bind mounts שורדים פעולה זו, כיוון שהם חיים במערכת הקבצים של המארח. פער זה ברדיוס הפגיעה הוא אחת הסיבות לבחור במכוון בין bind mounts לבין כרכים בעלי שם.

ניקוי המפנה שטח דיסק מבלי לאבד נתונים

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

הפקודה --remove-orphans מוחקת קונטיינרים השייכים לפרויקט אך אינם מופיעים עוד בקובץ, וזה בדיוק מה שקורה לאחר שינוי שם של שירות. ללא פקודה זו, קונטיינרים אלו ממשיכים לרוץ כשהם בלתי נראים עבור docker compose ps.

הפקודה docker system df מציגה לאן הלך שטח הדיסק לפני שתמחק דבר מה, תוך פירוט של אימג'ים, קונטיינרים, ווליומים מקומיים ומטמון בנייה (build cache), עם נתון של שטח שניתן לפינוי עבור כל אחד מהם. הפקודה image prune -a מסירה כל אימג' שאף תג (tag) לא מצביע עליו, ובשרת שהוריד מספר גרסאות של אימג' גדול, זהו בדרך כלל החיסכון המשמעותי ביותר. הפקודה builder prune מנקה את מטמון הבנייה, אשר גדל בשקט בכל שרת שבנה אימג'ים משלו.

אף אחת מפקודות אלו אינה נוגעת בווליום בעל שם (named volume). רק docker volume prune ו-docker compose down -v עושות זאת.

בדיקת הקובץ לפני גרימת נזק

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --quiet מבצע אימות ואינו מציג פלט במקרה של הצלחה, לכן הוא מתאים לשלב שלפני הפריסה (pre-deploy) או כ-git hook. הפקודה config מציגה את הקובץ לאחר מיזוג ואינטרפולציה מלאים; זו הדרך לוודא שמשתנה עבר רזולוציה ושהגדרות העקיפה (override) הוחלו כצפוי. משתנה שלא הוגדר יופיע שם כערך ריק, לצד האזהרה The "X" variable is not set. Defaulting to a blank string..

--dry-run הוא דגל גלובלי ולא דגל של פקודת משנה, לכן יש להציב אותו לפני up. הוא מציג את כל הפעולות ש-Compose יבצע מבלי לשנות דבר; מדובר בשלושים שניות שמוטב להשקיע לפני הרצת down על סביבה קריטית.

עבודה עם קבצים, פרופילים ופרויקטים מרובים

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

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

הדגל --profile מפעיל שירותים שתויגו עם פרופיל זה לצד שירותים ללא תיוג, מה שמאפשר להשאיר כלי ניפוי שגיאות מחוץ להרצה רגילה של up. הדגל -p מגדיר את שם הפרויקט, כך שניתן להריץ שני עותקים של אותו ה-stack זה לצד זה עם רשתות נפרדות ושמות נפחים (volumes) נפרדים. החזרת ה-stack לפעולה לאחר אתחול אינה פקודה שכותבים ידנית, אלא יחידה שמבצעת זאת עבורכם, כפי שמתואר ב-הפעלת Compose stacks בעת עליית המערכת.

FAQ

מה החליף את docker-compose עם מקף?

Compose V2, המופעל כ-docker compose עם רווח. זהו תוסף המצורף ל-Docker Engine, וכלי ה-Python בגרסה V1 אינו מותקן עוד בחבילות הנוכחיות. אם הפקודה עם הרווח אינה מציגה דבר, התקן את חבילת docker-compose-plugin עבור ההפצה שלך. עדכן סקריפטים ישנים לשימוש בפורמט עם רווח במקום להוסיף alias, כיוון של-V2 יש דגלים שלא היו קיימים ב-V1.

מדוע docker compose restart לא מזהה את שינויי ההגדרות שלי?

restart עוצר ומתחיל את הקונטיינר הקיים עם ההגדרות ששימשו ליצירתו, והוא אינו קורא מחדש את compose.yaml. כל שינוי במשתני סביבה, פורטים, כרכים (volumes) או תגית ה-image מחייב את docker compose up -d, המשווה כל שירות מול הקונטיינר הרץ שלו ויוצר מחדש את אלו ששונים. הוסף את --force-recreate כאשר ברצונך שההחלפה תתבצע גם אם לא חל שינוי בקובץ.

כיצד אוכל לעדכן שירות ל-image חדש יותר?

הרץ את docker compose pull, ולאחר מכן את docker compose up -d. הפעולה pull מושכת את ה-image העדכני עבור כל תגית בקובץ, ו-up -d יוצר מחדש כל שירות שמזהה ה-image שלו אינו תואם עוד לקונטיינר. הרצת up -d לבדה עושה שימוש חוזר ב-image שכבר נמצא על הדיסק, וזו הסיבה ש-stack המקובע ל-latest נשאר על גרסה בת חודשים מבלי להציג שגיאה.

אילו פקודות ניקוי בטוחות לשימוש בשרת פעיל?

docker system df, docker image prune -a ו-docker builder prune מסירות images ומטמון בלבד, לכן שירותים רצים ממשיכים לעבוד וכרכים בעלי שם (named volumes) נותרים ללא שינוי. הצמד המסוכן הוא docker compose down -v ו-docker volume prune, המוחקים כרכים בעלי שם ללא התראה. הרץ תחילה את docker compose config --volumes כדי לדעת מה נמצא בסיכון.

האם ניתן להריץ פקודה אחת מבלי להפעיל את כל ה-stack?

כן. docker compose run --rm --no-deps web sh מפעיל קונטיינר בודד מתוך הגדרת השירות web, מדלג על התלויות שלו, ומסיר את הקונטיינר בעת היציאה. השתמש ב-exec במקום זאת כאשר הקונטיינר כבר רץ, כיוון ש-exec מתחבר לתהליך הפעיל ומציג לך את המצב שבו השירות נמצא בפועל.