खऱ्या सर्व्हरसाठी Docker Compose commands ची यादी

प्रत्यक्ष वापरात येणारे Compose commands

Docker Compose मध्ये चाळीसपेक्षा अधिक subcommands उपलब्ध आहेत. सर्व्हरवरील दैनंदिन कामात त्यापैकी सुमारे डझनभर commands वापरले जातात. हे पृष्ठ तुम्ही करत असलेल्या कामानुसार त्यांची गटवारी करते, प्रत्येक command साठी एक स्पष्ट कारण देते आणि एखाद्या command मध्ये लपलेला धोका असल्यास त्यावरील सविस्तर मार्गदर्शिकेकडे निर्देश करते.

येथील सर्व माहिती Compose V2 साठी आहे: docker compose मध्ये space असतो; जुनी docker-compose script नाही. V2 हे Docker Engine सोबत install होणारे Go plugin आहे. सध्याच्या packages मधून V1 काढून टाकले आहे. त्यामुळे July 2026 मध्ये नव्याने तयार केलेल्या Ubuntu box वर docker-compose: command not found दिसणे अपेक्षित आहे; ही त्रुटी नाही. docker compose version वापरून तपासा. त्यातून काहीही output मिळत नसेल, तर docker-compose-plugin package install करा.

खालील प्रत्येक command तुमची compose.yaml असलेली directory current directory असताना चालवा. Compose project name या directory मधून घेते आणि file चा path त्याच्याशी संबंधित मानते. त्याच command ला एक level वरून चालवल्यास Compose no configuration file provided: not found दाखवून थांबते. File format तुमच्यासाठी नवीन असल्यास VPS वरील पहिली Compose file पासून सुरुवात करा आणि commands साठी येथे परत या.

Lifecycle: तुम्ही वापरत असलेले चार commands आणि containers काढून टाकणारा command

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

up -d network तयार करतो, containers तयार करतो, ते सुरू करतो आणि परत येतो. Containers तयार होताच तो परत येतो. त्यामुळे त्यानंतर curl probe चालवणारी deploy script पहिल्याच प्रयत्नात अनेकदा अपयशी ठरते. up -d --wait healthcheck घोषित केलेली प्रत्येक service healthy असल्याचे कळेपर्यंत थांबतो. एखादी service healthy स्थितीत पोहोचली नाही, तर तो non-zero status सह बाहेर पडतो. हा flag त्यामागील check जितका विश्वसनीय असेल तितकाच उपयुक्त असतो. त्यामुळे automation मध्ये त्यावर अवलंबून राहण्यापूर्वी Compose विश्वास ठेवू शकेल असा healthcheck लिहा.

stop containers थांबवतो आणि ते ठेवून देतो. त्यामुळे start त्याच containers ना त्याच writable layer सह पुन्हा सुरू करतो. down containers थांबवतो आणि त्यानंतर containers तसेच project network काढून टाकतो. Container मध्ये लिहिलेला आणि volume च्या बाहेर असलेला कोणताही डेटा त्यांच्यासोबत काढून टाकला जातो. Compose मधील हा सर्वात गंभीर गैरसमज आहे. down आणि stop मधील संपूर्ण फरक याचा परिणाम कुठे होतो ते स्पष्ट करतो.

restart हा reload नाही. तो विद्यमान configuration सह त्याच container ला थांबवून पुन्हा सुरू करतो. त्यामुळे बदललेला environment variable, नवीन image tag किंवा संपादित port mapping यांचा कोणताही परिणाम होत नाही. File मधील बदल लागू करण्यासाठी पुन्हा up -d चालवा. Compose प्रत्येक service ची तिच्या चालू container शी तुलना करतो आणि configuration बदललेल्या services चेच containers पुन्हा तयार करतो.

बदल लागू करणे: पुन्हा तयार करणे, pull करणे किंवा rebuild करणे

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 ही तुलना ओव्हरराइड करतो आणि configuration सारखीच असली तरी प्रत्येक container बदलून पुन्हा तयार करतो. त्यामुळे container मधील विचित्र state काढून टाकण्याचा हा सर्वात जलद मार्ग आहे.

image अपडेट करण्यासाठी दोन commands आवश्यक असतात, कारण त्या दोन वेगवेगळ्या गोष्टी करतात. pull फाइलमध्ये नमूद केलेल्या प्रत्येक tag साठी सध्याचा image डाउनलोड करतो. त्यानंतर up -d सेवा image ID आणि चालू container मधील image ID जुळत नाहीत हे ओळखतो आणि container पुन्हा तयार करतो. pull टाळल्यास up -d मागील महिन्यातील latest कोणतीही त्रुटी न दाखवता चालू ठेवतो.

build हे image: ऐवजी build: section जाहीर करणाऱ्या सेवांसाठी लागू होते. up -d --build एकाच टप्प्यात build करून सुरू करतो. कोडमध्ये बदल करताना हीच सामान्य प्रक्रिया आहे. Cached layer स्पष्टपणे जुना झाला असेल तेव्हाच --no-cache वापरा, कारण तो प्रत्येक 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 फक्त चालू असलेले containers दाखवते. सुरू होताना crash झालेली service तुम्ही -a जोडल्याशिवाय येथे दिसत नाही. त्यामुळे ps मध्ये container दिसत नसताना ps -a मध्ये त्याची स्थिती Exited (1) अशी दिसणे, हे startup failure चे नेहमीचे स्वरूप आहे. Exit code वाचा. त्यानंतर logs वाचा.

logs -f सर्व services एकाच वेळी monitor करते आणि प्रत्येक ओळीच्या सुरुवातीला service चे नाव देते. Services एकमेकांशी संवाद साधत असतील आणि घटनांचा क्रम महत्त्वाचा असेल, तेव्हा हाच view उपयुक्त ठरतो. Scope कमी करण्यासाठी service चे नाव द्या. महिनाभरापासून चालू असलेल्या container साठी --tail=100 महत्त्वाचे आहे, कारण default संपूर्ण history दाखवते आणि terminal मध्ये मोठ्या प्रमाणात output भरते. नुकताच केलेल्या restart दरम्यान काय घडले, या नेहमीच्या प्रश्नाचे उत्तर --since 15m देते.

top प्रत्येक container मधील processes दाखवते. त्यामुळे “container चालू आहे” आणि “त्यातील process चालू आहे” यांमधील फरक स्पष्ट होतो. ls सध्याच्या directory च्या बाहेर जाऊन host वरील सर्व Compose projects त्यांची स्थिती दाखवते. त्यामुळे तीन महिन्यांपूर्वी सुरू केलेला 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 आधीपासून सुरू असलेल्या container मध्ये command चालवते. run त्याच service definition वरून नवीन container सुरू करते. सेवा exec करण्याइतका वेळ सुरू राहत नसेल, तेव्हा run आवश्यक असते. run सोबत नेहमी --rm वापरा. अन्यथा प्रत्येक invocation नंतर थांबलेला container मागे राहतो. असे containers वाढत गेल्यावर docker compose ps -a वाचणे कठीण होते.

bash वापरण्यापूर्वी sh वापरून पाहा. Alpine आधारित images मध्ये bash नसते. त्यामुळे failure मध्ये exec: "bash": executable file not found in $PATH दिसते. run मध्ये --no-deps जोडल्यास सेवेच्या dependencies सुरू होत नाहीत. त्यामुळे configuration ची जलद तपासणी करताना संपूर्ण database सुरू होत नाही.

प्रत्येक .env file, environment: block आणि shell variable merge झाल्यानंतर सेवेला प्रत्यक्षात मिळालेले environment पाहण्यासाठी run --rm web env हा सर्वात जलद मार्ग आहे. एखादी value चुकीची असल्यास merge order हे सहसा कारण असते. Compose env files आणि secrets कसे resolve करते यामध्ये कोणत्या source ला प्राधान्य मिळते ते स्पष्ट केले आहे.

नेटवर्क, पोर्ट आणि name resolution

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

Compose प्रत्येक service ला एका project network वर ठेवते आणि प्रत्येक service चे नाव त्या network वरील DNS name असते. Resolution यशस्वी झाल्यास getent hosts db हे web मध्ये चालवल्यावर container IP दाखवते; resolution अयशस्वी झाल्यास काहीही दाखवत नाही. त्यामुळे “हे containers एकमेकांशी संपर्क करू शकतात का?” या प्रश्नाचे उत्तर दोन सेकंदांत मिळते. Name resolve होत असेल, पण connection refused मिळत असेल, तर db मधील process 0.0.0.0 ऐवजी 127.0.0.1 वर bound आहे. त्यामुळे दुसऱ्या container कडून आलेले packet ते कधीही स्वीकारत नाही. या मॉडेलचा उर्वरित भाग Compose networks आणि service DNS कसे कार्य करतात येथे दिला आहे.

port web 80 हे container port कोणत्या host address आणि port वर प्रकाशित केले आहे ते दाखवते. Mapping एखाद्या variable मधून आले असल्यास अंदाज बांधण्याची गरज राहत नाही. Port publish केल्यावर Docker स्वतः व्यवस्थापित करणारा firewall rule देखील तयार होतो. हा rule तुमच्या rule च्या आधी लागू होतो. त्यामुळे private असल्याचे तुम्हाला वाटत असलेली service इंटरनेटसाठी उघडी राहू शकते. ही परिस्थिती published Docker ports ufw ला bypass का करतात येथे स्पष्ट केली आहे.

व्हॉल्यूम आणि डेटा

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

config --volumes प्रोजेक्टने घोषित केलेले named volumes प्रत्येकी एका ओळीत दाखवते. तुम्ही याच सूचीचा backup घ्यायचा आहे. cp shell न उघडता container मध्ये किंवा container मधून file copy करते. यासाठी container ज्या बाजूला असेल त्या बाजूला service:path हे स्वरूप वापरले जाते.

down -v containers सोबत ते named volumes देखील काढून टाकते. Test stack काढून टाकण्यासाठी ही योग्य command आहे. परंतु महत्त्वाचा data असलेल्या कोणत्याही stack साठी ती चुकीची आहे, कारण कोणतीही confirmation मागितली जात नाही आणि ही कृती पूर्ववत करता येत नाही. Bind mounts यामुळे टिकून राहतात, कारण ते host filesystem वर असतात. या दोन्हींच्या परिणामक्षेत्रातील फरकामुळे bind mounts आणि named volumes यांपैकी योग्य पर्याय जाणीवपूर्वक निवडणे महत्त्वाचे ठरते.

डेटा न गमावता डिस्कवरील जागा मोकळी करणारी स्वच्छता

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

--remove-orphans प्रकल्पाशी संबंधित पण फाइलमध्ये आता नसलेले containers हटवते. सेवा rename केल्यानंतर नेमके हेच containers उरतात. हे न केल्यास ते containers चालूच राहतात आणि docker compose ps मध्ये दिसत नाहीत.

काहीही हटवण्यापूर्वी डिस्कची जागा कुठे वापरली आहे हे docker system df दाखवते. ती images, containers, local volumes आणि build cache यांचे स्वतंत्र विभाजन दाखवते आणि प्रत्येकासाठी reclaimable आकडा देते. कोणत्याही tag कडून संदर्भित नसलेली प्रत्येक image image prune -a हटवते. मोठ्या image च्या अनेक versions pull केलेल्या सर्व्हरवर यामुळे सहसा सर्वाधिक जागा मोकळी होते. स्वतःच्या images तयार करणाऱ्या कोणत्याही सर्व्हरवर हळूहळू वाढणारा build cache builder prune साफ करते.

यापैकी कोणतीही command named volume ला स्पर्श करत नाही. फक्त docker volume prune आणि docker compose down -v named volume हटवतात.

काही बिघडण्यापूर्वी फाइल तपासणे

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

config --quiet फाइलचे प्रमाणीकरण करते आणि यशस्वी झाल्यावर काहीही छापत नाही. त्यामुळे ते deploy करण्यापूर्वीच्या टप्प्यात किंवा git hook मध्ये वापरावे. साधे config पूर्णपणे merge आणि interpolate केलेली फाइल छापते. एखादा variable resolve झाला आहे आणि override फाइल अपेक्षेप्रमाणे लागू झाली आहे, याची खात्री करण्यासाठी ही पद्धत वापरा. unset variable तेथे रिकाम्या value प्रमाणे दिसतो आणि त्यासोबत The "X" variable is not set. Defaulting to a blank string. ही warning दिसते.

--dry-run हा subcommand flag नसून global flag आहे. त्यामुळे तो up च्या आधी द्यावा. Compose कोणती प्रत्येक action घेईल ते हा दाखवतो, पण कोणताही बदल करत नाही. महत्त्वाच्या stack वर down करण्यापूर्वी खर्च केलेली ही तीस सेकंद उपयुक्त ठरतात.

फाइल्स, profiles आणि projects वर काम करणे

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

एकापेक्षा अधिक -f flags वापरल्यास ते दिलेल्या क्रमाने एकत्र केले जातात. नंतरच्या फाइल्स आधीच्या फाइल्समधील key नुसार मूल्ये बदलतात. एका लहान production override सह एक base file ठेवण्यासाठी ही प्रमाणित पद्धत आहे. मात्र lists आणि maps साठी नियम वेगळे असतात. त्यामुळे अनपेक्षित परिणामाचे कारण शोधण्यापूर्वी Compose अनेक फाइल्स कशा एकत्र करते ते पहा.

--profile त्या profile सह tag केलेल्या services, tag नसलेल्या services सोबत सुरू करते. त्यामुळे सामान्य up मध्ये debug tooling समाविष्ट होत नाही. -p project name सेट करते. त्यामुळे एकाच stack च्या दोन प्रती स्वतंत्र networks आणि स्वतंत्र volume names सह एकाच वेळी चालवता येतात. रीबूटनंतर stack पुन्हा सुरू करणे ही तुम्ही थेट टाइप करायची command नाही. त्यासाठी तुमच्यावतीने ते एकदा चालवणारे unit वापरले जाते. त्याचे वर्णन रीबूटनंतर Compose stacks सुरू करणे येथे दिले आहे.

FAQ

हायफन असलेली docker-compose ची जागा कशाने घेतली?

स्पेससह docker compose म्हणून चालवले जाणारे Compose V2. हे Docker Engine मध्ये समाविष्ट असलेले plugin आहे. सध्याच्या packages मध्ये V1 Python tool आता install केले जात नाही. स्पेस असलेल्या स्वरूपातून कोणतेही output दिसत नसेल, तर तुमच्या distribution साठी docker-compose-plugin package install करा. Alias जोडण्याऐवजी जुन्या scripts मध्ये स्पेस असलेले स्वरूप वापरा, कारण V2 मध्ये V1 मध्ये नसलेले flags आहेत.

docker compose restart माझ्या configuration मधील बदल का घेत नाही?

restart विद्यमान container त्याच्या निर्मितीवेळी वापरलेल्या configuration सह थांबवते आणि पुन्हा सुरू करते. ते compose.yaml पुन्हा वाचत नाही. Environment variables, ports, volumes किंवा image tag मध्ये केलेल्या कोणत्याही बदलासाठी docker compose up -d आवश्यक आहे. हे प्रत्येक service ची त्याच्या चालू container शी तुलना करते आणि फरक असलेले containers पुन्हा तयार करते. File मध्ये कोणताही बदल नसतानाही replacement करायचे असल्यास --force-recreate जोडा.

Service ला नवीन image वर कसे update करायचे?

docker compose pull चालवा आणि त्यानंतर docker compose up -d चालवा. Pull केल्याने file मधील प्रत्येक tag साठी सध्याची image मिळते. up -d ज्या service ची image ID तिच्या container शी जुळत नाही, ती पुन्हा तयार करते. up -d स्वतंत्रपणे चालवल्यास disk वर आधीपासून असलेली image पुन्हा वापरली जाते. त्यामुळे latest वर pinned असलेला stack कोणतीही error न दाखवता अनेक महिन्यांपूर्वीच्या build वरच राहू शकतो.

Live server वर कोणते cleanup commands सुरक्षित आहेत?

docker system df, docker image prune -a आणि docker builder prune फक्त images आणि cache काढतात. त्यामुळे चालू services कार्यरत राहतात आणि named volumes ला धक्का लागत नाही. धोकादायक जोडी docker compose down -v आणि docker volume prune ही आहे. ती कोणतीही पुष्टी न विचारता named volumes हटवतात. कोणत्या गोष्टी धोक्यात आहेत हे समजण्यासाठी आधी docker compose config --volumes चालवा.

संपूर्ण stack सुरू न करता एक command चालवता येतो का?

होय. docker compose run --rm --no-deps web sh web service definition वरून एकच container सुरू करते, त्याच्या dependencies वगळते आणि तुम्ही बाहेर पडल्यावर container हटवते. Container आधीपासून चालू असल्यास त्याऐवजी exec वापरा, कारण exec चालू process मध्ये सामील होते आणि service प्रत्यक्षात कोणत्या स्थितीत आहे ते दाखवते.