מדריך פקודות 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 מדווח על תקינות, והיא מסתיימת עם קוד שגיאה אם אחד השירותים לא הגיע למצב זה. הדגל יעיל רק כמידת הדיוק של הבדיקה שמאחוריו, לכן כדאי להגדיר 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 עוקף את ההשוואה הזו ומחליף כל מכולה גם כאשר התצורה זהה, ולכן זו הדרך המהירה ביותר לנקות מצב (state) לא תקין בתוך המכולה.

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

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

צפייה בתהליכים רצים

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

נסו את sh לפני bash. תמונות (images) המבוססות על 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 מדפיס את כתובת המארח והפורט שבו פורט של מכולה מפורסם; זה חוסך ניחושים כאשר המיפוי מגיע ממשתנה. פרסום פורט גם כותב חוק firewall ש-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 מציג את הנפחים (volumes) בעלי השם שהפרויקט מצהיר עליהם, אחד בכל שורה. רשימה זו היא מה שעליכם לגבות. cp מעתיק קובץ אל תוך מכולה או ממנה החוצה ללא צורך בפתיחת shell, תוך שימוש בתחביר service:path בצד שבו נמצאת המכולה.

down -v מסיר את אותם נפחים בעלי שם יחד עם המכולות. זהו הפקודה הנכונה לפירוק סביבת בדיקות, אך היא שגויה עבור כל דבר המכיל נתונים שחשוב לכם לשמור, כיוון שאין בקשת אישור ואין אפשרות ביטול. 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 מציגה לאן נעלם שטח הדיסק לפני שמוחקים דבר מה, ומחלקת את הנתונים לפי תמונות (images), מכולות, כרכים (volumes) מקומיים ומטמון בנייה (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 על stack קריטי.

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

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 לפעולה לאחר אתחול אינה פקודה שאתם מקלידים, אלא יחידה שמריצה זאת עבורכם, כפי שמתואר ב-הפעלת stacks של Compose בעת עליית המערכת.

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 נשאר על build בן חודשים מבלי להציג שגיאה.

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

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

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

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