Docker Compose: सर्व्हरसाठी आवश्यक कमांड्स

प्रत्यक्षात वापरायच्या Compose कमांड

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

येथे सर्वत्र 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 एक directory वरून चालवल्यास Compose no configuration file provided: not found दाखवून थांबते. File format तुमच्यासाठी नवीन असल्यास, VPS वरील पहिल्या Compose file पासून सुरुवात करा आणि नंतर कमांडसाठी येथे परत या.

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 पहिल्या प्रयत्नात अनेकदा अयशस्वी होते. प्रत्येक healthcheck असलेली service healthy असल्याचे कळेपर्यंत up -d --wait थांबते. एखादी service कधीही healthy झाली नाही, तर ती non-zero status सह बाहेर पडते. हा flag त्यामागील check जितका विश्वासार्ह असेल तितकाच उपयुक्त असतो. त्यामुळे automation मध्ये त्यावर अवलंबून राहण्यापूर्वी Compose विश्वासाने वापरू शकेल असा healthcheck लिहा.

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

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

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

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 मधील असामान्य स्थिती दूर करण्याचा हा सर्वात जलद मार्ग आहे.

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

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

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

top प्रत्येक container मधील processes दाखवते. यामुळे "container चालू आहे" आणि "त्यातील process चालू आहे" यांतील फरक स्पष्ट होतो. ls सध्याच्या directory च्या बाहेर जाऊन host वरील प्रत्येक Compose project त्याच्या status सह दाखवते. त्यामुळे तीन महिन्यांपूर्वी सुरू केलेला 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 असा failure message दिसतो. run मध्ये --no-deps जोडल्यास service च्या dependencies वगळल्या जातात. त्यामुळे साधी config तपासणी करताना संपूर्ण database सुरू होत नाही.

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

नेटवर्क, पोर्ट आणि नावाचे निराकरण

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 एकमेकांशी संपर्क करू शकतात का" या प्रश्नाचे उत्तर दोन सेकंदांत मिळते. नावाचे resolution होते, पण connection नाकारले जाते, तर db मधील process 0.0.0.0 ऐवजी 127.0.0.1 वर bound असतो. त्यामुळे तो दुसऱ्या container कडून आलेले packet कधीही स्वीकारत नाही. या model चा उर्वरित भाग Compose networks आणि service DNS कसे कार्य करतात येथे दिला आहे.

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

Volumes आणि डेटा

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

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

down -v containers सोबत ते named volumes देखील काढून टाकते. test stack हटवण्यासाठी ही योग्य command आहे. मात्र, ज्या डेटाची तुम्हाला आवश्यकता आहे अशा कोणत्याही गोष्टीसाठी ती चुकीची command आहे, कारण कोणतीही पुष्टी मागितली जात नाही आणि 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 वेगळे दाखवते आणि प्रत्येकासाठी पुन्हा मिळवता येणारी जागा दर्शवते. कोणत्याही tag ने संदर्भित न केलेली प्रत्येक image image prune -a हटवते. मोठ्या image च्या अनेक versions डाउनलोड केलेल्या server वर यामुळे सामान्यतः सर्वाधिक जागा मोकळी होते. स्वतःच्या images build करणाऱ्या कोणत्याही server वर हळूहळू वाढणारा 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 यशस्वी झाल्यावर कोणतेही आउटपुट देत नाही. त्यामुळे ते डिप्लॉय करण्यापूर्वीच्या टप्प्यात किंवा git hook मध्ये वापरावे. साधे config पूर्णपणे मर्ज केलेली आणि इंटरपोलेट केलेली फाइल दाखवते. चलाचे मूल्य योग्यरीत्या ठरले आहे आणि override फाइल अपेक्षेप्रमाणे लागू झाली आहे, याची खात्री करण्याचा हा मार्ग आहे. सेट न केलेले चल तेथे रिकामे दिसते आणि The "X" variable is not set. Defaulting to a blank string. ही चेतावणीही दिसते.

--dry-run हा subcommand flag नसून global flag आहे. त्यामुळे तो up च्या आधी लिहावा. Compose कोणतीही कृती करेल ती प्रत्येक कृती तो दाखवतो आणि काहीही बदलत नाही. महत्त्वाच्या 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 फ्लॅग क्रमाने विलीन होतात. नंतरच्या फाइल्स आधीच्या फाइल्समधील मूल्ये कीनुसार अधिलिखित करतात. एका लहान production override सह एक base फाइल ठेवण्याची ही प्रमाणित पद्धत आहे. मात्र lists आणि maps साठी नियम वेगळे आहेत. त्यामुळे अनपेक्षित परिणामाचे debugging करण्यापूर्वी Compose अनेक फाइल्स कसे विलीन करते हे वाचा.

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

FAQ

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

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