VPN இணைந்த பிறகு Docker தொகுதி ஏற்றுதல் தோல்வியடைகிறது: daemon-ஐ சரிபார்க்கவும்

இந்தச் சிக்கலைப் பற்றிய கிட்டத்தட்ட ஒவ்வொரு எழுத்தும் தொகுதியையே குற்றம் சாட்டுகிறது, அதனால்தான் சரிசெய்வதற்கு இவ்வளவு நேரம் ஆகிறது. உங்களிடம் வேலை செய்த bind mount இருந்தது, நிறுவன VPN இணைந்தது, மேலும் docker compose up இப்போது காணாமல் போன source path, காலியான அடைவு அல்லது இயந்திரம் உருவாக்க மறுக்கும் mount உடன் தோல்வியடைகிறது. நான் சுத்தம் செய்த சூழல்களில் Compose கோப்பு மாறவில்லை, பாதையும் சரியாக இருந்தது. மாறியது எந்த daemon கோரிக்கையைப் பெற்றது என்பதுதான், mount பிழை அந்த வேறுபாடு முதலில் தெரிந்த இடம் மட்டுமே.

தொகுதி ஒருபோதும் நகரவில்லை; கோரிக்கையே நகர்ந்தது

ஒரு -v /srv/app:/app flag என்பது உங்கள் shell செய்யும் அடைவு நகல் அல்ல. கிளையண்ட் அதை API கோரிக்கையாக மாற்றுகிறது, பதிலளிக்கும் daemon /srv/app ஐ தன் சொந்தக் கோப்பு முறைமையின் அடிப்படையில் தீர்க்கிறது. இரு பக்கங்களும் ஒரே kernel-இல் இயங்கும்போது, அந்தப் பாதையே உங்கள் கோப்பு மேலாளரில் தெரிவது. endpoint மாறும்போது, அதே சரம் உங்கள் திட்ட அடைவைப் பற்றி ஒருபோதும் கேளாத இயந்திரத்தில் தேடப்படுகிறது, daemon மூலத்தைக் காணவில்லை எனத் தெரிவிக்கிறது அல்லது அதன் இடத்தில் அமைதியாகக் காலி அடைவை உருவாக்குகிறது.

பெயரிடப்பட்ட தொகுதி தொடர்ந்து வேலை செய்வதற்கும் bind mount செய்யாததற்கும் இதுவே காரணம். -v appdata:/app daemon வைத்திருக்கும் சேமிப்பகத்திற்குப் பெயரிடுகிறது, எனவே எந்த host path-உம் ஒரு குறிப்பிட்ட இடத்தில் இருக்க வேண்டியதில்லை. ஒரு சேவையை bind mount-இலிருந்து பெயரிடப்பட்ட தொகுதிக்கு மாற்றுவது பிழையை மறையச் செய்தால், நீங்கள் சிக்கலைச் சரிசெய்யவில்லை. பாதை எந்தக் கோப்பு முறைமைக்குச் சொந்தம் என்பதில் கிளையண்டும் daemon-உம் உடன்படவில்லை என்பதை உறுதிப்படுத்தியுள்ளீர்கள், அந்த முரண்பாடு மீண்டும் உண்மையான host அடைவு தேவைப்படும் தருணத்தில் திரும்பி வருகிறது.

mount-ஐத் தொடுவதற்கு முன் endpoint-ஐ அச்சிடுங்கள்

பல அமைப்புகள் கிளையண்டை ஒரு endpoint-ஐ நோக்கிக் காட்டலாம், அவை எப்போதும் உடன்படுவதில்லை: --context flag, 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-ஐ மாற்றுவது போன்ற சுரங்கப்பாதை, முன்பு இந்த மடிக்கணினியைக் குறித்த ஒரு பெயரை நிறுவன வலையமைப்பிற்குள் உள்ள முகவரிக்கு அனுப்பலாம்.

உள்ளமைவை அல்ல, நிலையை ஒப்பிடுங்கள். சுரங்கப்பாதை மூடியிருக்கும்போது docker ps -a மற்றும் docker images இயக்குங்கள், பிறகு சுரங்கப்பாதை திறந்திருக்கும்போது மீண்டும். வேறுபட்ட கொள்கலன் பட்டியல் எந்த உள்ளமைவுக் கோப்பையும் விட வலுவான சான்று, ஏனெனில் உங்கள் கோரிக்கைக்கு வேறு daemon பதிலளித்தது என்பதைக் காட்டுகிறது.

பாதை அங்கே உள்ளதா என்று daemon-ஐக் கேளுங்கள்

எந்த daemon-ஐ அடைந்தீர்கள் என்று தெரிந்ததும், அதை அடைவைப் பார்க்கச் சொல்லுங்கள். --mount வடிவம் குறுகிய flag-ஐ விட தெளிவான செய்தியுடன் தோல்வியடைகிறது, ஏனெனில் கொள்கலனைத் தொடங்கும் முன் மூலத்தைச் சரிபார்க்கிறது:

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 கோப்பில் ஒரு உள்ளீட்டை எழுதுகிறது, எனவே கொள்கலன் சுரங்கப்பாதை பற்றி எதையும் கற்றுக்கொள்ளாது, மேலும் முகவரியையும் உறைய வைக்கிறது. உள் host நகரும் போது, யாராவது Compose கோப்பைத் திருத்தும் வரை உள்ளீடு தவறாகவே இருக்கும். நிலையான சாதனத்திற்கோ பொருத்தப்பட்ட தரவுத்தளத்திற்கோ இதைப் பயன்படுத்துங்கள், நகரும் பெயர்களை DNS-க்கு விட்டுவிடுங்கள்.

மீள் நிறுவல் உண்மையில் எதை மாற்றுகிறது

Docker Desktop-ஐ மீண்டும் நிறுவுவது VM, socket மற்றும் context பட்டியலை மீண்டும் உருவாக்குகிறது, mount மீண்டும் வேலை செய்யத் தொடங்குகிறது. அந்த முடிவு உண்மையானது, அது எதையும் கற்பிக்கவில்லை, அதனால்தான் அடுத்த VPN புதுப்பிப்புக்குப் பிறகு அதே தோல்வி திரும்பி வருகிறது. மீள் நிறுவல் கிளையண்ட் பயன்படுத்திய endpoint-ஐ மாற்றியது; உங்கள் திட்டம் பெயரிடும் பாதையை daemon உண்மையில் படிக்கும் கோப்பு முறைமையுடன் அது ஒத்திசைக்கவில்லை.

என் வேலை வரிசை சுருக்கம். கிளையண்ட் எந்த endpoint-ஐப் பயன்படுத்தும் என்பதை உறுதிப்படுத்துங்கள். கொள்கலன் பட்டியல்களை ஒப்பிட்டு எந்த daemon பதிலளித்தது என்பதை உறுதிப்படுத்துங்கள். அந்த daemon-ஐ source path பட்டியலிடச் சொல்லுங்கள். அதன் பிறகுதான் mount-ஐத் திருத்துங்கள், hosts உள்ளீட்டைச் சேர்க்கவும் அல்லது தொகுதி வகையை மாற்றவும். VPN வழியாக வேலை செய்யும் குழுவிற்கு Compose கோப்பைப் பராமரித்தால், daemon வைத்திருக்க வேண்டிய தரவுக்குப் பெயரிடப்பட்ட தொகுதிகளை விரும்புங்கள், அதனால் host path ஒருபோதும் ஒப்பந்தத்தின் பகுதியாகாது.