Docker Compose stop आणि down मधील फरक काय?

लघु उत्तर

docker compose stop कंटेनर थांबवते आणि ते डिस्कवर ठेवते. docker compose down कंटेनर थांबवते आणि त्यानंतर कंटेनर तसेच या प्रकल्पासाठी Compose ने तयार केलेले network हटवते. कोणतीही command named volume वर परिणाम करत नाही. docker compose down -v प्रमाणे -v जोडल्यास, Compose file मधील volumes section मध्ये घोषित केलेले आणि या प्रकल्पाशी संबंधित non-external named volumes हटवले जातात. मात्र down कंटेनरने कोणत्याही volume च्या बाहेर, स्वतःच्या writable layer मध्ये लिहिलेली सर्व माहिती हटवते.

हा संपूर्ण फरक एका परिच्छेदात एवढाच आहे. या मार्गदर्शकाच्या उर्वरित भागात Postgres volume वापरून हे सिद्ध केले आहे. down नंतर ते टिकून राहते आणि down -v अंतर्गत हटते, हे तुम्ही पाहू शकता. तसेच --force-recreate आवश्यक असलेल्या दोन परिस्थिती स्पष्ट केल्या आहेत.

docker compose stop: कंटेनर थांबलेले दिसत नाहीत

stop प्रत्येक कंटेनरमधील मुख्य प्रक्रियेला कंटेनरमध्ये कॉन्फिगर केलेला stop signal पाठवते. डीफॉल्ट signal SIGTERM असतो. त्यानंतर ती प्रतीक्षा करते आणि प्रक्रिया अजूनही चालू असल्यास SIGKILL पाठवते. डीफॉल्ट प्रतीक्षा 10 सेकंदांची असते आणि -t ती बदलते. काहीही हटवले जात नाही. कंटेनरचा ID, त्याचा writable layer आणि त्याचे logs कायम राहतात.

docker compose stop
docker compose ps -a

docker compose ps स्वतः वापरल्यास फक्त चालू कंटेनर दाखवते. त्यामुळे stop नंतर ते रिक्त तक्ता दाखवते आणि कंटेनर हटवले गेले आहेत असे वाटते. ps -a थांबलेले कंटेनरही दाखवते. तिथे प्रत्येक सेवेजवळ Exited status आणि तिच्या प्रक्रियेने परत केलेला exit code दिसतो. व्यवस्थित shutdown झाल्यावर अनेकदा Exited (0) दिसते, परंतु नेहमीच असे होत नाही. काही servers graceful shutdown पूर्ण केल्यानंतर stop signal पुन्हा उचलतात आणि त्यामुळे प्रक्रिया त्या signal मुळे समाप्त होते. Uvicorn नेमके असेच करते. त्यामुळे व्यवस्थित stop करूनही non-zero code दिसू शकतो. प्रक्रियेत बिघाड झाला किंवा timeout नंतर ती kill केली गेली, तरी non-zero code दिसू शकतो. docker compose start वापरून कंटेनर पुन्हा सुरू करा. यामुळे अगदी तेच कंटेनर पुन्हा वापरले जातात.

कंटेनर अजूनही अस्तित्वात असल्यामुळे volume बाहेर त्यांच्यामध्ये लिहिलेली कोणतीही माहिती तिथेच राहते. यात docker compose exec वापरून manually install केलेले package आणि कंटेनरमध्ये edit केलेली config file यांचा समावेश होतो. Debugging करताना stop ला प्राधान्य देण्याचे हे व्यावहारिक कारण आहे: त्याच स्थितीतून कंटेनर पुन्हा सुरू करता येतात.

docker compose down: कंटेनर आणि नेटवर्क काढून टाकले जातात

down प्रथम कंटेनर थांबवते आणि त्यानंतर ते काढून टाकते. यासोबत प्रकल्पासाठी Compose ने तयार केलेले default network देखील काढले जाते. Docker documentation मध्ये याचे वर्णन कंटेनर थांबवणे आणि up ने तयार केलेले कंटेनर, नेटवर्क, volumes आणि images काढून टाकणे असे केले आहे. मात्र volumes आणि images काढण्याची प्रक्रिया केवळ -v आणि --rmi वापरून स्पष्टपणे सांगितल्यावरच होते.

docker compose down
docker compose ps -a
docker network ls

down नंतर, ps -a प्रकल्पासाठी काहीही output दाखवत नाही आणि <project>_default network नाहीसे होते. name: Compose file मध्ये सेट केले नसेल, COMPOSE_PROJECT_NAME सेट केले नसेल किंवा -p दिले नसेल, तर project name प्रकल्पाच्या directory च्या नावावरून घेतले जाते. कंटेनरच्या writable layer मध्ये केलेला प्रत्येक बदल आता पुनर्प्राप्त करता येत नाही. त्यामुळे down हा कंटेनर काढून टाकणारा, परंतु volumes मध्ये ठेवलेला data कायम ठेवणारा command आहे असे समजा.

सध्याच्या directory मध्ये किंवा तिच्या parent directories मध्ये Compose ला configuration file सापडली नाही, आणि -f किंवा COMPOSE_FILE द्वारे file दिली नसेल, तर no configuration file provided: not found मिळते. तुम्हाला कोणता project अभिप्रेत आहे हे Compose ला समजत नाही, त्यामुळे ते काम करण्यास नकार देते. तुम्ही project folder मध्ये नसताना docker compose -f /srv/myapp/compose.yaml down वापरा.

docker compose down माझे volumes delete करते का?

नाही. Top-level volumes key अंतर्गत घोषित केलेला named volume down पेक्षा जास्त काळ टिकतो. ज्या container ला तो जोडलेला आहे, तो container नष्ट झाल्यानंतरही volume टिकतो. या command संदर्भातील ही सर्वात सामान्य चिंता आहे. Compose v5.7.0 मध्ये down -v बदलले: आता दुसऱ्या project शी संबंधित किंवा Compose च्या बाहेर तयार केलेले named volumes warning देऊन वगळले जातात.

तपासणी करता येईल असा stack तयार करा. रिकाम्या voltest directory मध्ये 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 हा वेगळ्या ID असलेला वेगळा container आहे, पण तोच volume जोडलेला आहे. अधिक व्यापक माहिती हवी असल्यास, Compose basics मार्गदर्शकात named volumes ची bind mounts शी तुलना आणि प्रत्येक volume host वर प्रत्यक्षात कुठे राहतो हे स्पष्ट केले आहे.

down -v नेमके काय नष्ट करते

-v (विस्तारित स्वरूप --volumes) या प्रकल्पाशी संबंधित Compose फाइलच्या volumes विभागात घोषित केलेले non-external named volumes, तसेच कंटेनरना जोडलेले anonymous volumes काढते. Compose v5.7.0 मध्ये, दुसऱ्या प्रकल्पाचा ownership label असलेला किंवा कोणताही project label नसलेला named volume warning देऊन वगळला जातो; त्याची मालकी तपासता आली नाही, तर command अयशस्वी होते आणि volume कायम ठेवला जातो. ही command त्याच stack वर चालवा.

docker compose down -v
docker volume ls

voltest_pgdata यापुढे सूचीबद्ध दिसत नाही. Stack पुन्हा सुरू केल्यावर Postgres entrypoint ला रिकामी data directory सापडते आणि तो नवीन cluster initialize करतो. कंटेनर log मध्ये हे स्पष्टपणे दिसते.

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

अनेक महिने चालू असलेल्या stack वर हा block दिसत असल्यास, Postgres रिकामी data directory initialize करत आहे. तुमचा marker table नष्ट झाला आहे आणि परत मिळवण्याचा एकमेव मार्ग backup आहे.

काही storage -v कधीही काढत नाही. Bind mount हा host path असतो. त्यामुळे Docker फक्त तो unmount करते आणि तुमच्या फाइल्स त्यांच्या जागीच राहतात. external: true म्हणून चिन्हांकित volume या प्रकल्पाबाहेरील एखाद्या घटकाशी संबंधित असल्याचे घोषित केलेले असते. त्यामुळे Compose ते कधीही काढत नाही. down -v चालवण्यापूर्वी Compose फाइलमधून हटवलेला named volume यापुढे declared नसतो. त्यामुळे Compose ला तो काढता येत नाही आणि कोणताही कंटेनर त्याचा संदर्भ देत नसल्यावर तो docker volume prune -a साठी orphan म्हणून शिल्लक राहतो.

Refactor करताना शेवटची परिस्थिती अनेकांना अडचणीत आणते. फाइलमधून service आणि त्याचा volume काढून down -v चालवल्यास, फाइलमध्ये त्याचा उल्लेख उरलेला नसल्यामुळे volume टिकून राहतो. फाइल संपादित करण्यापूर्वी down -v चालवा, नंतर नाही.

जेव्हा --force-recreate खरोखर आवश्यक असते

docker compose up -d प्रत्येक वेळी सर्व काही पुन्हा तयार करत नाही. Compose प्रत्येक सेवेच्या resolved configuration चा hash container वर label म्हणून साठवते. Compose v5.7.0 मध्ये configuration hash, image ID आणि image-volume digest जुळत असतील, अपेक्षित network connections आणि named volume mounts उपलब्ध असतील आणि namespace- किंवा volume-sharing parent पुन्हा तयार केला जात नसेल, तर सुरू असलेला container तसाच ठेवला जातो. तुम्हाला Container voltest-db-1 Running ऐवजी Recreated मिळते. हीच वर्तणूक जवळजवळ नेहमी अपेक्षित असते, कारण त्यामुळे up -d वारंवार चालवणे सुरक्षित राहते.

म्हणूनच काही बदलांचा कोणताही परिणाम झालेला दिसत नाही. Compose त्या definition ने निर्देश केलेल्या फाइलमधील मजकुराचा hash काढत नाही; तो resolved service definition चा hash काढतो. Container मध्ये mount केलेली आणि startup वेळी एकदाच वाचली जाणारी config file तुम्ही संपादित केली, तरी recreate सुरू होत नाही, कारण mount path बदललेला नसतो. Service boot वेळी वाचलेल्या मूल्यांसह सुरूच राहते.

docker compose up -d --force-recreate

यामुळे प्रत्येक container थांबवला आणि काढला जातो आणि त्याच definition वरून नवीन container तयार केला जातो. Mounted config file संपादित केल्यानंतर किंवा container अशा स्थितीत गेल्यानंतर, ज्याचे कारण स्पष्ट करता येत नाही, हे वापरा. Volumes वर कोणताही परिणाम होत नाही, त्यामुळे force recreate केल्यानंतर database सुरक्षित राहतो. त्याच tag वरील नवीन image वापरण्यासाठी pull देखील आवश्यक आहे.

docker compose pull
docker compose up -d

pull नवीन image ID fetch करते आणि त्यानंतर up -d चालू container पेक्षा वेगळी image ID आढळल्यास container स्वतःहून पुन्हा तयार करते. --force-recreate हे pull शिवाय जोडल्यास त्याच जुन्या image वरून नवीन container तयार होतो. म्हणूनच "मी force recreate केले, तरी आवृत्ती जुनीच आहे" ही तक्रार वारंवार ऐकायला मिळते.

docker compose restart यापैकी काहीही करत नाही. ते विद्यमान containers पुन्हा सुरू करते; त्यांच्या configuration मध्ये बदल लागू करत नाही. त्यामुळे बदललेला environment variable किंवा बदललेले port mapping लागू होणार नाही. तुम्ही file संपादित केली असल्यास up -d वापरा.

लक्षात ठेवण्याचे मानसिक प्रारूप

कंटेनर बदलता येतात. कंटेनर म्हणजे प्रक्रिया आणि तिच्यासोबतचा एक पातळ writable layer. Compose फाइल आणि image वापरून त्याची जागा घेणारा कंटेनर तयार करू शकते. Volumes बदलता येत नाहीत, कारण त्यात state ची एकमेव प्रत असते आणि तुमच्या repository मधील कोणतीही फाइल ती पुन्हा तयार करू शकत नाही.

Compose मधील प्रत्येक verb या विभागणीशी संबंधित आहे. stop आणि start कंटेनर कायम ठेवतात. down आणि up volume कायम ठेवून कंटेनर बदलतात. down -v ही state काढून टाकणारी एकमेव नियमित command आहे. म्हणूनच तिला explicit flag आवश्यक असतो. कोणत्याही प्रत्यक्ष प्रणालीवर ही command टाइप करण्यापूर्वी तुमच्याकडे backup आहे आणि तो किमान एकदा restore करून तपासला आहे, याची खात्री करा.

हीच पद्धत secrets साठीही लागू होते. POSTGRES_PASSWORD द्वारे सेट केलेला password database पहिल्यांदा initialise होताना फक्त त्या वेळी वापरला जातो. त्यामुळे environment file मध्ये तो बदलून up -d चालवले, तरी साठवलेला password बदलत नाही. कंटेनर नवीन असतो, पण volume जुना असतो आणि त्या जुन्या volume मध्ये जुना password अजूनही साठवलेला असतो. समान variable दोनदा सेट केल्यास कोणता layer लागू होतो, हे Compose env files आणि secrets कसे resolve करते स्पष्ट करते.

अपयशाच्या स्थिती आणि दिसणाऱ्या स्ट्रिंग

no configuration file provided: not found म्हणजे Compose ला त्याच्या सध्याच्या directory आणि parent directory मध्ये केलेल्या शोधातून configuration file सापडली नाही. ही file -f किंवा COMPOSE_FILE असू शकते. पूर्ण path देऊन -f वापरा.

Compose v5.7.0 मध्ये down वर Network voltest_default Resource is still in use दिसत असल्यास, containers अजूनही project network शी जोडलेले आहेत. सामान्यतः हे containers या project च्या बाहेर docker run --network वापरून manually सुरू केलेले असतात. ते containers काढा आणि पुन्हा down चालवा.

सेवा rename किंवा delete केल्यानंतर Found orphan containers (voltest-old-1) for this project दिसते. सध्याच्या Compose आवृत्त्या नावे थेट आणि स्वल्पविरामांनी विभक्त करून दाखवतात. जुन्या Compose v2 releases मध्ये हीच warning नावे square brackets मध्ये दाखवून छापली जाते, जसे ([voltest-old-1]). जुन्या container वर अजूनही project label असतो. docker compose down --remove-orphans त्यांना काढते.

Manual 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 delete करते का?

Database named volume किंवा bind mount मध्ये असल्यास तो delete होत नाही. down containers आणि project network काढते; volume त्यातील data सह disk वर कायम राहतो. पुढील docker compose up -d त्याच volume ला नवीन container शी जोडते आणि data उपलब्ध राहतो. docker compose down -v Compose file मधील volumes section मध्ये घोषित केलेले, या project शी संबंधित non-external named volumes काढते.

परत वापरायच्या container साठी stop आणि down यात काय फरक आहे?

stop container ठेवते, त्यामुळे docker compose start त्याच writable layer असलेल्या त्याच container मध्ये परत आणते. Container मध्ये manually install किंवा edit केलेली कोणतीही गोष्ट तिथेच राहते. down container delete करते, त्यामुळे पुढील up -d image मधून नवीन container तयार करते आणि ते manual बदल नष्ट होतात. Debugging करताना stop वापरा.

Compose project ने तयार केलेल्या सर्व गोष्टी कशा काढू?

docker compose down -v --rmi all --remove-orphans containers, project network, file मध्ये घोषित केलेले आणि या project शी संबंधित non-external named volumes, services ने वापरलेल्या images आणि project मधील orphan containers काढते. हे bind mounts किंवा external: true म्हणून चिन्हांकित केलेले volumes काढत नाही. हे चालवण्यापूर्वी काय नष्ट होणार आहे ते docker volume ls ने तपासा.

Mounted config file मध्ये केलेला बदल माझा container का वापरत नाही?

Resolved service definition च्या hash ची तुलना करून Compose container पुन्हा तयार करायचा की नाही हे ठरवते. या hash मध्ये mounted file मधील contents समाविष्ट नसतात. Path बदललेला नसल्यामुळे Compose container चालू ठेवते आणि startup वेळी वाचलेली values वापरते. File पुन्हा वाचणारा नवीन container तयार करण्यासाठी docker compose up -d --force-recreate चालवा.

POSTGRES_PASSWORD बदलल्यानंतर माझा नवीन password का लागू होत नाही?

Postgres image empty data directory initialize करतानाच database password सेट करण्यासाठी POSTGRES_PASSWORD वापरते. तुमच्या volume मध्ये आधीच initialized cluster आहे. त्यामुळे variable दुर्लक्षित होते आणि जुना password लागू राहतो. नवीन password वापरून connect केल्यास password authentication failed for user "postgres" मिळते. चालू database मध्ये ALTER USER वापरून password बदला, किंवा data गमावण्याची तयारी असल्यास docker compose down -v वापरून पुन्हा सुरुवात करा.