Päätteessä lataaminen toimii, mutta VS Code -laajennukset epäonnistuvat VPN:n takana

curl toimii kontissa, eikä laajennus silti asennu. Vertaa paikallista editoria ja etäympäristöä ennen välityspalvelimen asetusten kopioimista.

Kontin päätteessä onnistuvat lataukset ovat todellista näyttöä kyseisen päätteen ympäristöstä. Ne eivät kerro mitään editorin prosessista, laajennusasentajasta tai binaaritiedostosta, jonka laajennus noutaa myöhemmin. Välityspalvelinmuuttujien kopioiminen näiden kolmen välillä muuttaa yhden epäonnistuneen pyynnön kokonaiseksi iltapäiväksi asiaan liittymättömiä muokkauksia.

Kaksi ympäristöä eroavat yleensä täsmälleen yhdessä suhteessa. Tuon suhteen löytäminen on nopeampaa kuin välityspalvelimen dokumentaation lukeminen kahdesti.

Mikä prosessi teki epäonnistuneen pyynnön

Yhden asennuksen aikana voi epäonnistua kolme pyyntöä, ja jokaisella on oma verkkoidentiteettinsä. Editori pyytää Marketplacelta metatiedot ja paketin URL-osoitteen ja lataa sitten paketin. Vasta sen jälkeen laajennusisäntä suorittaa koodia, joka voi noutaa kielipalvelimen tai oman binaaritiedostonsa. Mikä vaihe katkesi, ratkaisee, mikä prosessi tarvitsee välityspalvelinta, eikä virhepinta juuri nimeä vaihetta.

Toimiva pääte todistaa, että kontti pääsee internetiin, ei että editori pääsee. Lue laajennuksen lokista viimeinen URL, jota se yritti. Siellä nimetty isäntä tunnistaa prosessin ja siihen sovellettavan käytännön.

Paikallinen editori ja etäkontti ovat kaksi ympäristöä

Etätyötilassa laajennus toimii sillä puolella, jonka sen tyyppi ilmoittaa. Käyttöliittymälaajennukset pysyvät paikallisen editorin luona ja työtilalaajennukset toimivat kontissa. Toiseen asetettu välityspalvelin on näkymätön toiselle, ja uudelleenrakennus luo kontin ympäristön sen asetustiedostosta eikä siitä, mitä vientitit komentotulkissa. Tämä jako selittää, miksi sama laajennus asentuu kannettavaan tietokoneeseen ja epäonnistuu samassa projektissa SSH:n yli.

Lue asennuspaikka ennen kuin muutat mitään. Kun loki ilmoittaa etäasennuksesta, kontin ympäristö on se, jolla on merkitystä.

Sijoita välityspalvelin sinne, missä pyyntö alkaa

Dev Containerille, joka todella tarvitsee HTTP-välityspalvelimen, muuttuja kuuluu kontin asetuksiin, jotta uudelleenrakennus toistaa sen. Alla oleva katkelma asettaa sen kyseiselle ympäristölle. Paikkamerkki osoite edustaa omaa yhdyskäytävääsi, eivätkä poikkeukset ole valinnaista täytettä.

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

Muuttujan nimi kuvaa kohdeprotokollaa, joten HTTPS_PROXY-arvo voi laillisesti alkaa http:llä. Käytä muutos tuetun uudelleenrakennuspolun kautta ja pidä poikkeukset, koska sisäisiä isäntiä sieppaava välityspalvelin rikkoo palveluita, joita kontti tarvitsee.

Erota luottamusvirheet tavoitettavuudesta

Välityspalvelin, joka yhdistää ja palauttaa sitten varmenteen tarkistusvirheen, on edennyt myöhempään vaiheeseen kuin yhden yhteyden hylkäävä. Ensimmäinen virhe vaatii organisaation hyväksymän luottamusmateriaalin asennettuna ympäristöön, joka tekee pyynnön. Toinen vaatii tavoitettavan osoitteen ja portin. Niiden käsitteleminen yhtenä ongelmana tuottaa korjauksen, joka ei toimi kummallekaan.

Tarkistuksen poistaminen käytöstä tai editorin ajaminen korotetuilla oikeuksilla ei ole korjaus puuttuvalle välityspalvelimelle tai puuttuvalle luottamusketjulle. Molemmat vaihtavat näkyvän virheen hiljaiseen. Yritä sen jälkeen samaa laajennusta uudelleen ja kirjaa seuraava URL, joka epäonnistuu.

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

Kirjaa, kumpi työtilan puoli tuotti tuon URL:n. Lyhyt muistiinpano, joka nimeää vaiheen, isännän ja puolen, on arvokkaampi kuin luettelo jonkun muuttamista asetuksista, koska juuri sen muistiinpanon seuraava henkilö voi toistaa.

Aiheeseen liittyvät artikkelit