Terminali allalaadimised töötavad, kuid VS Code’i laiendused ei õnnestu VPN-i taga

curl töötab konteineris ja laiendus ei paigaldu ikkagi. Enne puhverserveri seadete kopeerimist võrrelge kohalikku redaktorit ja kaugkeskkonda.

Konteinuri terminalis õnnestuvad allalaadimised on tõeline tõend selle terminali keskkonna kohta. Need ei ütle midagi redaktori protsessi, laienduste paigaldaja ega binaarfaili kohta, mille laiendus hiljem alla laadib. Puhverserveri muutujate kopeerimine nende kolme vahel muudab ühe ebaõnnestunud päringu terveks pärastlõunaks asjassepuutumatuteks muudatusteks.

Kaks keskkonda erinevad tavaliselt täpselt ühes aspektis. Selle aspekti leidmine on kiirem kui puhverserveri dokumentatsiooni kaks korda lugemine.

Milline protsess tegi ebaõnnestunud päringu

Ühe paigalduse käigus võivad ebaõnnestuda kolm päringut ja igaühel on oma võrguidentiteet. Redaktor küsib Marketplace'ilt metaandmeid ja paketi URL-i, seejärel laadib paketi alla. Alles pärast seda käivitab laienduste host koodi, mis võib alla laadida keeleserveri või oma binaarfaili. Katki läinud etapp otsustab, milline protsess vajab puhverserverit, ja veapind nimetab seda etappi harva.

Töötav terminal tõestab, et konteiner pääseb internetti, mitte et redaktor pääseb. Lugege laienduse logist viimast URL-i, mida see proovis. Seal nimetatud host tuvastab protsessi ja sellele kohalduva poliitika.

Kohalik redaktor ja kaugkonteiner on kaks keskkonda

Kaugtööruumis töötab laiendus sellel poolel, mille selle tüüp deklareerib. Liidese laiendused jäävad kohaliku redaktori juurde ja tööruumi laiendused töötavad konteineris. Ühes seadistatud puhverserver on teise jaoks nähtamatu ning ümberehitus loob konteineri keskkonna selle konfiguratsioonifailist, mitte sellest, mida te kestas eksportisite. See jaotus selgitab, miks sama laiendus paigaldub sülearvutisse ja ebaõnnestub samas projektis SSH kaudu.

Lugege paigalduskohta enne, kui midagi muudate. Kui log teatab kaugpaigaldusest, on määrav konteineri keskkond.

Pange puhverserver sinna, kus päring algab

Dev Containeri puhul, mis tõesti vajab HTTP-puhverserverit, kuulub muutuja konteineri konfiguratsiooni, et ümberehitus selle taastoodaks. Allolev lõik seab selle selle keskkonna jaoks. Kohatäiteaadress esindab teie enda lüüsi ja erandid ei ole valikuline täidis.

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

Muutuja nimi kirjeldab sihtprotokolli, seega võib HTTPS_PROXY väärtus seaduslikult alata http-ga. Rakendage muudatus toetatud ümberehitustee kaudu ja hoidke erandid alles, sest sisemisi hoste püüdv puhverserver rikub teenuseid, mida konteiner vajab.

Eraldage usalduse tõrked kättesaadavusest

Puhverserver, mis ühendub ja seejärel tagastab sertifikaadi kontrollimise vea, on jõudnud hilisemasse etappi kui see, mis ühendusest keeldub. Esimene tõrge vajab organisatsiooni kinnitatud usaldusmaterjali, mis on paigaldatud päringut teostavasse keskkonda. Teine vajab kättesaadavat aadressi ja porti. Nende käsitlemine ühe probleemina annab paranduse, mis ei tööta kummagi jaoks.

Kontrollimise väljalülitamine või redaktori käivitamine kõrgendatud õigustega ei ole puuduva puhverserveri ega puuduva usaldusahela parandus. Mõlemad vahetavad nähtava vea vaikse vastu. Proovige seejärel sama laiendust uuesti ja märkige üles järgmine URL, mis ebaõnnestub.

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

Märkige üles, milline tööruumi pool selle URL-i tekitas. Lühike märkus, mis nimetab etapi, hosti ja poole, on väärtuslikum kui nimekiri seadetest, mida keegi muutis, sest just seda märkust saab järgmine inimene korrata.

Seotud artiklid