यदि macOS पर docker compose up के बाद वे फ़ाइलें गायब हो जाती हैं जो आपकी इमेज से आनी चाहिए, तो जांचें कि क्या कोई बाइंड माउंट उनकी कंटेनर डायरेक्टरी को कवर कर रहा है। एक बाइंड माउंट होस्ट फ़ोल्डर की सामग्री को माउंट टारगेट पर दृश्यमान बनाता है, जिससे इमेज में पहले से मौजूद फ़ाइलें छिप जाती हैं। विशिष्ट मैपिंग ढूंढें, उसके होस्ट या कंटेनर पाथ को सही करें—या यदि यह अनावश्यक है तो इसे हटा दें—और प्रभावित सर्विस को फिर से बनाएं। Docker दस्तावेज़ बताते हैं कि माउंट के बिना कंटेनर को फिर से बनाना ही इमेज की मूल फ़ाइलों को फिर से प्रकट करने का तरीका है। (Bind mounts)

बाइंड माउंट फ़ाइलों को क्यों छिपाता है

एक बाइंड माउंट होस्ट के पाथ को कंटेनर के पाथ से जोड़ता है। उदाहरण के लिए, ./app:/usr/src/app को माउंट करने से होस्ट का app फ़ोल्डर /usr/src/app पर दिखाई देने लगता है। यदि इमेज में पहले से ही वहां फ़ाइलें मौजूद हैं, तो वे अभी भी इमेज का हिस्सा होती हैं, लेकिन माउंट सक्रिय रहने के दौरान छिपी रहती हैं। इससे एक कार्यशील इमेज खाली दिख सकती है या जब उसका अपेक्षित प्रोग्राम कवर हो जाता है तो स्टार्टअप त्रुटियां हो सकती हैं। यही व्यवहार Mac पर भी लागू होता है; Docker Desktop अपनी Linux वर्चुअल मशीन के माध्यम से होस्ट फ़ाइल एक्सेस में मध्यस्थता करता है। (Bind mounts)

यह फ़ाइल अनुमति (permission) की समस्या से अलग है: कंटेनर माउंट की गई डायरेक्टरी को ठीक से पढ़ रहा हो सकता है, लेकिन वह इमेज की डायरेक्टरी के बजाय फ़ाइलों के एक अलग सेट को पढ़ रहा होता है। ओनरशिप बदलने या इमेज को फिर से बनाने (rebuilding) से पहले मैपिंग की जांच करें।

अपनी Compose फ़ाइल में मैपिंग ढूंढें

प्रोजेक्ट शुरू करने के लिए उपयोग की जाने वाली Compose फ़ाइल खोलें और प्रभावित सर्विस की volumes: प्रविष्टियों का पता लगाएं। ./app:/usr/src/app जैसी शॉर्ट-फ़ॉर्म प्रविष्टि एक बाइंड माउंट होती है जब इसका सोर्स होस्ट पाथ होता है। स्थानीय Compose में, एक रिलेटिव सोर्स पाथ का समाधान Compose फ़ाइल की पैरेंट डायरेक्टरी से किया जाता है। इसका मतलब है कि यदि Compose फ़ाइल किसी सबडायरेक्टरी में है, तो ./app आपकी अपेक्षा से भिन्न फ़ोल्डर को संदर्भित कर सकता है। (Compose services reference)

हल किए गए कॉन्फ़िगरेशन और सर्विस की स्थिति देखने के लिए, macOS टर्मिनल में प्रोजेक्ट डायरेक्टरी से ये कमांड चलाएं:

docker compose config
docker compose ps

रेंडर किए गए कॉन्फ़िगरेशन में, प्रत्येक माउंट के source (Mac पाथ) की तुलना उसके target (कंटेनर पाथ) से करें। फिर टारगेट की तुलना इमेज की वर्किंग डायरेक्टरी और उस डायरेक्टरी से करें जहां इसकी एप्लिकेशन फ़ाइलें अपेक्षित हैं। .:/usr/src/app जैसा एक व्यापक माउंट संपूर्ण एप्लिकेशन डायरेक्टरी को कवर कर सकता है; ./config:/usr/src/app/config जैसी एक संकीर्ण मैपिंग बाकी इमेज डायरेक्टरी को दृश्यमान छोड़ देती है।

सही समाधान चुनें

यदि सर्विस को सोर्स कोड तक लाइव एक्सेस की आवश्यकता है, तो बाइंड माउंट बनाए रखें, लेकिन इसे सही होस्ट फ़ोल्डर और इच्छित कंटेनर सबडायरेक्टरी पर इंगित करें। पुष्टि करें कि होस्ट डायरेक्टरी में वे फ़ाइलें मौजूद हैं जिनकी आप अपेक्षा करते हैं। Compose का संक्षिप्त सिंटैक्स किसी अनुपलब्ध बाइंड सोर्स पर एक डायरेक्टरी बना देता है, इसलिए टाइपो के कारण कंटेनर को चुपचाप एक खाली फ़ोल्डर मिल सकता है। स्पष्ट नियंत्रण के लिए, create_host_path: false के साथ लंबे सिंटैक्स का उपयोग करें; फिर Compose डायरेक्टरी बनाने के बजाय गायब सोर्स की रिपोर्ट करेगा। (Compose services reference)

services:
  app:
    volumes:
      - type: bind
        source: ./app
        target: /usr/src/app
        bind:
          create_host_path: false

यदि इमेज को एप्लिकेशन फ़ाइलें प्रदान करनी चाहिए, तो उस डायरेक्टरी को टारगेट करने वाले माउंट को हटा दें। यदि केवल कॉन्फ़िगरेशन या एक जनरेट किए गए फ़ोल्डर को होस्ट एक्सेस की आवश्यकता है, तो केवल उस सबडायरेक्टरी को माउंट करें। डेटाबेस जैसे पर्सिस्टेंट कंटेनर डेटा के लिए, इसके बजाय एक नेम्ड वॉल्यूम पर विचार करें: Docker इसके स्टोरेज का प्रबंधन करता है, और यह उस डेटा को किसी विशेष Mac डायरेक्टरी से जोड़ने से बचाता है। (Volumes)

सर्विस को फिर से बनाएं और सत्यापित करें

Compose फ़ाइल को संपादित करने के बाद, प्रभावित सर्विस को फिर से बनाएं ताकि यह अपडेट किए गए माउंट का उपयोग करे। नीचे दिए गए app को अपनी फ़ाइल से सर्विस नाम से बदलें:

docker compose up -d --force-recreate app
docker compose exec app sh -c 'ls -la /usr/src/app'

ls कमांड यह जांचता है कि कंटेनर टारगेट पर क्या देख सकता है; यदि आपकी सर्विस किसी भिन्न पाथ का उपयोग करती है तो पाथ बदलें। यदि इमेज में कोई शेल नहीं है या ls की कमी है, तो docker compose logs app के साथ इसके स्टार्टअप लॉग का निरीक्षण करें और उस इमेज में उपलब्ध डायग्नोस्टिक कमांड का उपयोग करें। Docker कंटेनर के माउंट सोर्स और डेस्टिनेशन की जांच के लिए docker inspect का भी दस्तावेजीकरण करता है; Compose के साथ, पहले docker compose ps से इसका कंटेनर नाम प्राप्त करें, फिर docker inspect CONTAINER_NAME चलाएं। (Bind mounts)

यदि सोर्स Docker Desktop के साझा फ़ोल्डरों से बाहर है, या आपको Mounts denied या file is not shared from the host दिखाई देता है, तो Docker Desktop की Settings > Resources > File sharing जांचें और विशिष्ट Mac डायरेक्टरी जोड़ें। Docker डिफ़ॉल्ट रूप से साझा की गई सूचियों में /Users, /Volumes, /private, /tmp, और /var/folders को सूचीबद्ध करता है, लेकिन उन स्थानों से बाहर की डायरेक्टरी को जोड़ने की आवश्यकता हो सकती है। Docker VMM बाइंड माउंट ऑटो-शेयर का समर्थन नहीं करता है, इसलिए उस बैकएंड के लिए डायरेक्टरी को मैन्युअल रूप से जोड़ना आवश्यक है। (Docker Desktop settings, Virtual Machine Manager)

इमेज फ़ाइलों को छिपाने वाले माउंट को आमतौर पर इसके सोर्स या टारगेट को सही करके, इसके दायरे को सीमित करके, या इसे हटाकर और सर्विस को फिर से बनाकर ठीक किया जाता है। जब कंटेनर को किसी विशिष्ट होस्ट फ़ोल्डर की आवश्यकता हो, तो बाइंड माउंट रखें; अन्यथा, इमेज को अपनी फ़ाइलें प्रदान करने दें या पर्सिस्टेंट डेटा को Docker-प्रबंधित वॉल्यूम में स्टोर करें।

स्रोत