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 बाह्य प्रश्न होस्टवर कॉन्फिगर केलेल्या सर्व्हरकडे पाठवतो, जे VPN होस्ट resolver पुन्हा लिहितो तेव्हा मदत करते आणि विभाजित DNS अंतर्गत झोन daemon आता न दिसणाऱ्या सर्व्हरकडे पाठवतो तेव्हा हानी करते. अरुंद, स्पष्ट मॅपिंग कधीही न बदलणाऱ्या नावांसाठीचा वाद टाळते:

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

हे कंटेनरच्या hosts फाइलमध्ये नोंद लिहिते, त्यामुळे कंटेनर tunnel बद्दल काहीही शिकत नाही, आणि ते पत्ताही गोठवते. अंतर्गत होस्ट हलल्यावर कोणी Compose फाइल संपादित करेपर्यंत नोंद चुकीचीच राहते. स्थिर उपकरण किंवा पिन केलेल्या डेटाबेससाठी याचा वापर करा, आणि हलणारी नावे DNS ला सोपवा.

पुन्हा इन्स्टॉल करणे प्रत्यक्षात काय बदलते

Docker Desktop पुन्हा इन्स्टॉल केल्याने VM, socket आणि context यादी पुन्हा तयार होते, आणि माउंट पुन्हा काम करू लागतो. तो निकाल खरा आहे आणि तो काहीच शिकवत नाही, म्हणूनच पुढील VPN अपडेटनंतर तीच बिघाड परत येते. पुन्हा इन्स्टॉलने क्लायंट वापरत असलेला endpoint बदलला; त्याने तुमचा प्रोजेक्ट ज्या पथाला नाव देतो तो daemon प्रत्यक्षात वाचत असलेल्या फाइलसिस्टमशी जुळवला नाही.

माझा कामाचा क्रम छोटा आहे. क्लायंट कोणता endpoint वापरेल याची खात्री करा. कंटेनर याद्यांची तुलना करून कोणत्या daemon ने उत्तर दिले याची खात्री करा. त्या daemon ला source path सूचीबद्ध करायला सांगा. त्यानंतरच माउंट संपादित करा, hosts नोंद जोडा किंवा व्हॉल्यूम प्रकार बदला. तुम्ही VPN वर काम करणाऱ्या संघासाठी Compose फाइल सांभाळत असल्यास, daemon च्या मालकीचा असावा अशा डेटासाठी नावाच्या व्हॉल्यूमला प्राधान्य द्या, जेणेकरून host path कधीही कराराचा भाग होणार नाही.