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

थोडक्यात उत्तर

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

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

docker compose stop: कंटेनर सुरूच राहतात

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

docker compose stop
docker compose ps -a

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

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

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

down कंटेनर थांबवते आणि त्यानंतर ते काढून टाकते. त्यासोबत Compose ने प्रकल्पासाठी तयार केलेले डीफॉल्ट नेटवर्कही काढले जाते. Docker दस्तऐवजात याचे वर्णन कंटेनर थांबवणे आणि up ने तयार केलेले कंटेनर, नेटवर्क, व्हॉल्यूम आणि इमेज काढून टाकणे असे केले आहे. मात्र, व्हॉल्यूम आणि इमेज काढण्याची प्रक्रिया तुम्ही -v आणि --rmi वापरून स्पष्टपणे मागणी केल्यावरच होते.

docker compose down
docker compose ps -a
docker network ls

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

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

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

नाही. शीर्ष-स्तरीय volumes key अंतर्गत घोषित केलेले named volume, down पेक्षा जास्त काळ टिकते. ते ज्या container शी जोडलेले होते, त्या 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

आउटपुटमध्ये अजूनही 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 मूलभूत मार्गदर्शक named volumes ची bind mounts शी तुलना करते आणि प्रत्येक volume 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 सुरू करतो. 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 चालवण्यापूर्वी तुम्ही Compose file मधून हटवलेला named volume यापुढे घोषित केलेला नसतो. त्यामुळे Compose ला तो काढून टाकण्याची माहिती नसते आणि तो docker volume prune साठी orphan म्हणून मागे राहतो.

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

तुम्हाला प्रत्यक्षात --force-recreate कधी आवश्यक असते

docker compose up -d प्रत्येक वेळी सर्व काही पुन्हा तयार करत नाही. Compose प्रत्येक सेवेच्या निराकरण केलेल्या कॉन्फिगरेशनचा hash कंटेनरवर label म्हणून साठवते. hash जुळत असेल आणि image ID जुळत असेल, तर कंटेनरमध्ये कोणताही बदल केला जात नाही आणि तुम्हाला Container voltest-db-1 Running ऐवजी Recreated मिळते. हे जवळजवळ नेहमी अपेक्षित वर्तन असते, कारण त्यामुळे up -d वारंवार सुरक्षितपणे चालवता येते.

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

docker compose up -d --force-recreate

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

docker compose pull
docker compose up -d

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

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

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

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

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

हेच तर्क secrets साठीही लागू होतात. POSTGRES_PASSWORD द्वारे सेट केलेला password database प्रथम initialize होताना एकदाच वाचला जातो. त्यामुळे environment file मध्ये तो बदलून up -d चालवल्यास password authentication failed for user "postgres" मिळते. कंटेनर नवीन असतो, पण volume जुना असतो. जुन्या volume मध्ये जुना password अजूनही असतो. Compose env files आणि secrets कसे सोडवते समान variable दोनदा सेट केल्यावर कोणता स्तर प्राधान्याने लागू होतो, हे स्पष्ट करते.

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

no configuration file provided: not found याचा अर्थ असा की Compose अशा directory मध्ये चालू आहे जिथे compose.yaml आणि docker-compose.yml दोन्ही नाहीत. पूर्ण path सह -f द्या.

down वरील network voltest_default has active endpoints याचा अर्थ असा की या project च्या network शी या project बाहेरील container जोडलेला आहे. तो सामान्यतः docker run --network वापरून हाताने सुरू केलेला असतो. तो container काढून टाका. त्यानंतर पुन्हा down चालवा.

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

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

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

stop container ठेवते. त्यामुळे docker compose start तुम्हाला त्याच writable layer असलेल्या त्याच container मध्ये परत आणते. Container मध्ये हाताने install किंवा edit केलेले सर्वकाही तसेच राहते. down container हटवते. त्यामुळे पुढील up -d image मधून नवीन container तयार करते आणि हाताने केलेले बदल नष्ट होतात. 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 बदलत नाही. काय हटणार आहे हे पाहण्यासाठी command चालवण्यापूर्वी docker volume ls तपासा.

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

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

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

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