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

עדכון image דורש שתי פקודות, משום שלכל אחת מהן תפקיד אחר. pull מורידה את ה־image העדכני עבור כל tag שמופיע בקובץ. לאחר מכן up -d מזהה שמזהה ה־image של השירות אינו תואם עוד למכולה שפועלת, ויוצרת אותה מחדש. אם מדלגים על שלב ה־pull, up -d משאירה את latest מהחודש שעבר פועלת בלי להציג שגיאה. הסיכון ההפוך מופיע ב־stack הכולל כמה שירותים: משיכת latest עבור כל השירותים בבת אחת עלולה להשבית יישום שעבד כראוי עשר שניות קודם לכן. לכן סביבת עבודה עצמית של AFFiNE מקבעת במקום זאת כל אחד מארבעת ה־image tags שלה. קיבוע הגרסה הופך גם את השדרוג לעריכה מכוונת של ה־tag, ולאחריה אותה פעולת pull ויצירה מחדש. ב־stack שמבצע migration למסד הנתונים בעת העלייה, רצוי שיהיה בידיכם dump לפני הפעלת אחת מהפקודות. זהו הנוהל ש־עמדת תמיכה עצמית של Chatwoot מיישמת בכל עדכון גרסה.

הפקודה 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. תמונות מבוססות Alpine אינן כוללות את bash, והשגיאה שתתקבל היא exec: "bash": executable file not found in $PATH. הוספת --no-deps ל-run מדלגת על התלויות של השירות, מה שמונע מבדיקת תצורה מהירה להפעיל את כל מסד הנתונים שלכם.

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

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

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, ולכן אינו מקבל מנות ממכולה אחרת. אותה הפרדה מסבירה מדוע מכולה שהופעלה מחוץ לפרויקט, באמצעות docker run או כחלק מ־stack עצמאי, אינה יכולה לפתור כלל שם כגון jellyfin. זהו הדבר הראשון שיש לבדוק כאשר ממשק קצה של Halcyon עבור ספריית Jellyfin שלך אינו מצליח להגיע לשרת שאליו הוא מצביע. שאר המודל מוסבר ב־אופן הפעולה של רשתות Compose ושל DNS לשירותים.

‏port web 80 מדפיס את כתובת המארח והפורט שבו פורט של מכולה מפורסם, מה שחוסך ניחושים כאשר המיפוי מגיע ממשתנה. פרסום פורט גם כותב חוק firewall ש-Docker מנהל בעצמו, וחוק זה ממוקם לפני החוקים שלכם; לכן, שירות שחשבתם שהוא פרטי עלול להיות חשוף לאינטרנט. מקרה זה מכוסה ב-מדוע פורטים של Docker שפורסמו עוקפים את ufw. השארת פורטים אלו ללא פרסום והצבת proxy מאמת על רשת הפרויקט לפני השירותים היא הגישה הבטוחה יותר, וזה מה ש-הרצת Authentik כשכבת Single Sign-On מספקת לכם.

נפחי אחסון ונתונים

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

config --volumes מציג את הנפחים (volumes) בעלי השם שהפרויקט מגדיר, אחד בכל שורה. רשימה זו היא מה שעליכם לגבות. כאשר הנפחים מכילים מידע שאינו ניתן לשחזור, פקודת הגיבוי המדויקת חשובה לא פחות מהרשימה; זו הסיבה ש-השוואת PhotoPrism ו-Immich מפרטת את פקודות ה-dump וההעתקה שכל שרת תמונות דורש. 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 מציג לאן הלך שטח הדיסק לפני שמוחקים דבר מה, ומחלק את הנתונים לתמונות, מכולות, כרכים (volumes) מקומיים ומטמון בנייה (build cache), עם נתון של שטח שניתן לפינוי עבור כל אחד. image prune -a מסיר כל תמונה שאף תגית לא מצביעה עליה; בשרת שהוריד כמה גרסאות של תמונה גדולה, זהו בדרך כלל הצעד המשמעותי ביותר. 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 זה לצד זה עם רשתות נפרדות ושמות volume נפרדים. החזרת ה-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 נשאר על גרסה בת חודשים מבלי להציג שגיאה.

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

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 מתחבר לתהליך החי ומציג לכם את המצב שבו השירות נמצא בפועל.