Shkarkimet në terminal funksionojnë, por shtesat e VS Code dështojnë përmes VPN

Shkarkimet që ia dalin në terminalin e kontejnerit janë provë e vërtetë për mjedisin e atij terminali. Ato nuk thonë asgjë për procesin e redaktorit, instaluesin e shtesave apo skedarin binar që një shtesë merr më pas. Kopjimi i variablave të proxy-t midis këtyre tre e kthen një kërkesë të dështuar në një pasdite të tërë ndryshimesh të palidhura.

Dy mjedise zakonisht ndryshojnë saktësisht në një aspekt. Gjetja e atij aspekti është më e shpejtë sesa leximi dy herë i dokumentacionit të proxy-t.

Cili proces e bëri kërkesën e dështuar

Tre kërkesa mund të dështojnë gjatë një instalimi të vetëm, dhe secila ka identitetin e vet të rrjetit. Redaktori i kërkon Marketplace-it metadatat dhe një URL pakete, pastaj shkarkon paketën. Vetëm pas kësaj hosti i shtesave ekzekuton kod që mund të marrë një server gjuhe ose skedarin e vet binar. Cila fazë u thye vendos cili proces ka nevojë për proxy, dhe sipërfaqja e gabimit rrallë e emërton fazën.

Një terminal që punon provon se kontejneri mund të arrijë internetin, jo se redaktori mundet. Lexoni regjistrin e shtesës për URL-në e fundit që provoi. Hosti i emërtuar atje identifikon procesin dhe politikën që zbatohet për të.

Redaktori lokal dhe kontejneri në distancë janë dy mjedise

Në një hapësirë pune në distancë një shtesë ekzekutohet në anën që deklaron lloji i saj. Shtesat e ndërfaqes qëndrojnë me redaktorin lokal, dhe shtesat e hapësirës së punës ekzekutohen në kontejner. Një proxy i vendosur në njërën është i padukshëm për tjetrën, dhe një rindërtim e rikrijon mjedisin e kontejnerit nga skedari i tij i konfigurimit, jo nga ajo që eksportuat në një shell. Kjo ndarje shpjegon përse e njëjta shtesë instalohet në një laptop dhe dështon në të njëjtin projekt përmes SSH.

Lexoni vendndodhjen e instalimit përpara se të ndryshoni çdo gjë. Kur regjistri raporton një instalim në distancë, mjedisi i kontejnerit është ai që ka rëndësi.

Vendosni proxy-n aty ku fillon kërkesa

Për një Dev Container që ka vërtet nevojë për një proxy HTTP, variabla i përket konfigurimit të kontejnerit, që një rindërtim ta riprodhojë atë. Fragmenti më poshtë e vendos atë për atë mjedis. Adresa e mbajtësit të vendit përfaqëson portën tuaj, dhe përjashtimet nuk janë mbushje opsionale.

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

Emri i variablës përshkruan protokollin e destinacionit, kështu që një vlerë HTTPS_PROXY mund të fillojë ligjërisht me http. Zbatojeni ndryshimin përmes rrugës së mbështetur të rindërtimit dhe mbani përjashtimet, sepse një proxy që përgjon hoste të brendshme prish shërbimet që kontejneri ka nevojë.

Ndani dështimet e besimit nga arritshmëria

Një proxy që lidhet dhe pastaj kthen një gabim verifikimi certifikate ka arritur një fazë më të vonë sesa ai që refuzon lidhjen. Dështimi i parë kërkon materialin e besimit të miratuar nga organizata, të instaluar në mjedisin që bën kërkesën. I dyti kërkon një adresë dhe portë të arritshme. Trajtimi i tyre si një problem i vetëm prodhon një rregullim që nuk funksionon për asnjërin.

Çaktivizimi i verifikimit, ose ekzekutimi i redaktorit me të drejta të larta, nuk është riparim për një proxy që mungon ose një zinxhir besimi që mungon. Të dyja shkëmbejnë një gabim të dukshëm me një të heshtur. Provoni përsëri të njëjtën shtesë më pas dhe shënoni URL-në tjetër që dështon.

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

Shënoni cila anë e hapësirës së punës e prodhoi atë URL. Një shënim i shkurtër me fazën, hostin dhe anën vlen më shumë se një listë cilësimesh që dikush ndryshoi, sepse pikërisht atë shënim personi tjetër mund ta riprodhojë.