Terminal yükləmələri işləyir, amma VPN arxasında VS Code genişləndirmələri uğursuz olur

Konteyner terminalında uğurla başa çatan yükləmələr həmin terminalın mühiti haqqında real sübutdur. Onlar redaktor prosesi, genişləndirmə quraşdırıcısı və ya genişləndirmənin sonradan endirdiyi binar fayl haqqında heç nə demir. Proxy dəyişənlərini bu üçü arasında köçürmək bir uğursuz sorğunu əlaqəsiz düzəlişlərlə dolu bir günortaya çevirir.

İki mühit adətən tam olaraq bir cəhətdən fərqlənir. Həmin cəhəti tapmaq proxy sənədlərini iki dəfə oxumaqdan daha sürətlidir.

Uğursuz sorğunu hansı proses göndərdi

Bir quraşdırma zamanı üç sorğu uğursuz ola bilər və hər birinin öz şəbəkə kimliyi var. Redaktor Marketpleysdən metadata və paket URL-i istəyir, sonra paketi endirir. Yalnız bundan sonra genişləndirmə hostu dil serverini və ya öz binar faylını endirə bilən kod işlədir. Hansı mərhələnin sındığı hansı prosesin proxy-yə ehtiyacı olduğunu müəyyən edir və xəta səthi bu mərhələni nadir hallarda adlandırır.

İşləyən terminal konteynerin internetə çıxa bildiyini sübut edir, redaktorun çıxa bildiyini yox. Genişləndirmə jurnalında onun son cəhd etdiyi URL-i oxuyun. Orada göstərilən host prosesi və ona tətbiq olunan siyasəti müəyyənləşdirir.

Yerli redaktor və uzaq konteyner iki fərqli mühitdir

Uzaq iş sahəsində genişləndirmə öz növünün bəyan etdiyi tərəfdə işləyir. İnterfeys genişləndirmələri yerli redaktorla qalır, iş sahəsi genişləndirmələri isə konteynerdə işləyir. Birində qurulan proxy digəri üçün görünməzdir və yenidən qurma konteyner mühitini qabıqda ixrac etdiyinizdən deyil, onun konfiqurasiya faylından yaradır. Bu bölünmə eyni genişləndirmənin noutbukda quraşdırılıb SSH üzərindən eyni layihədə niyə uğursuz olduğunu izah edir.

Hər hansı düzəliş etməzdən əvvəl quraşdırma yerini oxuyun. Jurnal uzaq quraşdırma bildirdikdə, konteynerin mühiti vacib olandır.

Proxy-ni sorğunun başladığı yerə qoyun

Həqiqətən HTTP proxy-yə ehtiyacı olan Dev Container üçün dəyişən konteyner konfiqurasiyasına aiddir ki, yenidən qurma onu təkrar istehsal etsin. Aşağıdakı fraqment onu həmin mühit üçün qurur. Yertutucu ünvan öz şlüzünüzün yerinə durur və istisnalar məcburi olmayan doldurma deyil.

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

Dəyişənin adı təyinat protokolunu təsvir edir, ona görə HTTPS_PROXY dəyəri qanuni olaraq http ilə başlaya bilər. Dəyişikliyi dəstəklənən yenidənqurma yolu ilə tətbiq edin və istisnaları saxlayın, çünki daxili hostları kəsən proxy konteynerin ehtiyac duyduğu xidmətləri pozur.

Etibar uğursuzluqlarını əlçatanlıqdan ayırın

Qoşulan və sonra sertifikat yoxlama xətası qaytaran proxy, bağlantını rədd edəndən daha sonrakı mərhələyə çatıb. Birinci uğursuzluq təşkilatın təsdiqlənmiş etibar materialının sorğunu yerinə yetirən mühitdə quraşdırılmasını tələb edir. İkincisi əlçatan ünvan və port tələb edir. Onlara bir problem kimi yanaşmaq ikisinə də işləyən düzəliş doğurmur.

Yoxlamanı söndürmək və ya redaktoru yüksəldilmiş hüquqlarla işlətmək itkin proxy və ya olmayan etibar zənciri üçün təmir deyil. Hər ikisi görünən xətanı səssiz biri ilə dəyişir. Sonra eyni genişləndirməni yenidən sınayın və uğursuz olan növbəti URL-i qeyd edin.

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

İş sahəsinin hansı tərəfinin o URL-i yaratdığını qeyd edin. Mərhələni, hostu və tərəfi adlandıran qısa qeyd kiminsə dəyişdiyi ayarlar siyahısından daha dəyərlidir, çünki növbəti şəxsin təkrar istehsal edə biləcəyi şey həmin qeyddir.