As descargas no terminal funcionan, pero as extensións de VS Code fallan coa VPN

curl funciona no contedor e a extensión segue sen instalarse. Compare o editor local e a contorna remota antes de copiar a configuración do proxy.

As descargas que teñen éxito no terminal do contedor son unha proba real da contorna dese terminal. Non din nada sobre o proceso do editor, o instalador de extensións nin o binario que unha extensión descarga despois. Copiar as variables de proxy entre eses tres converte unha solicitude fallida nunha tarde enteira de cambios non relacionados.

Dúas contornas adoitan diferir exactamente nun aspecto. Atopar ese aspecto é máis rápido que ler dúas veces a documentación do proxy.

Que proceso fixo a solicitude fallida

Tres solicitudes poden fallar durante unha soa instalación, e cada unha ten a súa propia identidade de rede. O editor pide ao Marketplace os metadatos e un URL do paquete, e despois descarga o paquete. Só despois diso o host de extensións executa código que pode descargar un servidor de linguaxe ou un binario propio. A etapa que se rompeu decide que proceso necesita un proxy, e a superficie de erro raramente nomea esa etapa.

Un terminal que funciona demostra que o contedor pode chegar a internet, non que o editor poida. Lea o rexistro da extensión para ver o último URL que intentou. O host que aparece alí identifica o proceso e a política que se lle aplica.

O editor local e o contedor remoto son dúas contornas

Nun espazo de traballo remoto unha extensión execútase no lado que declara o seu tipo. As extensións de interface quedan co editor local, e as extensións de espazo de traballo execútanse no contedor. Un proxy definido nun é invisible para o outro, e unha reconstrución recrea a contorna do contedor a partir do seu ficheiro de configuración en lugar do que exportase nun shell. Esa división explica por que a mesma extensión se instala nun portátil e falla no mesmo proxecto por SSH.

Lea a localización da instalación antes de editar calquera cousa. Cando o rexistro informa dunha instalación remota, a contorna do contedor é a que importa.

Poña o proxy onde comeza a solicitude

Para un Dev Container que realmente necesita un proxy HTTP, a variable pertence á configuración do contedor para que unha reconstrución a reproduza. O fragmento seguinte establécena para esa contorna. O enderezo de marcador de posición substitúe a súa propia pasarela, e as exclusións non son recheo opcional.

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

O nome da variable describe o protocolo de destino, así que un valor HTTPS_PROXY pode comezar lexitimamente por http. Aplique o cambio pola ruta de reconstrución admitida e conserve as exclusións, porque un proxy que intercepta hosts internos rompe servizos que o contedor necesita.

Separe os fallos de confianza da accesibilidade

Un proxy que conecta e despois devolve un erro de verificación de certificado chegou a unha etapa posterior que un que rexeita a conexión. O primeiro fallo quere o material de confianza aprobado pola organización instalado na contorna que realiza a solicitude. O segundo quere un enderezo e un porto accesibles. Tratalos como un só problema produce unha solución que non funciona para ningún dos dous.

Desactivar a verificación, ou executar o editor con dereitos elevados, non é unha reparación para un proxy ausente ou unha cadea de confianza ausente. Ambas cambian un erro visible por un silencioso. Volva probar a mesma extensión despois e anote o seguinte URL que falle.

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

Anote que lado do espazo de traballo produciu ese URL. Unha nota breve que nomee a etapa, o host e o lado vale máis que unha lista de axustes que alguén cambiou, porque esa nota é o que a seguinte persoa pode reproducir.

Artigos relacionados