Lejupielādes terminālī darbojas, bet VS Code paplašinājumi neizdodas ar VPN

Lejupielādes, kas izdodas konteinera terminālī, ir īsts pierādījums par šī termināļa vidi. Tās neko nepasaka par redaktora procesu, paplašinājumu instalētāju vai bināro failu, ko paplašinājums pēc tam lejupielādē. Starpniekservera mainīgo kopēšana starp šiem trim vienu neizdevušos pieprasījumu pārvērš veselā pēcpusdienā ar nesaistītiem labojumiem.

Divas vides parasti atšķiras tieši vienā aspektā. Šo aspektu atrast ir ātrāk nekā divreiz lasīt starpniekservera dokumentāciju.

Kurš process veica neizdevušos pieprasījumu

Vienas instalācijas laikā var neizdoties trīs pieprasījumi, un katram ir sava tīkla identitāte. Redaktors pieprasa Marketplace metadatus un pakotnes URL, pēc tam lejupielādē pakotni. Tikai pēc tam paplašinājumu resursdators izpilda kodu, kas var iegūt valodas serveri vai savu bināro failu. Kurš posms salūza, nosaka, kuram procesam vajag starpniekserveri, un kļūdu virsma šo posmu reti nosauc.

Strādājošs terminālis pierāda, ka konteiners var sasniegt internetu, nevis ka to var redaktors. Izlasiet paplašinājuma žurnālā pēdējo URL, ko tas mēģināja. Tur nosauktais resursdators identificē procesu un tam piemērojamo politiku.

Vietējais redaktors un attālais konteiners ir divas vides

Attālā darba telpā paplašinājums darbojas tajā pusē, kuru deklarē tā tips. Saskarnes paplašinājumi paliek pie vietējā redaktora, un darba telpas paplašinājumi darbojas konteinerī. Vienā iestatīts starpniekserveris ir neredzams otrai, un pārbūve izveido konteinera vidi no tā konfigurācijas faila, nevis no tā, ko eksportējāt čaulā. Šī šķelšanās izskaidro, kāpēc viens un tas pats paplašinājums instalējas klēpjdatorā un neizdodas tajā pašā projektā caur SSH.

Izlasiet instalācijas vietu, pirms kaut ko maināt. Kad žurnāls ziņo par attālu instalāciju, svarīga ir konteinera vide.

Novietojiet starpniekserveri tur, kur sākas pieprasījums

Dev Container, kuram patiešām vajag HTTP starpniekserveri, mainīgais pieder konteinera konfigurācijai, lai pārbūve to atjaunotu. Tālāk esošais fragments to iestata šai videi. Viettura adrese apzīmē jūsu pašu vārteju, un izņēmumi nav obligāta pildviela.

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

Mainīgā nosaukums apraksta galamērķa protokolu, tāpēc HTTPS_PROXY vērtība var likumīgi sākties ar http. Piemērojiet izmaiņas atbalstītajā pārbūves ceļā un saglabājiet izņēmumus, jo starpniekserveris, kas pārtver iekšējos resursdatorus, sabojā pakalpojumus, kas konteineram nepieciešami.

Atdaliet uzticēšanās kļūmes no sasniedzamības

Starpniekserveris, kas izveido savienojumu un pēc tam atgriež sertifikāta pārbaudes kļūdu, ir sasniedzis vēlāku posmu nekā tas, kas savienojumu noraida. Pirmajai kļūmei nepieciešams organizācijas apstiprinātais uzticēšanās materiāls, kas instalēts vidē, kura veic pieprasījumu. Otrajai nepieciešama sasniedzama adrese un ports. Uzskatot tās par vienu problēmu, tiek iegūts labojums, kas neder nevienai.

Pārbaudes izslēgšana vai redaktora palaišana ar paaugstinātām tiesībām nav trūkstoša starpniekservera vai trūkstošas uzticēšanās ķēdes labojums. Abi apmaina redzamu kļūdu pret klusu. Pēc tam mēģiniet to pašu paplašinājumu vēlreiz un atzīmējiet nākamo URL, kas neizdodas.

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

Pierakstiet, kura darba telpas puse izveidoja šo URL. Īsa piezīme ar posmu, resursdatoru un pusi ir vērtīgāka par kāda mainītu iestatījumu sarakstu, jo tieši šo piezīmi nākamais cilvēks var atkārtot.