प्रत्यक्ष सर्व्हरसाठी Docker Compose commands मार्गदर्शक

तुम्ही प्रत्यक्षात वापरत असलेल्या Compose commands

Docker Compose मध्ये चाळीसपेक्षा अधिक subcommands उपलब्ध आहेत. सर्व्हरवरील दैनंदिन कामात त्यांपैकी साधारण डझनभर commands वापरले जातात. तुम्ही करत असलेल्या कामानुसार या 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 मधून चालवा. 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 created होताच ती परत येते. त्यामुळे त्यानंतर curl probe चालवणारी deploy script पहिल्या प्रयत्नात अनेकदा अपयशी ठरते. up -d --wait healthcheck घोषित केलेल्या प्रत्येक service ने healthy स्थिती कळवेपर्यंत थांबते. एखादी service कधीही त्या स्थितीत पोहोचली नाही, तर ती non-zero सह बाहेर पडते. हा flag त्यामागील check जितका विश्वसनीय असेल तितकाच उपयुक्त असतो. त्यामुळे automation मध्ये त्यावर अवलंबून राहण्यापूर्वी Compose विश्वास ठेवू शकेल असा healthcheck लिहा.

stop containers थांबवते आणि ते ठेवून देते. त्यामुळे start त्याच writable layer सह तेच containers पुन्हा सुरू करते. 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 मध्ये बदल झाला आहे तेच 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 पाहते की service चा image ID तिच्या चालू container शी जुळत नाही आणि container पुन्हा तयार करते. Pull वगळल्यास up -d मागील महिन्याची latest कोणतीही error न दाखवता चालू ठेवते. उलट धोका multi-service stack मध्ये दिसतो. अशा वेळी सर्व services साठी एकाच वेळी latest pull केल्याने दहा सेकंदांपूर्वी व्यवस्थित चालणारे app बिघडू शकते. म्हणूनच self-hosted AFFiNE workspace त्याच्या चारही image tags वेगळे pin करते. Pinning केल्यावर upgrade करण्यासाठी tag मध्ये जाणीवपूर्वक बदल करावा लागतो आणि त्यानंतर तोच pull व recreate क्रम वापरावा लागतो. Boot होताना database migration करणाऱ्या stack साठी यापैकी कोणताही command चालवण्यापूर्वी dump तयार ठेवणे आवश्यक असते. प्रत्येक version bump वेळी self-hosted Chatwoot support desk हीच पद्धत वापरते.

build हे image: ऐवजी build: section घोषित करणाऱ्या services साठी लागू होते. up -d --build build आणि start ही दोन्ही कामे एका step मध्ये करते. Code मध्ये बदल करत असताना हीच सामान्य प्रक्रिया आहे. Cached layer स्पष्टपणे stale असल्यासच --no-cache वापरा, कारण ते प्रत्येक layer सुरुवातीपासून पुन्हा build करते. काही projects एकाच cloned repo मधून दोन्ही मार्ग देतात. अशा वेळी हे दोन loops update करण्याचे पर्यायी मार्ग असतात: self-hosted openGym workout tracker त्याच्या prebuilt images वर git pull, docker compose pull आणि docker compose up -d वापरून update होते. Source मधून build करताना मात्र ते git pull नंतर docker compose up -d --build वापरते.

कार्यरत काय चालू आहे ते पाहणे

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 एकाच वेळी प्रत्येक service चा मागोवा घेते आणि प्रत्येक ओळीच्या सुरुवातीला service चे नाव देते. Services एकमेकांशी संवाद साधत असताना आणि घटनांचा क्रम महत्त्वाचा असताना हाच view उपयुक्त असतो. यादी मर्यादित करण्यासाठी 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 सोबत नेहमी --rm वापरा. अन्यथा प्रत्येक invocation नंतर stopped container शिल्लक राहतो. असे container वाढत गेल्यास docker compose ps -a वाचणे कठीण होते.

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

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

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

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

Compose प्रत्येक service ला एका project network वर ठेवते आणि प्रत्येक service name हे त्या 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 वर bind केलेला असतो. त्यामुळे तो दुसऱ्या container कडून आलेले packet स्वीकारत नाही. हाच boundary स्पष्ट करतो की project च्या बाहेर सुरू केलेला container, तो docker run ने सुरू केलेला असो किंवा स्वतंत्र stack म्हणून, jellyfin सारखे name अजिबात resolve करू शकत नाही. तुमच्या Jellyfin library साठी Halcyon front end त्याने निर्देश केलेल्या server पर्यंत पोहोचत नसेल, तर सर्वप्रथम हे तपासा. या model चा उर्वरित भाग Compose networks आणि service DNS कसे काम करतात येथे स्पष्ट केला आहे.

port web 80 container port कोणत्या host address आणि port वर publish केला आहे ते दाखवते. Mapping एखाद्या variable मधून आले असल्यास अंदाज बांधण्याची गरज राहत नाही. Port publish केल्यावर Docker स्वतः व्यवस्थापित करणारा firewall rule लिहिते. हा rule तुमच्या rules च्या आधी लागू होतो. त्यामुळे private आहे असे तुम्हाला वाटणारे service इंटरनेटसाठी खुले होऊ शकते. हा प्रकार published Docker ports ufw ला bypass का करतात येथे स्पष्ट केला आहे. हे ports unpublished ठेवणे आणि त्याऐवजी project network वर services च्या पुढे authentication करणारा एक proxy ठेवणे अधिक सुरक्षित रचना आहे. Authentik ला single sign-on layer म्हणून चालवणे याच प्रकारची रचना देते.

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

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 घ्यायचा असतो. व्हॉल्यूममध्ये पुन्हा मिळवता न येणारा डेटा असल्यास, अचूक backup command यादीइतकीच महत्त्वाची असते. म्हणूनच PhotoPrism आणि Immich ची तुलना प्रत्येक photo server साठी आवश्यक dump आणि copy commands स्पष्ट करते. cp shell न उघडता container मध्ये किंवा container मधून file copy करते. यासाठी container ज्या बाजूला आहे त्या बाजूला service:path form वापरला जातो.

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

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

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

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

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

यापैकी कोणतीही कमांड named volume ला स्पर्श करत नाही. फक्त docker volume prune --all आणि docker compose down -v named volumes वर परिणाम करतात. साधी docker volume prune anonymous volumes हटवते.

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

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

config --quiet यशस्वी झाल्यावर काहीही छापत नाही; त्यामुळे ते pre-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 करण्यापूर्वी खर्च केलेली ही तीस सेकंद उपयुक्त ठरतात.

फाइल्स, प्रोफाइल्स आणि प्रोजेक्ट्समध्ये काम करणे

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 क्रमाने merge होतात आणि नंतरच्या फाइल्स आधीच्या फाइल्समधील key नुसार मूल्ये override करतात. एक base file आणि त्यावर production साठी लहान override file ठेवण्याची ही standard पद्धत आहे. मात्र lists आणि maps साठीचे नियम वेगळे असतात. त्यामुळे अनपेक्षित परिणामाचे debugging करण्यापूर्वी Compose अनेक फाइल्स merge कसे करते ते पहा.

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

FAQ

docker-compose च्या जागी hyphen असलेले काय आले?

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

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

restart विद्यमान container थांबवून, तो ज्या configuration सह तयार केला होता त्याच 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 चालवा. File मधील प्रत्येक tag साठी pull सध्याची 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 ला धक्का लागत नाही. धोकादायक commands ची जोडी docker compose down -v आणि docker volume prune --all ही आहे. docker compose down -v project चे named volumes कोणतीही prompt न दाखवता delete करते. docker volume prune --all एकाच y/N prompt नंतर, किंवा -f दिल्यास कोणताही prompt न दाखवता, कोणताही container वापरत नसलेले प्रत्येक named volume delete करते. काय धोक्यात आहे हे समजण्यासाठी प्रथम docker compose config --volumes चालवा.

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

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