ടെർമിനലിലെ ഡൗൺലോഡുകൾ പ്രവർത്തിക്കുന്നു, പക്ഷേ 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 ഉണ്ടാക്കിയതെന്ന് രേഖപ്പെടുത്തുക. ഘട്ടം, ഹോസ്റ്റ്, വശം എന്നിവ പേരെടുത്ത് പറയുന്ന ചെറിയ കുറിപ്പ്, ആരോ മാറ്റിയ ക്രമീകരണങ്ങളുടെ പട്ടികയേക്കാൾ മൂല്യമുള്ളതാണ്, കാരണം അടുത്ത വ്യക്തിക്ക് പുനരുൽപ്പാദിപ്പിക്കാനാകുന്നത് ആ കുറിപ്പാണ്.