Nedlastingar i terminalen verkar, men VS Code-utvidingar feilar på VPN

curl verkar i containeren, og utvidinga blir framleis ikkje installert. Samanlikn den lokale editoren og fjernmiljøet før du kopierer proxyinnstillingar.

Nedlastingar som lykkast i terminalen til containeren, er reelt prov på miljøet til den terminalen. Dei seier ingenting om editorprosessen, utvidingsinstallasjonen eller binærfilen ei utviding hentar etterpå. Å kopiere proxyvariablar mellom desse tre gjer éin mislukka førespurnad til ein heil ettermiddag med urelaterte endringar.

To miljø skil seg vanlegvis i nøyaktig éin henseande. Å finne den henseanden er raskare enn å lese proxydokumentasjonen to gonger.

Kva prosess sende den mislukka førespurnaden

Tre førespurnader kan feile under éin installasjon, og kvar har sin eigen nettverksidentitet. Editoren ber Marketplace om metadata og ein pakke-URL og lastar deretter ned pakken. Først etterpå køyrer utvidingsverten kode som kan hente ein språkserver eller sin eigen binærfil. Kva trinn som braut, avgjer kva prosess som treng ein proxy, og feilflata namngjev sjeldan trinnet.

Ein fungerande terminal provar at containeren kan nå internett, ikkje at editoren kan. Les utvidingsloggen for den siste URL-en han prøvde. Verten som er nemnd der, identifiserer prosessen og retningslinja som gjeld for han.

Lokal editor og ekstern container er to miljø

I eit eksternt arbeidsområde køyrer ei utviding på sida som typen hennar erklærer. Grensesnittutvidingar blir hos den lokale editoren, og arbeidsområdeutvidingar køyrer i containeren. Ein proxy sett i den eine er usynleg for den andre, og ein gjenoppbygging gjenskapar miljøet til containeren frå konfigurasjonsfila i staden for frå det du eksporterte i eit skal. Denne delinga forklarar kvifor den same utvidinga blir installert på ein berbar PC og feilar i det same prosjektet over SSH.

Les installasjonsstaden før du endrar noko. Når loggen rapporterer ein ekstern installasjon, er det miljøet til containeren som tel.

Set proxyen der førespurnaden startar

For ein Dev Container som verkeleg treng ein HTTP-proxy, høyrer variabelen heime i containerkonfigurasjonen slik at ein gjenoppbygging gjenskapar han. Utdraget nedanfor set han for det miljøet. Plasshaldaradressa står for din eigen gateway, og unntaka er ikkje valfri utfylling.

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

Variabelnamnet skildrar destinasjonsprotokollen, så ein HTTPS_PROXY-verdi kan lovleg byrje med http. Bruk endringa gjennom den støtta gjenoppbyggingsvegen, og hald på unntaka, fordi ein proxy som fangar interne vertar, øydelegg tenester containeren treng.

Skil tillitsfeil frå tilgjenge

Ein proxy som koplar til og deretter returnerer ein sertifikatverifiseringsfeil, har nådd eit seinare trinn enn ein som avviser tilkoplinga. Den første feilen vil ha organisasjonen sitt godkjende tillitsmateriale installert i miljøet som utfører førespurnaden. Den andre vil ha ei tilgjengeleg adresse og port. Blir dei handsama som eitt problem, gir det ei løysing som ikkje verkar for nokon av dei.

Å deaktivere verifisering eller køyre editoren med forhøgde rettar er ikkje ein reparasjon for ein manglande proxy eller ei manglande tillitskjede. Begge byter ein synleg feil mot ein stille. Prøv den same utvidinga igjen etterpå og noter den neste URL-en som feilar.

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

Noter kva side av arbeidsområdet som produserte den URL-en. Eit kort notat som namngjev trinnet, verten og sida er meir verdt enn ei liste over innstillingar nokon har endra, fordi nettopp det notatet kan den neste personen gjenskape.

Relaterte artiklar