Docker Compose commands: सर्वर मैनेजमेंट के लिए गाइड

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

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

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

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

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 file में दिए गए प्रत्येक tag की current image download करता है। इसके बाद up -d देखता है कि service की image ID उसके running container से match नहीं करती और उसे recreate करता है। Pull छोड़ देने पर up -d पिछले महीने के latest को बिना किसी error के running रखता है। इसका उलटा जोखिम multi-service stack में दिखता है, जहाँ सभी services के लिए एक साथ latest pull करने से वह app टूट सकता है जो दस seconds पहले तक सही चल रहा था। इसी कारण self-hosted AFFiNE workspace अपने चारों image tags को अलग-अलग pin करता है। Pinning से upgrade एक जानबूझकर किए गए tag edit में बदल जाता है। इसके बाद वही pull और recreate commands चलानी होती हैं। जिस stack में boot के दौरान database migrate होता है, उसमें दोनों commands चलाने से पहले dump तैयार रखना चाहिए। यही routine self-hosted Chatwoot support desk हर version bump के लिए अपनाता है।

build उन services पर लागू होता है जो image: के बजाय build: section घोषित करती हैं। up -d --build एक ही चरण में build और start करता है, जो code बदलते समय सामान्य loop है। --no-cache का उपयोग केवल तब करें जब cached layer स्पष्ट रूप से पुरानी हो, क्योंकि यह हर layer को शुरू से rebuild करता है। जब किसी stack को registry image के बजाय checked out git tag से deploy किया जाता है, तो वही build loop उसका update path भी होता है, और इसी तरह एक self-hosted openGym workout tracker एक pinned version से दूसरे पर जाता है।

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

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 रूप से यह पूरा इतिहास print कर देता है और terminal भर जाता है। --since 15m आपके उस सवाल का जवाब देता है जो आमतौर पर मन में होता है: अभी किए गए restart के दौरान क्या हुआ।

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

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

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 सभी services को एक project network पर रखता है, और प्रत्येक service का नाम उस network में DNS name होता है। जब resolution काम करता है, तो web के अंदर getent hosts db चलाने पर container IP छपता है। Resolution काम न करने पर कुछ भी नहीं छपता। इसलिए दो seconds में पता चल जाता है कि “क्या ये containers एक-दूसरे को देख सकते हैं।” यदि name resolve हो जाता है, लेकिन connection refused मिले, तो db के अंदर process 0.0.0.0 के बजाय 127.0.0.1 पर bound है। इसलिए वह किसी दूसरे container से आने वाला packet स्वीकार नहीं करता। यही सीमा बताती है कि project के बाहर शुरू किया गया container, चाहे docker run से शुरू किया गया हो या अपने अलग stack के रूप में, jellyfin जैसे name को बिल्कुल resolve नहीं कर सकता। जब आपका Jellyfin library के लिए Halcyon front end उस server तक नहीं पहुँच पाता जिसे वह target करता है, तो सबसे पहले यही जाँच करें। इस model का बाकी विवरण Compose networks और service DNS कैसे काम करते हैं में दिया गया है।

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

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 को प्रति पंक्ति एक के अनुसार प्रिंट करता है। आपको इसी सूची का बैकअप लेना होता है। जब volumes में कुछ ऐसा डेटा हो जिसे दोबारा प्राप्त नहीं किया जा सकता, तो सटीक बैकअप कमांड उतना ही महत्वपूर्ण हो जाता है जितनी कि सूची। यही कारण है कि PhotoPrism और Immich की तुलना में प्रत्येक फोटो सर्वर के लिए आवश्यक dump और copy कमांड का विस्तार से वर्णन किया गया है। 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 को हटा देता है जो project का हिस्सा तो हैं लेकिन अब file में दिखाई नहीं देते, जो कि किसी service का नाम बदलने के बाद होने वाली सामान्य स्थिति है। इसके बिना वे containers चलते रहते हैं और docker compose ps को दिखाई नहीं देते।

docker system df यह दिखाता है कि कुछ भी हटाने से पहले डिस्क का उपयोग कहाँ हुआ है, जो images, containers, local volumes और build cache को अलग-अलग करके दिखाता है और प्रत्येक के लिए पुनः प्राप्त करने योग्य (reclaimable) जगह बताता है। image prune -a उन सभी images को हटा देता है जिनकी कोई tag नहीं है, और जिस सर्वर पर किसी बड़ी image के कई version download किए गए हों, वहाँ आमतौर पर इससे सबसे अधिक जगह खाली होती है। builder prune build cache को साफ करता है, जो उन सभी servers पर धीरे-धीरे बढ़ता है जहाँ अपनी 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 पूरी तरह से मर्ज और इंटरपोलेट की गई फाइल को प्रिंट करता है, जिससे आप यह पुष्टि कर सकते हैं कि कोई variable सही ढंग से resolve हुआ है और override फाइल आपकी अपेक्षा के अनुसार लागू हुई है। यदि कोई variable unset है, तो वह वहां खाली मान के रूप में दिखाई देगा, जिसके साथ The "X" variable is not set. Defaulting to a blank string. चेतावनी भी होगी।

--dry-run एक global flag है, न कि subcommand flag, इसलिए इसे up से पहले रखा जाता है। यह उन सभी क्रियाओं को प्रिंट करता है जो Compose करेगा और किसी भी चीज में बदलाव नहीं करता है। किसी महत्वपूर्ण stack पर down चलाने से पहले इसमें बिताए गए 30 सेकंड का समय सार्थक होता है।

फाइलों, प्रोफाइलों और प्रोजेक्ट्स के साथ काम करना

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 लाइव प्रोसेस से जुड़ जाता है और आपको वह स्टेट दिखाता है जिसमें सर्विस वास्तव में है।