Os downloads no terminal funcionam, mas as extensões do VS Code falham na VPN

curl funciona no contentor e a extensão continua a não instalar. Compare o editor local e o ambiente remoto antes de copiar as definições do proxy.

Os downloads que têm êxito no terminal do contentor são prova real do ambiente desse terminal. Não dizem nada sobre o processo do editor, o instalador de extensões ou o binário que uma extensão obtém depois. Copiar as variáveis de proxy entre esses três transforma um pedido falhado numa tarde inteira de alterações não relacionadas.

Dois ambientes diferem normalmente em exatamente um aspeto. Encontrar esse aspeto é mais rápido do que ler a documentação do proxy duas vezes.

Que processo fez o pedido falhado

Três pedidos podem falhar durante uma única instalação, e cada um tem a sua própria identidade de rede. O editor pede ao Marketplace os metadados e um URL do pacote, e depois transfere o pacote. Só depois disso o anfitrião de extensões executa código que pode obter um servidor de linguagem ou um binário próprio. A etapa que falhou decide que processo precisa de um proxy, e a superfície de erro raramente nomeia a etapa.

Um terminal funcional prova que o contentor consegue chegar à internet, não que o editor consegue. Leia o registo da extensão para o último URL que tentou. O anfitrião aí indicado identifica o processo e a política que se lhe aplica.

O editor local e o contentor remoto são dois ambientes

Num espaço de trabalho remoto, uma extensão é executada no lado que o seu tipo declara. As extensões de interface ficam com o editor local, e as extensões de espaço de trabalho são executadas no contentor. Um proxy definido num é invisível para o outro, e uma reconstrução recria o ambiente do contentor a partir do seu ficheiro de configuração e não do que exportou numa shell. Essa divisão explica por que a mesma extensão se instala num portátil e falha no mesmo projeto por SSH.

Leia a localização da instalação antes de editar seja o que for. Quando o registo indica uma instalação remota, é o ambiente do contentor que importa.

Coloque o proxy onde o pedido começa

Para um Dev Container que precisa realmente de um proxy HTTP, a variável pertence à configuração do contentor para que uma reconstrução a reproduza. O fragmento abaixo defini-la para esse ambiente. O endereço de substituição representa o seu próprio gateway, e as exclusões não são preenchimento 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 variável descreve o protocolo de destino, pelo que um valor HTTPS_PROXY pode legitimamente começar por http. Aplique a alteração pelo caminho de reconstrução suportado e mantenha as exclusões, porque um proxy que interceta anfitriões internos quebra serviços de que o contentor precisa.

Separe as falhas de confiança da acessibilidade

Um proxy que liga e depois devolve um erro de verificação de certificado atingiu uma etapa posterior do que um que recusa a ligação. A primeira falha quer o material de confiança aprovado pela organização instalado no ambiente que faz o pedido. A segunda quer um endereço e uma porta acessíveis. Tratá-las como um só problema produz uma correção que não funciona para nenhuma delas.

Desativar a verificação, ou executar o editor com privilégios elevados, não é uma reparação para um proxy em falta ou uma cadeia de confiança ausente. Ambas trocam um erro visível por um silencioso. Tente novamente a mesma extensão depois e anote o próximo URL que falhar.

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

Anote que lado do espaço de trabalho produziu esse URL. Uma nota curta com a etapa, o anfitrião e o lado vale mais do que uma lista de definições que alguém alterou, porque é essa nota que a próxima pessoa consegue reproduzir.

Artigos relacionados