Docker Compose में stop और down में अंतर

संक्षिप्त उत्तर

docker compose stop कंटेनर को रोकता है और उन्हें डिस्क पर रखता है। docker compose down कंटेनर को रोकता है, फिर कंटेनर और प्रोजेक्ट के लिए Compose द्वारा बनाए गए नेटवर्क को हटा देता है। इनमें से कोई भी कमांड named volume को प्रभावित नहीं करता। आपका डेटाबेस तभी हटता है जब आप -v जोड़ते हैं, जैसा कि docker compose down -v में है। यह Compose फ़ाइल के volumes सेक्शन में घोषित named volumes को हटा देता है।

यही पूरे अंतर का सार एक पैराग्राफ में है। इस गाइड के बाकी हिस्से में Postgres volume के उदाहरण से दिखाया गया है कि वह down के बाद सुरक्षित रहता है और down -v के दौरान हट जाता है। इसमें उन दो स्थितियों की भी व्याख्या की गई है, जिनमें आपको --force-recreate की आवश्यकता होती है।

docker compose stop: कंटेनर चलते रहते हैं

stop प्रत्येक कंटेनर की मुख्य प्रक्रिया को SIGTERM भेजता है, प्रतीक्षा करता है, फिर प्रक्रिया के अभी भी सक्रिय रहने पर SIGKILL भेजता है। डिफ़ॉल्ट प्रतीक्षा अवधि 10 सेकंड है और -t इसे बदलता है। कुछ भी हटाया नहीं जाता। कंटेनर अपनी ID, अपनी writable layer, अपना IP reservation और अपने logs बनाए रखता है।

docker compose stop
docker compose ps -a

docker compose ps अपने आप केवल चल रहे कंटेनर दिखाता है। इसलिए stop के बाद यह एक खाली तालिका दिखाता है और लोगों को लगता है कि कंटेनर हट गए हैं। ps -a रुके हुए कंटेनर भी शामिल करता है। वहीं आपको प्रत्येक service के आगे Exited (0) दिखाई देगा। उन्हें docker compose start से फिर शुरू करें। यह ठीक उन्हीं कंटेनरों का फिर से उपयोग करता है।

कंटेनर अभी भी मौजूद हैं, इसलिए volume के बाहर उनमें लिखी गई कोई भी सामग्री वहीं रहती है। इसमें docker compose exec से हाथ से install किया गया package और कंटेनर के अंदर edit की गई config file भी शामिल है। Debugging के दौरान stop को प्राथमिकता देने का यही व्यावहारिक कारण है: आप उसी स्थिति में फिर से शुरू कर सकते हैं।

docker compose down: कंटेनर और नेटवर्क हटा दिए जाते हैं

down कंटेनर को रोकता है और फिर उन्हें हटाता है। इसके साथ, प्रोजेक्ट के लिए Compose द्वारा बनाए गए डिफ़ॉल्ट नेटवर्क को भी हटा दिया जाता है। Docker documentation इसे कंटेनर रोकने तथा up द्वारा बनाए गए कंटेनर, नेटवर्क, वॉल्यूम और इमेज हटाने के रूप में वर्णित करती है। लेकिन वॉल्यूम और इमेज तभी हटते हैं, जब आप -v और --rmi के साथ ऐसा करने का अनुरोध करते हैं।

docker compose down
docker compose ps -a
docker network ls

down के बाद, ps -a प्रोजेक्ट के लिए कुछ भी प्रिंट नहीं करता और <project>_default नेटवर्क हट जाता है। प्रोजेक्ट का नाम directory के नाम से लिया जाता है, जब तक कि आप Compose file में name: सेट न करें या -p पास न करें। कंटेनर की writable layer के अंदर किए गए सभी परिवर्तन अब पुनर्प्राप्त नहीं किए जा सकते। इसलिए down को ऐसा command मानें जो कंटेनर को हटा देता है और volumes में रखे डेटा को सुरक्षित रखता है।

इसे गलत directory में चलाने पर no configuration file provided: not found मिलता है। Compose को पता नहीं होता कि आपका आशय किस प्रोजेक्ट से है, इसलिए वह command को अस्वीकार कर देता है। जब आप project folder में न हों, तब docker compose -f /srv/myapp/compose.yaml down का उपयोग करें।

क्या docker compose down मेरे volumes को हटा देता है?

नहीं। शीर्ष-स्तरीय volumes key के अंतर्गत घोषित named volume, down के बाद भी बना रहता है। जिस container से वह जुड़ा था, उसके हटने के बाद भी वह बना रहता है। इस command को लेकर यही सबसे आम चिंता है। Compose v2 में इसका उत्तर स्थिर है।

ऐसा stack तैयार करें, जिस पर आप परीक्षण कर सकें। इसे खाली directory voltest में compose.yaml में रखें।

services:
  db:
    image: postgres:16.4
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

इसे शुरू करें और ऐसी row लिखें, जिसे आप बाद में पहचान सकें।

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "create table marker (note text);"
docker compose exec -T db psql -U postgres -c "insert into marker values ('survived');"

अब container हटाएँ और volume जाँचें।

docker compose down
docker volume ls

Output में अभी भी voltest_pgdata सूचीबद्ध है। Container हट गया है, लेकिन data मौजूद है। Stack को फिर शुरू करें और row पढ़ें।

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "select * from marker;"

आपको survived वाली एक row मिलती है। नया container अलग container है और उसकी ID अलग है, लेकिन वह उसी volume से जुड़ा है। यदि आपको पूरी जानकारी चाहिए, तो Compose की मूल बातें बताने वाली guide में named volumes की bind mounts से तुलना और host पर प्रत्येक के वास्तविक स्थान की जानकारी दी गई है।

down -v वास्तव में क्या नष्ट करता है

-v (लंबा रूप --volumes) Compose फ़ाइल के volumes अनुभाग में घोषित नामित volumes को हटाता है। यह containers से जुड़े anonymous volumes को भी हटाता है। इसे उसी stack पर चलाएँ।

docker compose down -v
docker volume ls

voltest_pgdata अब सूची में नहीं है। Stack को फिर शुरू करें। तब Postgres entrypoint को खाली data directory मिलती है और वह नया cluster initialise करता है। Container log यह बात स्पष्ट रूप से बताता है।

The files belonging to this database system will be owned by user "postgres".
PostgreSQL init process complete; ready for start up.

कई महीनों से चल रहे stack पर यह block दिखाई देने का अर्थ है कि volume हटा दिया गया है। आपकी marker table समाप्त हो गई है। वापस पाने का एकमात्र तरीका backup है।

कुछ storage -v द्वारा कभी नहीं हटाया जाता। Bind mount host path होता है, इसलिए Docker केवल उसे unmount करता है और आपकी files वहीं रहती हैं। external: true से चिह्नित volume को इस project के बाहर किसी चीज़ से संबंधित घोषित किया जाता है, इसलिए Compose उसे कभी नहीं हटाता। यदि down -v चलाने से पहले आपने named volume को Compose फ़ाइल से हटा दिया है, तो वह अब घोषित नहीं है। इसलिए Compose को उसे हटाने की जानकारी नहीं होती और वह docker volume prune के लिए orphan के रूप में बचा रहता है।

Refactor के दौरान आखिरी स्थिति लोगों को अक्सर भ्रमित करती है। फ़ाइल से किसी service और उसके volume को हटाकर down -v चलाने पर volume बचा रहता है, क्योंकि फ़ाइल में अब उसका उल्लेख नहीं है। फ़ाइल को संपादित करने से पहले down -v चलाएँ, बाद में नहीं।

जब आपको वास्तव में --force-recreate की आवश्यकता हो

docker compose up -d हर बार सब कुछ फिर से नहीं बनाता। Compose प्रत्येक service के resolved configuration का hash container पर label के रूप में संग्रहीत करता है। यदि hash और image ID समान हों, तो container को वैसे ही छोड़ दिया जाता है और आपको Container voltest-db-1 Running के बजाय Recreated मिलता है। लगभग हमेशा यही व्यवहार अपेक्षित होता है, क्योंकि इससे up -d को बार-बार सुरक्षित रूप से चलाया जा सकता है।

इसी कारण कुछ बदलाव प्रभावहीन दिखाई देते हैं। Compose उन files की सामग्री का hash नहीं बनाता जिनकी ओर resolved service definition संकेत करती है। Container में mount की गई config file को यदि startup पर केवल एक बार पढ़ा जाता है, तो उसे edit करने पर recreate नहीं होगा, क्योंकि mount path नहीं बदला। Service boot के समय पढ़ी गई values के साथ चलती रहती है।

docker compose up -d --force-recreate

यह प्रत्येक container को रोककर हटाता है और उसी definition से नया container बनाता है। Mounted config file में edit करने के बाद इसका उपयोग करें। इसका उपयोग तब भी करें जब कोई container ऐसी स्थिति में चला गया हो जिसे आप समझा नहीं सकते। Volumes में कोई बदलाव नहीं होता, इसलिए force recreate के बाद database सुरक्षित रहता है। उसी tag पर उपलब्ध नई image लेने के लिए pull भी आवश्यक है।

docker compose pull
docker compose up -d

pull नई image ID प्राप्त करता है। इसके बाद up -d चल रहे container की image ID अलग पाकर उसे स्वयं recreate करता है। pull के बिना --force-recreate जोड़ने पर उसी पुरानी image से नया container मिलता है। इसी कारण “मैंने force recreate किया, फिर भी यह पुराना version है” जैसी शिकायत आम है।

docker compose restart इनमें से कुछ भी नहीं करता। यह मौजूदा containers को restart करता है और Compose file को दोबारा पढ़ता ही नहीं। इसलिए बदला हुआ environment variable या बदला हुआ port mapping लागू नहीं होगा। यदि आपने file edit की है, तो up -d का उपयोग करें।

ध्यान में रखने योग्य मानसिक मॉडल

कंटेनर बदले जा सकते हैं। कंटेनर एक process और उसकी पतली writable layer से बना होता है। Compose लगभग 1 second में file से उसके जैसा समान कंटेनर बना सकता है। Volumes बदले नहीं जा सकते, क्योंकि इनमें state की एकमात्र copy होती है, जिसे आपके repository की कोई भी file फिर से generate नहीं कर सकती।

हर Compose verb इसी विभाजन के अनुरूप है। stop और start कंटेनर को बनाए रखते हैं। down और up कंटेनर को बदलते हैं और volume को बनाए रखते हैं। down -v ही एकमात्र नियमित command है जो state को हटाती है। इसी कारण इसके लिए explicit flag आवश्यक है। किसी वास्तविक system पर इसे type करने से पहले पुष्टि करें कि आपके पास backup है और आपने उसे कम से कम 1 बार restore किया है।

यही तर्क secrets पर भी लागू होता है। POSTGRES_PASSWORD के माध्यम से set किया गया password केवल database के पहली बार initialise होने पर पढ़ा जाता है। इसलिए environment file में इसे बदलकर up -d चलाने पर आपको password authentication failed for user "postgres" मिलता है। कंटेनर नया है, लेकिन volume पुराना है। पुराने volume में पुराना password अभी भी मौजूद है। Compose env files और secrets को कैसे resolve करता है बताता है कि एक ही variable को 2 बार set करने पर कौन-सी layer प्राथमिकता पाती है।

विफलता की स्थितियाँ और दिखाई देने वाले संदेश

no configuration file provided: not found का अर्थ है कि Compose ऐसी directory में चल रहा है जिसमें compose.yaml और docker-compose.yml दोनों नहीं हैं। पूरे path के साथ -f दें।

down पर network voltest_default has active endpoints का अर्थ है कि इस project के बाहर का कोई container project network से जुड़ा है। आमतौर पर इसे docker run --network के साथ हाथ से शुरू किया गया होता है। उस container को हटाएँ, फिर down दोबारा चलाएँ।

किसी service का नाम बदलने या उसे हटाने के बाद Found orphan containers ([voltest-old-1]) for this project दिखाई देता है। पुराने container में अभी भी project label मौजूद है। docker compose down --remove-orphans उन्हें साफ़ करता है और इसे स्वस्थ stack पर चलाना सुरक्षित है।

हाथ से चलाए गए docker volume rm पर Error response from daemon: remove voltest_pgdata: volume is in use का अर्थ है कि कोई container अभी भी volume को reference कर रहा है। इसमें stopped container भी शामिल है। पहले docker compose down चलाएँ, फिर volume हटाएँ, या सीधे down -v का उपयोग करें। बड़े project में multi service Compose stack दिखाता है कि एक project में कितने volumes जमा हो सकते हैं।

FAQ

क्या docker compose down मेरे database को हटा देता है?

यदि database किसी named volume या bind mount में मौजूद है, तो ऐसा नहीं होता। down containers और project network को हटाता है, जबकि volume अपने data के साथ disk पर बना रहता है। अगला docker compose up -d उसी volume से एक नया container जोड़ता है और data उपलब्ध रहता है। केवल docker compose down -v named volumes हटाता है, और वह भी केवल वे volumes जो Compose file के volumes section में घोषित हैं।

जिस container को मैं वापस चलाना चाहता हूँ, उसके लिए stop और down में क्या अंतर है?

stop container को बनाए रखता है, इसलिए docker compose start आपको उसी container में, उसी writable layer के साथ वापस ले आता है। आपने container के अंदर manually install या edit किया हुआ कोई भी data मौजूद रहता है। down container को हटा देता है, इसलिए अगला up -d image से एक नया container बनाता है और वे manual changes खो जाते हैं। Debugging के दौरान stop का उपयोग करें।

Compose project द्वारा बनाए गए सभी resources को मैं कैसे हटाऊँ?

docker compose down -v --rmi all --remove-orphans containers, project network, file में घोषित named volumes, services द्वारा उपयोग की गई images और project name से labelled किसी भी शेष container को हटा देता है। यह bind mounts या external: true से चिह्नित volumes को नहीं छूता। इसे चलाने से पहले docker volume ls से जाँच लें कि आप क्या हटाने वाले हैं।

Mounted config file में किए गए बदलाव को मेरा container अनदेखा क्यों करता है?

Compose यह तय करता है कि container को recreate करना है या नहीं, इसके लिए resolved service definition के hash की तुलना करता है। इस hash में mounted file की सामग्री शामिल नहीं होती। Path नहीं बदला है, इसलिए Compose container को चलने देता है और startup के समय पढ़े गए values का उपयोग करता है। वह file दोबारा पढ़ने वाला नया container बनाने के लिए docker compose up -d --force-recreate चलाएँ।

बदलने के बाद मेरा नया POSTGRES_PASSWORD काम क्यों नहीं कर रहा है?

Postgres image POSTGRES_PASSWORD को केवल तब पढ़ता है, जब वह empty data directory को initialise करता है। आपके volume में पहले से initialised cluster मौजूद है, इसलिए variable को अनदेखा किया जाता है और पुराना password लागू रहता है। आपको password authentication failed for user "postgres" दिखाई देगा। चल रहे database के अंदर ALTER USER से password बदलें, या data खोने की अनुमति देकर docker compose down -v के साथ फिर से शुरू करें।