VPN வழியாக docker pull: டீமனுக்கு அதன் சொந்த பிணையம் உள்ளது

உங்கள் மடிக்கணினி நிறுவன VPN-இல் உள்ளது, curl உள் பதிவேட்டை அடைகிறது, இருந்தும் docker pull EOF-உடன் தோல்வியடைகிறது. இந்தக் கலவை முரண்பாடு அல்ல. நீங்கள் தட்டச்சு செய்த கட்டளை உங்கள் ஷெல்லில் இயங்குகிறது, ஆனால் பரிமாற்றம் Docker CLI தேர்ந்தெடுத்த டீமனுக்குள் இயங்குகிறது, அந்த டீமன் முற்றிலும் வேறு ஹோஸ்ட்டில் இருக்கலாம். அதன் பிணையப் பாதையே வேலை செய்ய வேண்டும், அதன் ப்ராக்ஸி அமைப்புகளே பொருந்தும்.

பாதையல்ல, என்ஜினை அடையாளம் காண்பதில் தொடங்குங்கள்

docker context show மற்றும் docker version இயக்கவும். பதிப்பு வெளியீடு ஒரு கிளையண்ட் பகுதியையும் ஒரு சேவையகப் பகுதியையும் அச்சிடுகிறது, சேவையகத் தொகுதி யார் பதிலளித்தது என்று சொல்கிறது: உள்ளூர் சொந்த என்ஜின், Docker Desktop மெய்நிகர் இயந்திரம், அல்லது தொலை இயந்திரத்தில் உள்ள டீமன். உறுதியாக இருக்க விரும்பினால் docker context inspect தேர்ந்தெடுக்கப்பட்ட சூழலின் இறுதிப் புள்ளியைக் காட்டும், இந்தக் கட்டளைகளில் எதுவும் எதையும் மாற்றாது.

DOCKER_HOST போன்ற சூழல் மாறி CLI-ஐ நீங்கள் கருதுவதை விட வேறு என்ஜினை நோக்கி அமைதியாக வழிநடத்தலாம், மடிக்கணினி VPN-இல் இருப்பது போல் தோன்றியும் இழுப்பு வேறு இடத்திற்குச் செல்வதற்கு இதுவே வழக்கமான விளக்கம்.

டீமனுக்கு அதற்கேயுரிய பிணைய அடையாளம் உள்ளது

தொலை என்ஜினுக்கு தனியார் பதிவேட்டிற்கு அதன் சொந்த அனுமதிக்கப்பட்ட பாதை தேவை. உங்கள் மடிக்கணினியின் VPN கிளையண்டை இணைப்பது அந்த மடிக்கணினிக்கு ஒரு பாதையைத் தருகிறது; ஆய்வகத்திலோ மேக சப்நெட்டிலோ இருக்கும் டீமனுக்கு அதே தனியார் முகவரியைத் தராது. என்ஜின் Docker Desktop ஆக இருந்தால், இழுப்பு அதன் மெய்நிகர் இயந்திரத்திற்குள் நடைபெறுகிறது, அதற்கு உங்கள் ஷெல் சூழலிலிருந்து தனித்த அதற்கேயுரிய பிணையம் மற்றும் ப்ராக்ஸி உள்ளமைவு உள்ளது.

அதனால்தான் ஹோஸ்ட்டில் வெற்றிகரமான curl ஹோஸ்ட்டைப் பற்றிய சான்று மட்டுமே, அதற்கு மேல் ஒன்றுமில்லை.

பதிவேட்டுடன் எந்தப் பரிமாற்றம் முடிந்தது என்பதைக் கண்டறியுங்கள்

பட இழுப்பு ஒரு வரிசை: அங்கீகாரம், மேனிஃபெஸ்ட் பெறுதல், பின்னர் பெரும்பாலும் பொருள் சேமிப்பகத்திற்கோ CDN இறுதிப் புள்ளிக்கோ திருப்பிவிடப்படும் blob பரிமாற்றங்கள். வெற்றிகரமான docker login முதல் படிநிலையை மட்டுமே நிரூபிக்கிறது, திருப்பிவிடப்பட்ட blob ஹோஸ்ட் டீமனின் பிணையத்திலிருந்து அடைய முடியாததாக இருந்தாலும் டோக்கன் முழுமையாக செல்லுபடியாக இருக்கலாம். எதையும் மாற்றும் முன் சரியான நேரம், படச் சுட்டி மற்றும் டீமன் அல்லது கிளையண்ட் பதிவின் முதல் பயனுள்ள நிகழ்வைப் பதிவு செய்யுங்கள்.

EOF தனியாக எந்தக் காரணத்தையும் குறிப்பிடவில்லை. அது துண்டிக்கப்பட்ட இணைப்பு, ஸ்ட்ரீமை விட்டுவிட்ட ப்ராக்ஸி, காலாவதி அல்லது MTU சிக்கலாக இருக்கலாம், நேர முத்திரையிட்ட நிகழ்வு இல்லாமல் அவற்றுக்கிடையே ஊகிப்பதே ஆரோக்கியமான என்ஜினை மீண்டும் கட்டமைக்கும் வழி. கிளையண்ட் வெளியீட்டில் உள்ள பைட் ஆஃப்செட்டை தரவாகக் கருதுங்கள், ஏனெனில் ஒவ்வொரு முறையும் ஒரே அளவில் நிற்கும் பரிமாற்றம் ஒருபோதும் தொடங்காத ஒன்றிலிருந்து முற்றிலும் வேறுபட்ட விலங்கு. இரண்டு முடிவுகளையும் பதிவு செய்து முயற்சிகளுக்கிடையே ஒப்பிடுங்கள்.

பரிமாற்றம் செய்யும் கூறை உள்ளமைக்கவும்

சொந்த Linux என்ஜினுக்கு ப்ராக்ஸி சேவை சூழலில் இருக்கும், உங்கள் ஷெல்லில் அல்ல. /etc/systemd/system/docker.service.d/ கீழ் HTTP_PROXY, HTTPS_PROXY மற்றும் NO_PROXY உள்ளீடுகளுடன் கூடிய drop-in கோப்பு, அதைத் தொடர்ந்து systemctl daemon-reload மற்றும் மறுதொடக்கம், இதுவே ஆவணப்படுத்தப்பட்ட ஏற்பாடு. Docker Desktop அதே மதிப்புகளை அதன் சொந்த அமைப்புகள் மூலம் வெளிப்படுத்துகிறது, ஷெல் சுயவிவரத்தைத் திருத்துவது அவற்றில் எதையும் தொடாது.

பதிவேட்டை நேரடியாக VPN வழியாக அடைய வேண்டுமானால், டீமனுக்கு தீர்வி, பாதை மற்றும் வேண்டுமென்றே செய்யப்பட்ட ப்ராக்ஸி விலக்கு தேவை, விலக்கு மட்டும் அல்ல. NO_PROXY பொருத்தம் ஒவ்வொரு கூறுக்கும் சரம் ஒப்பீடு, அடிப்படைப் பாதை இல்லாத விலக்கு ப்ராக்ஸி சிக்கலைப் போலத் தோன்றும் தோல்வியை உருவாக்குகிறது.

நிறுவன TLS ஆய்வு அனுமதிக்கப்பட்ட பாதையில் இருக்கும்போது, அதன் சரிபார்க்கப்பட்ட வேர்க்கட்டியை என்ஜின் அல்லது Desktop பணிப்பாய்வு மூலம் நிறுவுங்கள். பதிவேட்டை insecure-registries-இல் சேர்ப்பது சரிபார்ப்பை முடக்கும் வேறு மாற்றம், அது நம்பிக்கைச் சேமிப்பக உள்ளமைவு அல்ல.

ஒரு கட்டுப்படுத்தப்பட்ட இழுப்பை மீண்டும் செய்து என்ன மாறியது எனப் பாருங்கள்

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

build படிநிலைகளுக்கும் இயங்கும் கொள்கலன்களுக்கும் அவற்றுக்கேயுரிய பிணைய சூழல்கள் உள்ளன, எனவே இழுப்பு தானே வேலை செய்த பிறகு அவற்றைத் தனித்தனி கேள்விகளாகக் கருதுங்கள்.