docker compose stop आणि down मधील फरक काय?

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

docker compose stop कंटेनर थांबवते आणि ते डिस्कवर ठेवते. docker compose down कंटेनर थांबवते आणि त्यानंतर प्रकल्पासाठी Compose ने तयार केलेले कंटेनर आणि नेटवर्क हटवते. यापैकी कोणतीही कमांड named volume वर परिणाम करत नाही. -v जोडल्यावरच तुमचा database हटतो. उदाहरणार्थ, docker compose down -v कमांड named volumes हटवते, जे Compose फाइलच्या volumes विभागात घोषित केलेले असतात.

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

docker compose stop: कंटेनर थांबतात, पण कायम राहतात

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

docker compose stop
docker compose ps -a

docker compose ps स्वतंत्रपणे वापरल्यास केवळ सुरू असलेले कंटेनर दाखवते. त्यामुळे stop नंतर ते रिक्त सारणी दाखवते आणि कंटेनर हटवले गेले आहेत असे वाटते. ps -a थांबलेले कंटेनरही समाविष्ट करते. तिथे प्रत्येक सेवेजवळ Exited (0) दिसेल. docker compose start वापरून ते पुन्हा सुरू करा. यामुळे अगदी तेच कंटेनर पुन्हा वापरले जातात.

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

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

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

docker compose down
docker compose ps -a
docker network ls

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

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

docker compose down माझे volumes हटवते का?

नाही. Top-level volumes key अंतर्गत घोषित केलेला named volume down नंतरही टिकून राहतो आणि तो जोडलेला container हटवल्यानंतरही टिकतो. या command बाबत ही सर्वात सामान्य भीती आहे. Compose v2 च्या सर्व आवृत्त्यांमध्ये याचे उत्तर समान आहे.

चाचणी करता येईल असा 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 यांची तुलना तसेच host वर प्रत्येकाची वास्तविक स्थिती स्पष्ट केली आहे.

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

-v (विस्तृत स्वरूप --volumes) Compose फाइलच्या volumes विभागात घोषित केलेले named volumes तसेच कंटेनरना जोडलेले anonymous volumes काढून टाकते. ही कमांड त्याच stack वर चालवा.

docker compose down -v
docker volume ls

voltest_pgdata यादीत दिसत नाही. Stack पुन्हा सुरू केल्यावर Postgres entrypoint ला रिकामी data directory आढळते आणि तो नवीन cluster initialise करतो. कंटेनरच्या 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 चालवण्यापूर्वी तुम्ही Compose फाइलमधून हटवलेला named volume आता घोषित केलेला नसतो. त्यामुळे Compose ला तो काढायचा आहे हे कळत नाही आणि तो docker volume prune साठी orphan म्हणून तसाच राहतो.

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

तुम्हाला प्रत्यक्षात --force-recreate ची गरज कधी असते

docker compose up -d प्रत्येक वेळी संपूर्ण रचना पुन्हा तयार करत नाही. Compose प्रत्येक सेवेच्या resolved configuration चा hash container वर label म्हणून साठवते. Hash आणि image ID जुळत असल्यास container तसाच ठेवला जातो आणि तुम्हाला Container voltest-db-1 Running ऐवजी Recreated मिळते. हे जवळजवळ नेहमीच अपेक्षित वर्तन असते, कारण त्यामुळे up -d वारंवार सुरक्षितपणे चालवता येते.

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

docker compose up -d --force-recreate

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

docker compose pull
docker compose up -d

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

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

लक्षात ठेवायचे मूलभूत मॉडेल

Containers बदलून पुन्हा तयार करता येतात. Container म्हणजे process आणि त्यावरचा पातळ writable layer. Compose सुमारे एका सेकंदात file मधून त्याच्यासारखा container पुन्हा तयार करू शकते. Volumes बदलून पुन्हा तयार करता येत नाहीत, कारण त्यात state ची एकमेव प्रत असते. Repository मधील कोणतीही file ती प्रत पुन्हा निर्माण करू शकत नाही.

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

हीच तर्कशृंखला secrets साठीही लागू होते. POSTGRES_PASSWORD द्वारे सेट केलेला password database प्रथम initialize होताना फक्त एकदाच वाचला जातो. त्यामुळे environment file मध्ये तो बदलून up -d चालवल्यास password authentication failed for user "postgres" मिळते. Container नवीन असतो आणि volume जुना असतो. जुन्या volume मध्ये जुना passwordच असतो. Compose env files आणि secrets कसे resolve करते समान variable दोनदा सेट केल्यास कोणता 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 ने manually सुरू केलेले container असते. तो container काढा आणि पुन्हा down चालवा.

सेवा rename किंवा delete केल्यानंतर Found orphan containers ([voltest-old-1]) for this project दिसतो. जुन्या container कडे अजूनही project label असतो. docker compose down --remove-orphans हे labels काढते. आरोग्यपूर्ण stack वर ते चालवणे सुरक्षित आहे.

manual docker volume rm वर Error response from daemon: remove voltest_pgdata: volume is in use म्हणजे एखादा container अजूनही volume चा संदर्भ देत आहे. त्यात थांबवलेला 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 disk वर त्यातील data सह जसाच्या तसा राहतो. पुढील docker compose up -d त्याच volume ला नवीन container शी जोडते आणि data उपलब्ध असतो. फक्त docker compose down -v named volumes काढते आणि तेही Compose file मधील volumes section मध्ये घोषित केलेले volumesच.

मला पुन्हा सुरू करायचा असलेल्या container साठी stop आणि down मध्ये काय फरक आहे?

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

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

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

Mounted config file मध्ये केलेला बदल माझा container का दुर्लक्षित करतो?

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

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

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