VPN जडान भएपछि Docker भोल्युम माउन्ट असफल हुन्छ: daemon जाँच गर्नुहोस्

यो समस्याबारे लगभग हरेक लेखले भोल्युमलाई दोष दिन्छ, र सुधार गर्न यति लामो समय लाग्नुको कारण पनि त्यही हो। तपाईंसँग काम गर्ने bind mount थियो, कर्पोरेट VPN जडान भयो, र docker compose up अब हराएको source path, खाली डाइरेक्टरी, वा इन्जिनले बनाउन अस्वीकार गर्ने mount सँग असफल हुन्छ। मैले सफा गरेका वातावरणहरूमा Compose फाइल परिवर्तन भएको थिएन र बाटो सही थियो। परिवर्तन भएको कुरा यो थियो कि कुन daemon ले अनुरोध पायो, र mount त्रुटि त्यो भिन्नता पहिलो पटक देखिने ठाउँ मात्र थियो।

भोल्युम कहिल्यै सरेन; अनुरोध सर्यो

एक -v /srv/app:/app फ्ल्याग तपाईंको shell ले गर्ने डाइरेक्टरी प्रतिलिपि होइन। क्लाइन्टले यसलाई API अनुरोधमा बदल्छ, र जवाफ दिने daemon /srv/app लाई आफ्नै फाइलसिस्टमको आधारमा समाधान गर्छ। दुवै पक्ष एउटै कर्नेलमा चल्दा त्यही बाटो तपाईंले फाइल म्यानेजरमा देख्नुहुन्छ। endpoint परिवर्तन हुँदा त्यही स्ट्रिङ तपाईंको प्रोजेक्ट डाइरेक्टरीबारे कहिल्यै नसुनेको मेसिनमा खोजिन्छ, र daemon ले या त स्रोत हराएको जनाउँछ या त्यसको ठाउँमा चुपचाप खाली डाइरेक्टरी बनाउँछ।

नाम भएको भोल्युम काम गरिरहने र bind mount नगर्ने कारण पनि यही हो। -v appdata:/app daemon को स्वामित्वमा रहेको भण्डारणलाई नाम दिन्छ, त्यसैले कुनै host path कुनै निश्चित ठाउँमा हुनु आवश्यक छैन। एउटा सेवालाई bind mount बाट नाम भएको भोल्युममा बदल्दा त्रुटि हराउँछ भने तपाईंले समस्या सुधार्नुभएको छैन। क्लाइन्ट र daemon बाटो कुन फाइलसिस्टमको हो भन्नेमा सहमत छैनन् भनी तपाईंले पुष्टि गर्नुभयो, र त्यो मतभेद फेरि वास्तविक host डाइरेक्टरी चाहिने क्षणमा फर्कन्छ।

माउन्ट छुनु अघि endpoint प्रिन्ट गर्नुहोस्

धेरै सेटिङले क्लाइन्टलाई endpoint तर्फ देखाउन सक्छन्, र ती सधैं सहमत हुँदैनन्: --context फ्ल्याग, DOCKER_CONTEXT, DOCKER_HOST हालको shell मा, र क्लाइन्ट कन्फिगरेसनमा सुरक्षित context। प्राथमिकताबारे सोच्नुको सट्टा सबै प्रिन्ट गर्नुहोस् र जवाफहरू तुलना गर्नुहोस्।

docker context show
docker context ls
docker version
docker info --format "{{.Name}} {{.OperatingSystem}} {{.ServerVersion}}"

क्लाइन्ट कन्फिग यहाँ छ: ~/.docker/config.json Linux र macOS मा, र यहाँ: %USERPROFILE%\.docker\config.json Windows मा, र हालको टर्मिनलमा export गरिएको मानले सुरक्षित मानलाई त्यो सत्रका लागि मात्र ओभरराइड गर्छ। endpoint स्थानीय socket होइन hostname हो भने, नाम समाधान र मार्गहरूले यो कहाँ अवतरण हुन्छ भनी निर्धारण गर्छन्, र VPN क्लाइन्टले ठ्याक्कै त्यही पुनःलेखन गर्छ। मार्ग थप्ने वा resolver बदल्ने tunnel ले पहिले यो ल्यापटपलाई जनाउने नाम कर्पोरेट नेटवर्कभित्रको ठेगानामा पठाउन सक्छ।

कन्फिगरेसन होइन, अवस्था तुलना गर्नुहोस्। tunnel बन्द हुँदा docker ps -a र docker images चलाउनुहोस्, त्यसपछि tunnel खुला हुँदा फेरि। फरक कन्टेनर सूची कुनै पनि कन्फिग फाइलभन्दा बलियो प्रमाण हो, किनकि यसले तपाईंको अनुरोधलाई अर्को daemon ले जवाफ दिएको देखाउँछ।

बाटो त्यहाँ छ कि भनी daemon लाई सोध्नुहोस्

तपाईं कुन daemon सम्म पुग्नुभयो थाहा भएपछि, त्यसलाई डाइरेक्टरी हेर्न लगाउनुहोस्। --mount रूपले छोटो फ्ल्यागभन्दा स्पष्ट सन्देशसँग असफल हुन्छ, किनकि यसले कन्टेनर सुरु गर्नु अघि स्रोत प्रमाणित गर्छ:

docker run --rm --mount type=bind,source=/srv/app,target=/app alpine ls -la /app

यसले स्रोत हराएको जनाएमा, जवाफ दिएको मेसिनमा त्यो बनाउनुहोस्, वा सेवालाई नाम भएको भोल्युमतर्फ देखाएर डेटा त्यहाँ प्रतिलिपि गर्नुहोस्। यो जाँचअघि भोल्युम पुनः बनाउनु र इन्जिन पुनःस्थापना गर्नु तपाईंले गर्नु नहुने कुरा हो। ती कार्यहरूले असंगति लुकाउन पर्याप्त वातावरण बदल्छन्, तर त्यसलाई ठाउँमै राख्छन्।

अर्को एउटा बाटो पूर्ण रूपमा अन्तै चल्छ: image तान्नु daemon को काम हो, क्लाइन्टको होइन। सफल तान्नाले daemon registry सम्म पुग्न सक्छ भन्ने मात्र प्रमाणित गर्छ, र काम गर्ने bind mount ले बाटो समाधान भयो भन्ने मात्र। हरेक बाटोलाई यो वास्तवमै चल्ने ठाउँमै परीक्षण गर्नुहोस्, नत्र गलत बाटोमा दिउँसो बिताउनुहुनेछ।

इन्ट्रानेट नामहरू अर्कै कारणले असफल हुन्छन्

त्यही प्रतिवेदनको दोस्रो आधा सामान्यतया कन्टेनरले intranet.corp.exampleसम्म पुग्न नसक्नु हो। त्यो छुट्टै संयन्त्र हो, दोस्रो भोल्युम समस्या होइन। कन्टेनरले आफ्नो /etc/resolv.conf सुरु हुँदा पाउँछ, जो daemon resolver सेटिङबाट उत्पन्न हुन्छ, त्यसैले कन्टेनर बनाएपछि VPN ले थपेको DNS सर्भर कन्टेनर पुनः नबनेसम्म त्यहाँ देखिँदैन।

प्रयोगकर्ता-परिभाषित नेटवर्कमा Docker को अन्तर्निहित resolver ले बाह्य प्रश्नहरू host मा कन्फिगर गरिएका सर्भरहरूमा पठाउँछ, जसले VPN ले host resolver पुनःलेखन गर्दा मद्दत गर्छ र विभाजित DNS ले आन्तरिक क्षेत्र daemon ले अब नदेख्ने सर्भरमा पठाउँदा हानि गर्छ। साँघुरो, स्पष्ट म्यापिङले कहिल्यै नबदलिने नामहरूका लागि यो बहस छल्छ:

services:
  web:
    extra_hosts:
      - "intranet.corp.example:10.20.30.40"

यसले कन्टेनरको hosts फाइलमा प्रविष्टि लेख्छ, त्यसैले कन्टेनरले tunnel बारे केही सिक्दैन, र यसले ठेगाना पनि जमाउँछ। आन्तरिक host सर्दा कसैले Compose फाइल सम्पादन नगरेसम्म प्रविष्टि गलत नै रहन्छ। स्थिर उपकरण वा पिन गरिएको डेटाबेसका लागि यो प्रयोग गर्नुहोस्, र सर्ने नामहरू DNS लाई छोड्नुहोस्।

पुनःस्थापनाले वास्तवमा के परिवर्तन गर्छ

Docker Desktop पुनःस्थापना गर्दा VM, socket र context सूची फेरि बन्छन्, र माउन्ट फेरि काम गर्न थाल्छ। त्यो नतिजा वास्तविक छ र यसले केही सिकाउँदैन, त्यसैले अर्को VPN अपडेटपछि त्यही विफलता फर्कन्छ। पुनःस्थापनाले क्लाइन्टले प्रयोग गरेको endpoint बदल्यो; यसले तपाईंको प्रोजेक्टले नाम दिने बाटोलाई daemon ले वास्तवमै पढ्ने फाइलसिस्टमसँग मिलाएन।

मेरो कामको क्रम छोटो छ। क्लाइन्टले कुन endpoint प्रयोग गर्नेछ निश्चित गर्नुहोस्। कन्टेनर सूची तुलना गरेर कुन daemon ले जवाफ दियो निश्चित गर्नुहोस्। त्यो daemon लाई source path सूचीबद्ध गर्न भन्नुहोस्। त्यसपछि मात्र माउन्ट सम्पादन गर्नुहोस्, hosts प्रविष्टि थप्नुहोस्, वा भोल्युम प्रकार बदल्नुहोस्। यदि तपाईं VPN मा काम गर्ने टोलीका लागि Compose फाइल राख्नुहुन्छ भने, daemon को स्वामित्वमा हुनुपर्ने डेटाका लागि नाम भएका भोल्युमलाई प्राथमिकता दिनुहोस्, ताकि host path कहिल्यै सम्झौताको भाग नबनोस्।