டெர்மினலில் பதிவிறக்கங்கள் வேலை செய்கின்றன, ஆனால் VPN-ல் VS Code நீட்டிப்புகள் தோல்வியடைகின்றன

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

இரண்டு சூழல்கள் பொதுவாக சரியாக ஒரு விஷயத்தில் வேறுபடுகின்றன. அந்த விஷயத்தைக் கண்டுபிடிப்பது ப்ராக்ஸி ஆவணங்களை இரண்டு முறை படிப்பதை விட வேகமானது.

எந்த செயல்முறை தோல்வியடைந்த கோரிக்கையைச் செய்தது

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

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

உள்ளூர் எடிட்டரும் தொலை கெண்டெய்னரும் இரண்டு சூழல்கள்

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

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

கோரிக்கை தொடங்கும் இடத்தில் ப்ராக்ஸியை வையுங்கள்

உண்மையிலேயே HTTP ப்ராக்ஸி தேவைப்படும் Dev Container-க்கு, மாறி கெண்டெய்னர் உள்ளமைவில் இருக்க வேண்டும், அதனால் மறுகட்டுமானம் அதை மீண்டும் உருவாக்கும். கீழே உள்ள பகுதி அதை அந்தச் சூழலுக்கு அமைக்கிறது. இடம்காட்டி முகவரி உங்கள் சொந்த நுழைவாயிலைக் குறிக்கிறது, விலக்குகள் கட்டாயமற்ற நிரப்பு அல்ல.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

மாறியின் பெயர் இலக்கு நெறிமுறையை விவரிக்கிறது, எனவே HTTPS_PROXY மதிப்பு சட்டப்படி http-வுடன் தொடங்கலாம். ஆதரிக்கப்படும் மறுகட்டுமான பாதை வழியாக மாற்றத்தைப் பயன்படுத்துங்கள், விலக்குகளை வைத்திருங்கள், ஏனெனில் உள் ஹோஸ்ட்களைத் தடுக்கும் ப்ராக்ஸி கெண்டெய்னருக்குத் தேவையான சேவைகளை உடைக்கிறது.

நம்பிக்கைத் தோல்விகளை அணுகல்தன்மையிலிருந்து பிரியுங்கள்

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

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

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

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