Docker Compose कमांड्स का उपयोग कैसे करें: पूरी गाइड

Compose commands जिनका आप वास्तव में उपयोग करते हैं

Docker Compose में चालीस से अधिक subcommands होते हैं। सर्वर पर दैनिक कार्य के लिए लगभग एक दर्जन का ही उपयोग होता है। यह पृष्ठ उन्हें आपके द्वारा किए जा रहे कार्य के आधार पर वर्गीकृत करता है, प्रत्येक के लिए एक स्पष्ट कारण बताता है, और जब कोई कमांड किसी समस्या का कारण बनती है तो विस्तृत जानकारी की ओर संकेत करता है।

यहाँ सब कुछ Compose V2 का उपयोग करता है: docker compose एक स्पेस के साथ, न कि पुराने docker-compose स्क्रिप्ट का। V2 एक Go प्लगइन है जो Docker Engine के साथ इंस्टॉल होता है, और V1 वर्तमान पैकेज से हटा दिया गया है, इसलिए जुलाई 2026 तक एक नए Ubuntu बॉक्स पर docker-compose: command not found का चलना अपेक्षित है, न कि त्रुटिपूर्ण। docker compose version के साथ जाँच करें। यदि यह कुछ भी प्रिंट नहीं करता है, तो docker-compose-plugin पैकेज इंस्टॉल करें।

नीचे दी गई प्रत्येक कमांड उस डायरेक्टरी से चलती है जिसमें आपकी compose.yaml फाइल होती है, क्योंकि Compose उस डायरेक्टरी से प्रोजेक्ट का नाम लेता है और फाइल को उसके सापेक्ष ढूंढता है। यदि आप एक स्तर ऊपर जाकर वही कमांड चलाते हैं, तो Compose no configuration file provided: not found के साथ रुक जाता है। यदि फाइल फॉर्मेट आपके लिए नया है, तो VPS पर पहली Compose फाइल से शुरुआत करें और कमांड्स के लिए यहाँ वापस आएँ।

Lifecycle: चार कमांड जो आप टाइप करते हैं, और एक जो कंटेनर्स को हटाता है

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 तब तक ब्लॉक रहता है जब तक कि हेल्थचेक घोषित करने वाली प्रत्येक सर्विस 'हेल्दी' रिपोर्ट न कर दे, और यदि कोई सर्विस वहां तक नहीं पहुंचती है तो यह नॉन-जीरो एग्जिट कोड देता है। यह फ्लैग केवल उसके पीछे के चेक जितना ही प्रभावी है, इसलिए ऑटोमेशन में इसका उपयोग करने से पहले ऐसा हेल्थचेक लिखें जिस पर Compose भरोसा कर सके।

stop कंटेनर्स को रोक देता है और उन्हें बनाए रखता है, इसलिए start उन्हीं कंटेनर्स को उसी राइटेबल लेयर के साथ वापस लाता है। down उन्हें रोकता है और फिर कंटेनर्स और प्रोजेक्ट नेटवर्क को हटा देता है। कंटेनर के अंदर और वॉल्यूम के बाहर लिखा गया कोई भी डेटा उनके साथ ही चला जाता है। यह Compose में सबसे महंगी गलतफहमी है, और down और stop के बीच का पूरा अंतर बताता है कि यह समस्या कहां आती है।

restart रीलोड नहीं है। यह उसी कंटेनर को उसी कॉन्फ़िगरेशन के साथ रोकता और स्टार्ट करता है जो उसके पास पहले से है, इसलिए बदले हुए एनवायरनमेंट वेरिएबल, नए इमेज टैग या एडिट किए गए पोर्ट मैपिंग का कोई प्रभाव नहीं पड़ता है। फ़ाइल में बदलाव लागू करने के लिए आप फिर से up -d रन करते हैं। Compose प्रत्येक सर्विस की तुलना उसके चल रहे कंटेनर से करता है और केवल उन्हीं को फिर से बनाता है जिनकी कॉन्फ़िगरेशन बदल गई है।

बदलाव लागू करना: recreate, 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 उस तुलना को अनदेखा कर देता है और हर container को बदल देता है, भले ही configuration समान हो, इसलिए container के भीतर की अजीब स्थिति को साफ करने का यह सबसे तेज़ तरीका है।

Image को update करने के लिए दो commands की आवश्यकता होती है क्योंकि वे दो अलग-अलग काम करती हैं। pull फाइल में नामित प्रत्येक tag के लिए वर्तमान image को download करता है। इसके बाद up -d यह देखता है कि service की image ID अब चल रहे container से मेल नहीं खाती है और उसे recreate कर देता है। यदि आप pull को छोड़ देते हैं, तो up -d बिना किसी error के पिछले महीने की latest को ही चलाता रहेगा।

build उन services पर लागू होता है जो image: के बजाय build: section घोषित करती हैं। up -d --build एक ही चरण में build और start करता है, जो code बदलते समय सामान्य loop है। --no-cache का उपयोग केवल तब करें जब cached layer स्पष्ट रूप से पुरानी हो जाए, क्योंकि यह हर layer को शुरू से rebuild करता है।

चल रही प्रक्रियाओं को देखना

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 की सूची दिखाता है। जो service start होते समय crash हो गई, वह तब तक दिखाई नहीं देगी जब तक आप -a न जोड़ें। इसलिए, यदि कोई container ps में नहीं दिख रहा है, जबकि ps -a उसे Exited (1) के रूप में दिखा रहा है, तो यह startup failure का सामान्य लक्षण है। exit code पढ़ें, फिर logs देखें।

logs -f एक साथ सभी services को follow करता है और हर line के आगे service का नाम जोड़ता है। जब services आपस में बात कर रही हों और घटनाओं का क्रम महत्वपूर्ण हो, तो यह view सबसे उपयोगी होता है। किसी विशिष्ट service को देखने के लिए उसका नाम लिखें। --tail=100 उन containers के लिए महत्वपूर्ण है जो एक महीने से चल रहे हैं, क्योंकि default रूप से यह पूरा history print कर देता है और terminal भर जाता है। --since 15m उस सवाल का जवाब देता है जो आमतौर पर आपके मन में होता है, यानी अभी किए गए restart के दौरान क्या हुआ।

top हर container के अंदर चल रही processes की सूची दिखाता है। यह "container चल रहा है" और "उसके अंदर की process चल रही है" के बीच का अंतर स्पष्ट करता है। ls वर्तमान directory से बाहर निकलकर host पर मौजूद हर Compose project और उसकी स्थिति को दिखाता है, ताकि आप उस stack को ढूंढ सकें जिसे आपने तीन महीने पहले शुरू किया था।

किसी service के अंदर 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 शुरू करता है, जिसकी आवश्यकता तब होती है जब service इतनी देर तक नहीं चलती कि आप उसमें exec कर सकें। run को हमेशा --rm के साथ उपयोग करें, क्योंकि इसके बिना हर invocation एक stopped container पीछे छोड़ देता है, और वे तब तक जमा होते रहते हैं जब तक docker compose ps -a अपठनीय न हो जाए।

bash से पहले sh आज़माएँ। Alpine आधारित images में bash नहीं होता है, और failure का संदेश exec: "bash": executable file not found in $PATH दिखाई देता है। run में --no-deps जोड़ने से service की dependencies skip हो जाती हैं, जिससे एक त्वरित config check के कारण आपका पूरा database boot नहीं होता है।

run --rm web env यह देखने का सबसे तेज़ तरीका है कि हर .env file, environment: block और shell variable के merge होने के बाद service को वास्तव में क्या environment मिला। जब कोई 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 हर सर्विस को एक प्रोजेक्ट नेटवर्क पर रखता है, और प्रत्येक सर्विस का नाम उस पर एक DNS नाम होता है। web के अंदर getent hosts db चलाने पर रिज़ॉल्यूशन काम करने पर कंटेनर IP प्रिंट होता है और काम न करने पर कुछ भी प्रिंट नहीं होता, इसलिए यह दो सेकंड में जवाब देता है कि "क्या ये कंटेनर एक-दूसरे को देख सकते हैं"। यदि नाम रिज़ॉल्व हो जाता है लेकिन कनेक्शन रिफ्यूज (refused) हो जाता है, तो db के अंदर की प्रक्रिया 0.0.0.0 के बजाय 127.0.0.1 पर बाउंड (bound) है, इसलिए यह किसी अन्य कंटेनर से पैकेट स्वीकार नहीं करती है। उस मॉडल का बाकी हिस्सा Compose नेटवर्क और सर्विस DNS कैसे काम करते हैं में है।

port web 80 उस होस्ट एड्रेस और पोर्ट को प्रिंट करता है जिस पर कंटेनर पोर्ट पब्लिश किया गया है, जिससे मैपिंग किसी वेरिएबल से आने पर अनुमान लगाने की जरूरत नहीं पड़ती। पोर्ट पब्लिश करने से एक फायरवॉल रूल भी लिखा जाता है जिसे Docker खुद मैनेज करता है, और वह रूल आपके रूल से पहले होता है, इसलिए जिसे आप प्राइवेट समझते थे वह सर्विस इंटरनेट के लिए खुली हो सकती है। वह मामला पब्लिश किए गए Docker पोर्ट ufw को बायपास क्यों करते हैं में कवर किया गया है।

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 को प्रति लाइन एक के हिसाब से प्रिंट करता है। आपको इसी सूची का बैकअप लेना होता है। cp कमांड शेल खोले बिना किसी फाइल को कंटेनर के अंदर या बाहर कॉपी करता है, इसके लिए जिस तरफ कंटेनर हो वहां service:path फॉर्मेट का उपयोग किया जाता है।

down -v कमांड कंटेनरों के साथ-साथ उन named volumes को भी हटा देता है। टेस्ट स्टैक को हटाने के लिए यह सही कमांड है, लेकिन जिस डेटा की आपको आवश्यकता है उसके लिए यह गलत है, क्योंकि इसमें कोई पुष्टि (confirmation) नहीं मांगी जाती और इसे अनडू (undo) नहीं किया जा सकता। Bind mounts इससे सुरक्षित रहते हैं, क्योंकि वे होस्ट फाइलसिस्टम पर स्थित होते हैं। ब्लास्ट रेडियस में यह अंतर bind mounts और named volumes के बीच सोच-समझकर चुनाव करने का एक कारण है।

डेटा खोए बिना डिस्क खाली करने के लिए सफाई

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

--remove-orphans उन containers को हटा देता है जो प्रोजेक्ट का हिस्सा तो हैं लेकिन अब फाइल में दिखाई नहीं देते। ऐसा तब होता है जब आप किसी service का नाम बदलते हैं। इसके बिना, वे containers चलते रहते हैं और docker compose ps को दिखाई नहीं देते।

docker system df यह दिखाता है कि कुछ भी हटाने से पहले डिस्क का उपयोग कहाँ हुआ है। यह images, containers, local volumes और build cache को अलग-अलग करके दिखाता है और प्रत्येक के लिए पुनः प्राप्त करने योग्य (reclaimable) जगह की जानकारी देता है। image prune -a उन सभी images को हटा देता है जिनसे कोई tag नहीं जुड़ा है। जिस सर्वर पर किसी बड़ी image के कई versions download किए गए हों, वहां यह सबसे अधिक जगह खाली करता है। builder prune build cache को साफ करता है, जो किसी भी ऐसे सर्वर पर धीरे-धीरे बढ़ता रहता है जहाँ अपनी images खुद build की जाती हैं।

इनमें से कोई भी 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 पूरी तरह से मर्ज और इंटरपोलेट की गई फाइल को प्रिंट करता है, जिससे आप यह पुष्टि कर सकते हैं कि वेरिएबल सही ढंग से रिज़ॉल्व हुआ है और ओवरराइड फाइल आपकी अपेक्षा के अनुसार लेयर हुई है। यदि कोई वेरिएबल सेट नहीं है, तो वह चेतावनी The "X" variable is not set. Defaulting to a blank string. के साथ एक खाली मान के रूप में दिखाई देगा।

--dry-run एक सब-कमांड फ्लैग के बजाय एक ग्लोबल फ्लैग है, इसलिए यह up से पहले आता है। यह उन सभी क्रियाओं को प्रिंट करता है जो Compose करेगा और किसी भी चीज़ में बदलाव नहीं करता है। किसी महत्वपूर्ण स्टैक पर 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 फ्लैग्स क्रम में मर्ज होते हैं, और बाद वाली फाइलें पहले वाली फाइलों को की-दर-की (key by key) ओवरराइड करती हैं। एक बेस फाइल के साथ छोटा प्रोडक्शन ओवरराइड रखने का यह मानक तरीका है, हालांकि लिस्ट और मैप्स के लिए नियम अलग होते हैं, इसलिए किसी भी अप्रत्याशित व्यवहार को डीबग करने से पहले Compose कई फाइलों को कैसे मर्ज करता है पढ़ें।

--profile उस प्रोफाइल के साथ टैग की गई सर्विसेज को बिना टैग वाली सर्विसेज के साथ स्टार्ट करता है, जिससे डीबग टूलिंग सामान्य up से बाहर रहती है। -p प्रोजेक्ट का नाम सेट करता है, ताकि एक ही स्टैक की दो कॉपियां अलग-अलग नेटवर्क्स और अलग-अलग वॉल्यूम नामों के साथ एक साथ चल सकें। रीबूट के बाद स्टैक को वापस लाना कोई ऐसी कमांड नहीं है जिसे आप टाइप करते हैं, यह एक यूनिट है जो आपके लिए इसे रन करती है, जिसका विवरण बूट पर Compose स्टैक को स्टार्ट करना में दिया गया है।

FAQ

हाइफ़न वाले docker-compose की जगह क्या आया है?

Compose V2, जिसे docker compose के रूप में स्पेस के साथ चलाया जाता है। यह Docker Engine के साथ बंडल किया गया एक प्लगइन है, और V1 Python टूल अब वर्तमान पैकेजों में इंस्टॉल नहीं होता है। यदि स्पेस वाला कमांड कुछ भी आउटपुट नहीं देता है, तो अपने डिस्ट्रिब्यूशन के लिए docker-compose-plugin पैकेज इंस्टॉल करें। पुराने स्क्रिप्ट्स को स्पेस वाले फॉर्मेट में अपडेट करें, न कि कोई alias जोड़ें, क्योंकि V2 में ऐसे कई flags हैं जो V1 में नहीं थे।

docker compose restart मेरे कॉन्फ़िगरेशन बदलाव को क्यों नहीं उठाता?

restart मौजूदा कंटेनर को उसी कॉन्फ़िगरेशन के साथ रोकता और शुरू करता है जिसके साथ उसे बनाया गया था, और यह कभी भी compose.yaml को दोबारा नहीं पढ़ता है। एनवायरनमेंट वेरिएबल्स, पोर्ट्स, वॉल्यूम्स या इमेज टैग में किसी भी बदलाव के लिए docker compose up -d की आवश्यकता होती है, जो प्रत्येक सर्विस की तुलना उसके चल रहे कंटेनर से करता है और अंतर होने पर उन्हें फिर से बनाता है। यदि आप चाहते हैं कि फाइल में कोई बदलाव न होने पर भी रिप्लेसमेंट हो, तो --force-recreate जोड़ें।

मैं किसी सर्विस को नई इमेज पर कैसे अपडेट करूँ?

docker compose pull चलाएं, फिर docker compose up -d चलाएं। pull कमांड फाइल में दिए गए प्रत्येक टैग के लिए वर्तमान इमेज को फेच करता है, और up -d उन सभी सर्विसेज को फिर से बनाता है जिनकी इमेज ID अब उनके कंटेनर से मेल नहीं खाती है। केवल up -d चलाने पर डिस्क पर मौजूद पुरानी इमेज का ही उपयोग होता है, यही कारण है कि latest पर पिन किया गया स्टैक बिना किसी एरर के महीनों पुराने बिल्ड पर चलता रहता है।

लाइव सर्वर पर कौन से क्लीनअप कमांड सुरक्षित हैं?

docker system df, docker image prune -a और docker builder prune केवल इमेज और कैश को हटाते हैं, इसलिए चल रही सर्विसेज काम करती रहती हैं और named volumes सुरक्षित रहते हैं। खतरनाक कमांड docker compose down -v और docker volume prune हैं, जो बिना किसी प्रॉम्प्ट के named volumes को डिलीट कर देते हैं। पहले docker compose config --volumes चलाएं ताकि आपको पता रहे कि क्या जोखिम में है।

क्या मैं पूरे स्टैक को शुरू किए बिना एक कमांड चला सकता हूँ?

हाँ। docker compose run --rm --no-deps web sh, web सर्विस परिभाषा से एक सिंगल कंटेनर शुरू करता है, इसकी डिपेंडेंसीज को छोड़ देता है, और बाहर निकलने पर कंटेनर को हटा देता है। जब कंटेनर पहले से चल रहा हो तो इसके बजाय exec का उपयोग करें, क्योंकि exec लाइव प्रोसेस से जुड़ता है और आपको वह स्थिति दिखाता है जिसमें सर्विस वास्तव में है।