Atsisiuntimai terminale veikia, bet VS Code plėtiniai nepavyksta per VPN

curl veikia konteineryje, o plėtinys vis tiek neįdiegiamas. Prieš kopijuodami tarpinio serverio nustatymus, palyginkite vietinį redaktorių ir nuotolinę aplinką.

Atsisiuntimai, kurie pavyksta konteinerio terminale, yra tikras to terminalo aplinkos įrodymas. Jie nieko nesako apie redaktoriaus procesą, plėtinių diegiklį ar dvejetainį failą, kurį plėtinys vėliau atsisiunčia. Tarpinio serverio kintamųjų kopijavimas tarp šių trijų vieną nepavykusią užklausą paverčia visu puse dienos nesusijusių pakeitimų.

Dvi aplinkos paprastai skiriasi tiksliai vienu aspektu. Rasti tą aspektą greičiau nei du kartus skaityti tarpinio serverio dokumentaciją.

Kuris procesas atliko nepavykusią užklausą

Vieno diegimo metu gali nepavykti trys užklausos, ir kiekviena turi savo tinklo tapatybę. Redaktorius prašo Marketplace metaduomenų ir paketo URL, tada atsisiunčia paketą. Tik po to plėtinių šeimininkas vykdo kodą, kuris gali atsisiųsti kalbos serverį arba savo dvejetainį failą. Kuri stadija nulūžo, lemia, kuriam procesui reikia tarpinio serverio, o klaidų paviršius tą stadiją retai įvardija.

Veikiantis terminalas įrodo, kad konteineris pasiekia internetą, o ne kad redaktorius jį pasiekia. Perskaitykite plėtinio žurnale paskutinį URL, kurį jis bandė. Ten nurodytas šeimininkas nustato procesą ir jam taikomą politiką.

Vietinis redaktorius ir nuotolinis konteineris yra dvi aplinkos

Nuotolinėje darbo srityje plėtinys vykdomas toje pusėje, kurią deklaruoja jo tipas. Sąsajos plėtiniai lieka prie vietinio redaktoriaus, o darbo srities plėtiniai vykdomi konteineryje. Vienoje nustatytas tarpinis serveris yra nematomas kitai, o perkūrimas sukuria konteinerio aplinką iš jos konfigūracijos failo, o ne iš to, ką eksportavote apvalkale. Šis padalijimas paaiškina, kodėl tas pats plėtinys įdiegiamas nešiojamajame kompiuteryje ir nepavyksta tame pačiame projekte per SSH.

Perskaitykite diegimo vietą prieš ką nors keisdami. Kai žurnalas praneša apie nuotolinį diegimą, svarbi yra konteinerio aplinka.

Įdėkite tarpinį serverį ten, kur prasideda užklausa

Dev Container, kuriam tikrai reikia HTTP tarpinio serverio, kintamasis priklauso konteinerio konfigūracijai, kad perkūrimas jį atkurtų. Toliau pateiktas fragmentas jį nustato tai aplinkai. Pakaitinis adresas reiškia jūsų pačių šliuzą, o išimtys nėra neprivalomas užpildas.

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

Kintamojo pavadinimas apibūdina paskirties protokolą, todėl HTTPS_PROXY reikšmė gali teisėtai prasidėti http. Taikykite pakeitimą palaikomu perkūrimo keliu ir palikite išimtis, nes tarpinis serveris, perimantis vidinius šeimininkus, sugadina paslaugas, kurių konteineriui reikia.

Atskirkite pasitikėjimo klaidas nuo pasiekiamumo

Tarpinis serveris, kuris prisijungia ir tada grąžina sertifikato tikrinimo klaidą, pasiekė vėlesnę stadiją nei tas, kuris atmeta ryšį. Pirmajai klaidai reikia organizacijos patvirtintos pasitikėjimo medžiagos, įdiegtos aplinkoje, kuri atlieka užklausą. Antrajai reikia pasiekiamo adreso ir prievado. Traktuojant juos kaip vieną problemą, gaunamas sprendimas, kuris netinka nė vienam.

Tikrinimo išjungimas arba redaktoriaus paleidimas su išplėstomis teisėmis nėra trūkstamo tarpinio serverio ar trūkstamos pasitikėjimo grandinės taisymas. Abu keičia matomą klaidą į tylą. Paskui bandykite tą patį plėtinį dar kartą ir pažymėkite kitą nepavykstantį URL.

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

Užsirašykite, kuri darbo srities pusė sukūrė tą URL. Trumpa pastaba su stadija, šeimininku ir puse verta daugiau nei kažkieno pakeistų nustatymų sąrašas, nes būtent tą pastabą kitas žmogus gali atkartoti.

Susiję straipsniai