Downloads yn 'e terminal wurkje, mar VS Code-útwreidings mislearje op VPN

curl wurket yn 'e container en de útwreiding installaasje noch altyd net. Ferlykje de lokale bewurker en de fiere omjouwing foardat jo proxy-ynstellingen kopiearje.

Downloads dy't slagje yn 'e terminal fan 'e container binne echte bewiis oer de omjouwing fan dy terminal. Se sizze neat oer it bewurkerproses, de útwreidingsynstallearder of it binariese bestân dat in útwreiding dêrnei hellet. Proxy-fariabelen tusken dy trije kopiearje feroaret ien mislearre fersyk yn in hiele middei fan net-relatearre bewurkings.

Twa omjouwings ferskille meastentiids krekt op ien punt. Dat punt fine is flugger as de proxydokumintaasje twa kear lêze.

Hokker proses die it mislearre fersyk

Trije fersiken kinne mislearje by ien ynstallaasje, en elk hat syn eigen netwurkidentiteit. De bewurker freget it Marketplace om metadata en in pakket-URL, en downloadt dan it pakket. Pas dêrnei fiert de útwreidingshost koade út dy't in taalserver of syn eigen binariese bestân helje kin. Hokker stap bruts, bepaalt hokker proses in proxy nedich hat, en it flak fan 'e flater neamt de stap selden.

In wurkjende terminal bewiist dat de container it ynternet berikke kin, net dat de bewurker dat kin. Lês it útwreidingslog foar de lêste URL dy't it besocht. De host dy't dêr neamd wurdt, identifisearret it proses en it belied dat dêrfoar jildt.

Lokale bewurker en fiere container binne twa omjouwings

Yn in fiere wurkromte rint in útwreiding oan 'e kant dy't syn type ferklearret. Ynterface-útwreidings bliuwe by de lokale bewurker, en wurkromte-útwreidings rinne yn 'e container. In proxy dy't yn 'e iene set is, is ûnsichtber foar de oare, en in weropbou makket de containeromjouwing út syn konfiguraasjebestân, net út wat jo yn in shell eksportearre hawwe. Dy splitsing ferklearret wêrom deselde útwreiding op in laptop ynstallearret en yn itselde projekt fia SSH mislearret.

Lês de ynstallaasjelokaasje foardat jo eat bewurkje. As it log in fiere ynstallaasje meldt, is de omjouwing fan 'e container dy't ta saak docht.

Set de proxy dêr't it fersyk begjint

Foar in Dev Container dy't echt in HTTP-proxy nedich hat, heart de fariabele yn 'e containerkonfiguraasje, sadat in weropbou him reproduisearret. It fragmint hjirûnder set him foar dy omjouwing. It plakferfangeradres stiet foar jo eigen gateway, en de útslutingen binne gjin opsjonele opfolstoffs.

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

De namme fan 'e fariabele beskriuwt it bestimmingsprotokol, dus in HTTPS_PROXY-wearde mei legitimaal mei http begjinne. Pas de feroaring ta fia it stipe weropboupad, en behâld de útslutingen, want in proxy dy't ynterne hosts ûnderskept, brekt tsjinsten dy't de container nedich hat.

Skied fertrouwensflaters fan berikberens

In proxy dy't ferbynt en dan in sertifikaatferifikaasjeflater jout, hat in lettere stap berikt as ien dy't de ferbining wegeret. De earste flater wol it goedkarde fertrouwensmateriaal fan 'e organisaasje ynstalleare yn 'e omjouwing dy't it fersyk docht. De twadde wol in berikber adres en poarte. As jo se as ien probleem behannelje, krij jo in oplossing dy't foar gjin fan beide wurket.

Ferifikaasje útsette, of de bewurker mei ferhege rjochten rinne litte, is gjin reparaasje foar in ûntbrekkende proxy of in ûntbrekkende fertrouwensketen. Beide ruilje in sichtbere flater foar in stille. Besykje dêrnei deselde útwreiding op 'e nij en notearje de folgjende URL dy't mislearret.

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

Notearje hokker kant fan 'e wurkromte dy URL produsearre hat. In koarte nota mei de stap, de host en de kant is mear wurdich as in list ynstellingen dy't immen feroare hat, want dy nota is wat de folgjende persoan reprodusearje kin.

Relatearre artikelen