macOS पर किसी Compose बाइंड माउंट को सुरक्षित रूप से बदलने के लिए, सबसे पहले मौजूदा होस्ट फ़ोल्डर और उस कंटेनर पाथ की पहचान करें जिसे यह सर्व करता है। Compose में बदलाव करने से पहले फ़ाइलों को नए Mac फ़ोल्डर में कॉपी करें, फिर रिज़ॉल्व किए गए माउंट को सत्यापित करें और प्रभावित सर्विस को फिर से बनाएँ। एक बाइंड माउंट किसी होस्ट पाथ को पॉइंट करता है; उस पाथ को बदलने से मूल फ़ाइलें स्थानांतरित या हटाई नहीं जाती हैं। Docker का बाइंड माउंट दस्तावेज़ यह भी बताता है कि एक माउंट अपने कंटेनर गंतव्य पर पहले से मौजूद फ़ाइलों को छिपा सकता है।

जानें कि माउंट किन फ़ाइलों को नियंत्रित करता है

Compose बाइंड माउंट आपके Mac के एक पाथ को कंटेनर के अंदर के पाथ से जोड़ता है। उदाहरण के लिए, ./data:/var/lib/example Compose फ़ाइल के बगल में मौजूद data डायरेक्टरी को कंटेनर के भीतर /var/lib/example पर उपलब्ध कराता है। कंटेनर द्वारा उस माउंट में किए गए राइट्स (writes) Mac फ़ाइलों को बदल सकते हैं, क्योंकि बाइंड माउंट डिफ़ॉल्ट रूप से रीड-राइट होते हैं। Mac फ़ोल्डर वह डेटा है जिसे आपको सुरक्षित रखना है; कंटेनर गंतव्य वह जगह है जहाँ एप्लिकेशन इसे देखने की अपेक्षा करता है।

यह db-data:/var/lib/example जैसे नेम्ड वॉल्यूम (named volume) से भिन्न है। एक नेम्ड वॉल्यूम Docker द्वारा संग्रहीत और प्रबंधित किया जाता है, जबकि एक बाइंड माउंट होस्ट डायरेक्टरी का उपयोग करता है। एक को दूसरे में बदलना एक स्टोरेज माइग्रेशन है, न कि केवल एक पाथ संपादन। यह न मानें कि कंटेनर को फिर से बनाने से उनके बीच फ़ाइलें कॉपी हो जाती हैं। Docker का स्टोरेज दस्तावेज़ इस अंतर का वर्णन करता है।

मौजूदा फ़ाइलों को नए Mac फ़ोल्डर में कॉपी करें

Compose फ़ाइल को बदलने से पहले, सर्विस को रोक दें यदि यह डेटा में राइट कर सकती है। Terminal से, docker compose stop app चलाएँ, जहाँ app को Compose सर्विस नाम से बदलें। इससे आपके कॉपी करने के दौरान पुराने और नए फ़ोल्डरों के बीच विसंगति होने की संभावना कम हो जाती है। सटीक वर्तमान स्रोत (source) और गंतव्य (target) की पुष्टि करने के लिए Compose फ़ाइल और किसी भी ओवरराइड की जाँच करें; केवल कंटेनर की दृश्यमान डायरेक्टरी से अनुमान लगाने से बचें।

उदाहरण के लिए, यदि वर्तमान स्रोत ~/Projects/Old App/data है और नया स्रोत ~/Projects/New App/data होना चाहिए, तो गंतव्य बनाएँ और macOS के मानक rsync कमांड के साथ सामग्री को कॉपी करें:

mkdir -p "$HOME/Projects/New App/data"
rsync -a "$HOME/Projects/Old App/data/" "$HOME/Projects/New App/data/"

अंतिम स्लैश का अर्थ है "इस डायरेक्टरी की सामग्री को कॉपी करें।" कोट्स इन उदाहरण पाथों में मौजूद रिक्त स्थानों (spaces) को डिफ़ॉल्ट macOS शेल, zsh, से सुरक्षित रखते हैं। यह कमांड फ़ाइलों को गंतव्य में मर्ज करता है और केवल-गंतव्य फ़ाइलों को नहीं हटाता है। आगे बढ़ने से पहले गंतव्य का निरीक्षण करें। यदि डेटा महत्वपूर्ण है, तो एक स्वतंत्र बैकअप भी रखें; एक प्रतिलिपि (copy) बैकअप का विकल्प नहीं है।

बाइंड माउंट को अपडेट करें और टाइपो से बचाव करें

डायरेक्टरी माउंट के लिए Compose के लॉन्ग सिंटैक्स (long syntax) को प्राथमिकता दें जब आप चाहते हैं कि कोई अनुपलब्ध स्रोत पाथ चुपचाप एक खाली फ़ोल्डर बनने के बजाय स्टार्टअप को रोक दे:

services:
  app:
    volumes:
      - type: bind
        source: ./data
        target: /var/lib/example
        bind:
          create_host_path: false

यहाँ, स्थानीय Compose रनटाइम के लिए ./data को Compose फ़ाइल की पैरेंट डायरेक्टरी के सापेक्ष रिज़ॉल्व किया जाता है। इसे इच्छित सापेक्ष या निरपेक्ष (absolute) Mac पाथ में बदलें, लेकिन यदि एप्लिकेशन को /var/lib/example का उपयोग जारी रखना है, तो target को वही रखें। Compose का शॉर्ट सिंटैक्स (short syntax) स्रोत के गायब होने पर एक होस्ट डायरेक्टरी बना देता है; create_host_path: false के साथ लॉन्ग सिंटैक्स उस फ़ॉलबैक से बचाता है। Compose सर्विस संदर्भ देखें।

यदि आप रिक्त स्थान वाला कोई निरपेक्ष पाथ चुनते हैं, तो YAML स्ट्रिंग को उद्धृत (quote) करें, उदाहरण के लिए source: "/Users/sam/Projects/New App/data"। sam को अपने Mac खाते के वास्तविक होम-डायरेक्टरी नाम से बदलें। YAML में स्रोत पाथ को शाब्दिक पाथ (literal path) के रूप में रखें; शेल कोटिंग नियम Terminal कमांड पर लागू होते हैं, YAML मानों पर नहीं।

रिज़ॉल्व किए गए पाथ की जाँच करें, फिर सर्विस को फिर से बनाएँ

Compose फ़ाइल वाली डायरेक्टरी से, उस कॉन्फ़िगरेशन का निरीक्षण करें जिसका उपयोग Compose करेगा:

docker compose config

जाँचें कि app सर्विस का बाइंड स्रोत नए फ़ोल्डर पर रिज़ॉल्व होता है और इसका गंतव्य अभी भी /var/lib/example है। यदि आप एकाधिक Compose फ़ाइलों का उपयोग करते हैं, तो याद रखें कि पाथ निर्दिष्ट पहली फ़ाइल पर आधारित होते हैं; Compose CLI संदर्भ इस व्यवहार का दस्तावेजीकरण करता है। यदि रिज़ॉल्व किया गया स्रोत अप्रत्याशित है, तो कंटेनर शुरू करने से पहले रुकें और फ़ाइल को सही करें।

सर्विस को फिर से बनाएँ ताकि चल रहे कंटेनर को बदला हुआ माउंट प्राप्त हो सके:

docker compose up -d --force-recreate app
docker compose ps app

Compose दस्तावेज़ बताता है कि कॉन्फ़िगरेशन बदलने पर up कंटेनरों को फिर से बनाता है, और --force-recreate इसे स्पष्ट करता है। पुष्टि करें कि सर्विस चल रही है, फिर पुराने फ़ोल्डर को हटाने या उसका नाम बदलने से पहले एप्लिकेशन की अपेक्षित फ़ाइलों या डेटा की जाँच करें। पुरानी डायरेक्टरी आपके Mac पर तब तक बनी रहती है जब तक कि आप इसे स्वयं नहीं हटाते। इसे तब तक बनाए रखें जब तक आप यह पुष्टि न कर लें कि नया स्रोत सही है और एप्लिकेशन अपेक्षा के अनुरूप व्यवहार कर रहा है।

यदि Docker Desktop for Mac पर माउंट विफल हो जाता है

Docker Desktop कंटेनरों को Linux VM में चलाता है और Mac फ़ाइलों तक पहुँच को मध्यस्थता प्रदान करता है। इसकी डिफ़ॉल्ट शेयर्ड डायरेक्टरीज़ में /Users, /Volumes, /private, /tmp, और /var/folders शामिल हैं; उपलब्ध शेयर्ड स्थानों के बाहर के स्रोत को Docker Desktop के Settings > Resources > File sharing में जोड़ने की आवश्यकता हो सकती है। Docker का डेस्कटॉप सेटिंग्स दस्तावेज़ इस नियंत्रण का वर्णन करता है और नोट करता है कि फ़ाइल अनुमतियाँ अभी भी मायने रखती हैं।

एक विफल माउंट को पाथ और शेयरिंग की जाँच के लिए प्रेरित करना चाहिए, न कि पुरानी कॉपी को हटाने के लिए। यदि नई डायरेक्टरी खाली है, तो रिज़ॉल्व किए गए source को सत्यापित करें, क्या कॉपी ने इच्छित डायरेक्टरी स्तर पर फ़ाइलें रखी हैं, और क्या Docker Desktop उस Mac स्थान तक पहुँच सकता है। बाइंड-माउंट मरम्मत चरण के रूप में docker compose down -v का उपयोग न करें: बाइंड स्रोत को बदलने के लिए यह अनावश्यक है और प्रोजेक्ट द्वारा उपयोग किए जाने वाले नेम्ड वॉल्यूम को हटा सकता है।

सुरक्षित समापन सरल है: सत्यापित करें कि नए Mac फ़ोल्डर में आवश्यक फ़ाइलें शामिल हैं, पुष्टि करें कि Compose उस फ़ोल्डर और अपेक्षित कंटेनर गंतव्य पर रिज़ॉल्व होता है, फिर मूल कॉपी को हटाने से पहले फिर से बनाई गई सर्विस का परीक्षण करें।

स्रोत