Docker Compose कमांड्स की पूरी गाइड और चीट शीट

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

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

यहाँ सब कुछ 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 फ़ाइल से शुरुआत करें और कमांड्स के लिए यहाँ वापस आएं।

लाइफसाइकिल: वे चार कमांड जो आप टाइप करते हैं, और वह जो कंटेनरों को हटाता है

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

इमेज को अपडेट करने के लिए दो कमांड की आवश्यकता होती है क्योंकि वे दो अलग-अलग कार्य करते हैं। pull फ़ाइल में नामित प्रत्येक टैग के लिए वर्तमान इमेज को डाउनलोड करता है। up -d फिर यह देखता है कि सर्विस की इमेज ID अब उसके चल रहे कंटेनर से मेल नहीं खाती है और उसे फिर से बनाता है (recreate)। pull को छोड़ दें तो up -d पिछले महीने की latest को बिना किसी त्रुटि के चलाता रहेगा।

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

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

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 केवल चल रहे कंटेनरों की सूची दिखाता है। स्टार्टअप के दौरान क्रैश हुई सर्विस वहां तब तक दिखाई नहीं देती जब तक आप -a न जोड़ें। इसलिए, यदि कोई कंटेनर ps में नहीं दिख रहा है, जबकि ps -a उसे Exited (1) के रूप में दिखाता है, तो यह स्टार्टअप विफलता की सामान्य स्थिति है। एग्जिट कोड पढ़ें, फिर लॉग्स की जांच करें।

logs -f एक साथ सभी सर्विसेज को फॉलो करता है और प्रत्येक लाइन के आगे सर्विस का नाम जोड़ देता है। जब सर्विसेज आपस में बात करती हैं और घटनाओं का क्रम महत्वपूर्ण होता है, तो यह दृश्य सबसे उपयोगी होता है। किसी विशिष्ट सर्विस को देखने के लिए उसका नाम लिखें। --tail=100 उन कंटेनरों के लिए महत्वपूर्ण है जो एक महीने से चल रहे हैं, क्योंकि डिफ़ॉल्ट रूप से यह पूरा इतिहास प्रिंट कर देता है और टर्मिनल को भर देता है। --since 15m उस प्रश्न का उत्तर देता है जो आमतौर पर आपके मन में होता है, यानी आपके द्वारा अभी किए गए रीस्टार्ट के दौरान क्या हुआ।

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

सर्विस के अंदर शेल प्राप्त करना

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

bash से पहले sh आज़माएँ। Alpine आधारित इमेज में bash नहीं होता है, और विफलता का संदेश exec: "bash": executable file not found in $PATH दिखाई देता है। run में --no-deps जोड़ने से सर्विस की डिपेंडेंसी स्किप हो जाती है, जिससे एक त्वरित कॉन्फ़िगरेशन जांच के दौरान आपका पूरा डेटाबेस बूट नहीं होता है।

run --rm web env यह देखने का सबसे तेज़ तरीका है कि प्रत्येक .env फ़ाइल, environment: ब्लॉक और शेल वेरिएबल के मर्ज होने के बाद सर्विस को वास्तव में कौन सा एनवायरनमेंट मिला है। जब कोई मान गलत होता है, तो इसका कारण आमतौर पर मर्ज का क्रम होता है, और Compose कैसे env फ़ाइलों और सीक्रेट्स को रिज़ॉल्व करता है यह स्पष्ट करता है कि कौन सा स्रोत प्रभावी होता है।

नेटवर्क, पोर्ट और नाम रिज़ॉल्यूशन

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

Compose हर सर्विस को एक प्रोजेक्ट नेटवर्क पर रखता है, और हर सर्विस का नाम उस पर एक DNS नाम होता है। जब रिज़ॉल्यूशन काम करता है, तो web के अंदर getent hosts db चलाने पर कंटेनर का IP प्रिंट होता है, और काम न करने पर कुछ भी प्रिंट नहीं होता है। इसलिए यह दो सेकंड में जवाब देता है कि "क्या ये कंटेनर एक-दूसरे को देख सकते हैं"। यदि नाम रिज़ॉल्व हो जाता है लेकिन कनेक्शन अस्वीकार कर दिया जाता है, तो db के अंदर की प्रक्रिया 0.0.0.0 के बजाय 127.0.0.1 से बाइंड है, इसलिए यह किसी अन्य कंटेनर से पैकेट स्वीकार नहीं करती है। उस मॉडल का बाकी हिस्सा Compose नेटवर्क और सर्विस DNS कैसे काम करते हैं में है।

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

Volumes and data

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

config --volumes प्रोजेक्ट द्वारा घोषित नामित वॉल्यूम को एक-एक पंक्ति में प्रिंट करता है। आपको इसी सूची का बैकअप लेना होगा। cp किसी कंटेनर में शेल खोले बिना फ़ाइल को कॉपी करने के काम आता है, इसके लिए कंटेनर वाली साइड पर service:path प्रारूप का उपयोग करें।

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

डिस्क स्पेस खाली करने के लिए क्लीनअप, डेटा खोए बिना

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

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

docker system df दिखाता है कि कुछ भी हटाने से पहले डिस्क का उपयोग कहाँ हुआ है। यह इमेज, कंटेनर, लोकल वॉल्यूम और बिल्ड कैश को अलग-अलग करता है और प्रत्येक के लिए पुनः प्राप्त करने योग्य (reclaimable) डेटा की मात्रा बताता है। image prune -a उन सभी इमेज को हटा देता है जिनकी कोई टैग नहीं है। जिस सर्वर पर किसी बड़ी इमेज के कई वर्ज़न डाउनलोड किए गए हों, वहां आमतौर पर इससे सबसे अधिक जगह खाली होती है। 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 फ़ाइल को वैलिडेट करता है और सफल होने पर कुछ भी प्रिंट नहीं करता है, इसलिए इसे प्री-डिप्लॉय स्टेप या 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 में ऐसे फ्लैग्स हैं जो 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 केवल इमेज और कैश को हटाते हैं, इसलिए चल रही सर्विसेज काम करती रहती हैं और नेम्ड वॉल्यूम्स सुरक्षित रहते हैं। खतरनाक जोड़ी docker compose down -v और docker volume prune है, जो बिना किसी प्रॉम्प्ट के नेम्ड वॉल्यूम्स को डिलीट कर देती है। पहले docker compose config --volumes चलाएं ताकि आपको पता चल सके कि क्या जोखिम में है।

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

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