Терминалдагы жүктөөлөр иштейт, бирок VPN аркылуу VS Code кеңейтүүлөрү орнотулбайт
curl контейнерде иштейт, ал эми кеңейтүү дагы эле орнотулбайт. Прокси жөндөөлөрүн көчүрүүдөн мурун жергиликтүү редактор менен алыскы чөйрөнү салыштырыңыз.
Контейнердин терминалында ийгиликтүү аяктаган жүктөөлөр ошол терминалдын чөйрөсү тууралуу чыныгы далил. Алар редактордун процесси, кеңейтүү орноткучу же кеңейтүү кийин жүктөй турган бинардык файл жөнүндө эч нерсе айтпайт. Бул үчөөнүн ортосунда прокси өзгөрмөлөрүн көчүрүү бир ийгиликсиз сурамды түштөн кийинки байланышсыз оңдоолорго айландырат.
Эки чөйрө адатта так бир жагынан айырмаланат. Ошол жакты табуу прокси документтерин эки жолу окуудан тезирээк.
Ийгиликсиз сурамды кайсы процесс жасады
Бир орнотуу учурунда үч сурам ийгиликсиз болушу мүмкүн жана ар биринин өзүнүн тармактык инсандыгы бар. Редактор Marketplaceтен метаберилиштерди жана пакеттин URLин сурайт, анан пакетти жүктөйт. Ушундан кийин гана кеңейтүү хосту тил серверин же өзүнүн бинардык файлын жүктөй турган кодду иштетет. Кайсы баскыч бузулганы кайсы процесске прокси керек экенин аныктайт, ал эми ката бети бул баскычты сейрек атайт.
Иштеген терминал контейнердин интернетке жете аларын далилдейт, редактордун жете аларын эмес. Кеңейтүү журналынан анын акыркы аракет кылган URLин окуңуз. Ал жерде аталган хост процессти жана ага колдонулуучу саясатты аныктайт.
Жергиликтүү редактор менен алыскы контейнер — эки чөйрө
Алыскы иш мейкиндигинде кеңейтүү өз түрү жарыялаган тарапта иштейт. Интерфейс кеңейтүүлөрү жергиликтүү редактор менен калат, ал эми иш мейкиндигинин кеңейтүүлөрү контейнерде иштейт. Бирөөндө коюлган прокси экинчисине көрүнбөйт, ал эми кайра куруу контейнердин чөйрөсүн анын конфигурация файлынан жаратат, shellде экспорттогонуңуздан эмес. Бул бөлүнүү ошол эле кеңейтүүнүн ноутбукта орнотулуп, ошол эле долбоордо SSH аркылуу эмне үчүн ийгиликсиз болорун түшүндүрөт.
Бир нерсени оңдоодон мурун орнотуу ордун окуңуз. Журнал алыскы орнотуу тууралуу билдиргенде, маанилүүсү — контейнердин чөйрөсү.
Проксини сурам башталган жерге коюңуз
Чындап эле HTTP прокси керек болгон Dev Container үчүн өзгөрмө контейнердин конфигурациясында болушу керек, ошондо кайра куруу аны кайра жаратат. Төмөнкү үзүндү аны ошол чөйрө үчүн коёт. Орун басар дарек өзүңүздүн шлюзүңүздү билдирет, ал эми өзгөчөлүктөр милдеттүү эмес толуктоочу эмес.
"containerEnv": {
"HTTP_PROXY": "http://proxy.corp.example:8080",
"HTTPS_PROXY": "http://proxy.corp.example:8080",
"NO_PROXY": "localhost,127.0.0.1,.internal.example"
}
Өзгөрмөнүн аталышы багыт протоколун сүрөттөйт, ошондуктан HTTPS_PROXY мааниси мыйзамдуу түрдө http менен башталышы мүмкүн. Өзгөртүүнү колдоого алынган кайра куруу жолу менен колдонуңуз жана өзгөчөлүктөрдү сактаңыз, анткени ички хостторду кармаган прокси контейнерге керек кызматтарды бузат.
Ишенимдин бузулушу менен жеткиликтүүлүктү ажыратыңыз
Туташып, анан сертификатты текшерүү катасын кайтарган прокси туташуудан баш тарткан проксиге караганда кийинки баскычка жетти. Биринчи бузулууга уюмдун бекитилген ишеним материалы сурамды аткарган чөйрөгө орнотулушу керек. Экинчисине жеткиликтүү дарек жана порт керек. Экөөнү бир маселе катары кароо эч бирине жарабаган түзөтүү чыгарат.
Текшерүүнү өчүрүү же редакторду жогорку укуктар менен иштетүү жок прокси же жок ишеним чынжыры үчүн оңдоо эмес. Экөө тең көрүнүүчү катаны үнсүз катага алмаштырат. Андан кийин ошол эле кеңейтүүнү кайра аракет кылып, ийгиликсиз болгон кийинки URLди белгилеңиз.
env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force
Иш мейкиндигинин кайсы тарабы ошол URLди жаратканын жазып коюңуз. Баскычты, хостту жана тарапты атаган кыска жазуу бирөө өзгөрткөн жөндөөлөрдүн тизмесинен кымбат, анткени кийинки адам дал ошол жазууну кайталай алат.