प्रत्यक्ष सर्व्हरसाठी 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 पटकन साफ करण्यासाठी हा सर्वात जलद मार्ग आहे.

इमेज अपडेट करण्यासाठी दोन commands आवश्यक असतात, कारण त्या दोन वेगवेगळी कामे करतात. pull फाइलमध्ये नमूद केलेल्या प्रत्येक tag साठी सध्याची image डाउनलोड करते. त्यानंतर up -d सेवा वापरत असलेल्या image ID ची तिच्या चालू container शी जुळवणी होत नाही हे ओळखते आणि container पुन्हा तयार करते. pull टाळल्यास up -d मागील महिन्याची latest कोणतीही error न देता चालू ठेवते. याउलट, अनेक सेवांच्या stack मध्ये एकाच वेळी प्रत्येक सेवेसाठी latest pull केल्यास दहा सेकंदांपूर्वी व्यवस्थित चालणारे अॅप बंद पडू शकते. म्हणूनच self-hosted AFFiNE workspace त्याऐवजी त्याच्या चारही image tags pin करते. Pinning केल्यामुळे upgrade म्हणजे tag मध्ये जाणीवपूर्वक केलेला बदल, त्यानंतर तोच pull आणि recreate असा नियंत्रित क्रम बनतो. Boot होताना database migration करणाऱ्या stack साठी दोन्ही commands चालवण्यापूर्वी dump तयार ठेवणे आवश्यक असते. प्रत्येक version bump साठी self-hosted Chatwoot support desk हीच पद्धत वापरते.

build हे image: ऐवजी build: section जाहीर करणाऱ्या services साठी लागू होते. up -d --build एका चरणात build आणि start करते. Code बदलत असताना हीच सामान्य प्रक्रिया असते. Cached layer स्पष्टपणे stale असेल तेव्हाच --no-cache वापरा, कारण ते प्रत्येक layer सुरुवातीपासून पुन्हा 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 कसे सोडवते येथे स्पष्ट केले आहे.

नेटवर्क, पोर्ट आणि 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 यशस्वी झाल्यास web मध्ये getent hosts db चालवल्यावर container IP दिसतो. Resolution अयशस्वी झाल्यास काहीही दिसत नाही. त्यामुळे “हे containers एकमेकांपर्यंत पोहोचू शकतात का?” याचे उत्तर दोन सेकंदांत मिळते. Name resolve होत असेल, पण connection refused येत असेल, तर db मधील process 0.0.0.0 ऐवजी 127.0.0.1 वर bound आहे. त्यामुळे तो दुसऱ्या container कडून आलेले packet कधीही स्वीकारत नाही. हाच boundary स्पष्ट करतो की project च्या बाहेर सुरू केलेला container, तो docker run ने सुरू केला असो किंवा स्वतःच्या stack म्हणून, jellyfin सारखे name अजिबात resolve करू शकत नाही. तुमच्या Jellyfin library साठी Halcyon front end ज्या server शी जोडण्याचा प्रयत्न करते तो server उपलब्ध नसल्यास, सर्वप्रथम हेच तपासा. या model चे उर्वरित स्पष्टीकरण 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 करतात येथे स्पष्ट केली आहे. हे ports unpublished ठेवणे आणि services च्या पुढे project network वर 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 तयार होतात. हे न केल्यास ते containers सुरूच राहतात आणि docker compose ps मध्ये दिसत नाहीत.

काहीही हटवण्यापूर्वी डिस्कची जागा कुठे वापरली गेली आहे हे docker system df दाखवते. ते images, containers, local volumes आणि build cache यांचे स्वतंत्र विभाजन दाखवते आणि प्रत्येकासाठी reclaimable जागाही दर्शवते. कोणत्याही tag कडून संदर्भित नसलेली प्रत्येक image image prune -a हटवते. मोठ्या image च्या अनेक आवृत्त्या डाउनलोड केलेल्या सर्व्हरवर यामुळे सहसा सर्वाधिक जागा मोकळी होते. स्वतःच्या images तयार करणाऱ्या कोणत्याही सर्व्हरवर हळूहळू वाढणारा build cache 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 पूर्णपणे 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 ची जागा कशाने घेतली?

स्पेससह `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 शी तुलना करते आणि फरक असलेल्या services पुन्हा तयार करते. File मध्ये कोणताही बदल नसतानाही replacement करायचे असल्यास --force-recreate` जोडा.

Service नवीन image वर कशी update करावी?

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

चालू 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 प्रत्यक्षात कोणत्या स्थितीत आहे ते दाखवते.