Ներբեռնումները տերմինալում աշխատում են, բայց VS Code-ի ընդլայնումները ձախողվում են VPN-ի հետևում

Կոնտեյների տերմինալում հաջողվող ներբեռնումները իրական ապացույց են այդ տերմինալի միջավայրի մասին։ Դրանք ոչինչ չեն ասում խմբագրիչի գործընթացի, ընդլայնումների տեղադրիչի կամ այն բինար ֆայլի մասին, որը ընդլայնումը հետո ներբեռնում է։ Այս երեքի միջև պրոքսի փոփոխականները պատճենելը մեկ ձախողված հարցումը դարձնում է անհետևանք փոփոխություններով լի մի ամբողջ կեսօր։

Երկու միջավայր սովորաբար տարբերվում են ուղիղ մեկ առումով։ Այդ առումը գտնելը ավելի արագ է, քան պրոքսի փաստաթղթերը երկու անգամ կարդալը։

Որ գործընթացն է կատարել ձախողված հարցումը

Մեկ տեղադրման ընթացքում կարող են ձախողվել երեք հարցում, և յուրաքանչյուրն ունի իր ցանցային ինքնությունը։ Խմբագրիչը Marketplace-ից խնդրում է մետատվյալներ և փաթեթի URL, ապա ներբեռնում է փաթեթը։ Միայն դրանից հետո է ընդլայնումների հոսթը գործարկում կոդ, որը կարող է բերել լեզվական սերվեր կամ իր սեփական բինար ֆայլը։ Թե որ փուլն է կոտրվել, դա որոշում է, թե որ գործընթացին է պրոքսի պետք, և սխալի մակերևույթը հազվադեպ է նշում այդ փուլը։

Աշխատող տերմինալը ապացուցում է, որ կոնտեյները կարող է հասնել ինտերնետին, ոչ թե որ խմբագրիչը կարող է։ Կարդացեք ընդլայնման մատյանում վերջին URL-ը, որը նա փորձել է։ Այնտեղ նշված հոսթը նույնականացնում է գործընթացը և դրա նկատմամբ կիրառվող քաղաքականությունը։

Տեղական խմբագրիչը և հեռավոր կոնտեյները երկու միջավայր են

Հեռավոր աշխատանքային տարածքում ընդլայնումը գործարկվում է այն կողմում, որը հայտարարում է նրա տեսակը։ Ինտերֆեյսի ընդլայնումները մնում են տեղական խմբագրիչի հետ, իսկ աշխատանքային տարածքի ընդլայնումները գործարկվում են կոնտեյներում։ Մեկում սահմանված պրոքսին անտեսանելի է մյուսի համար, և վերակառուցումը ստեղծում է կոնտեյների միջավայրը նրա կոնֆիգուրացիայի ֆայլից, այլ ոչ թե այն ամենից, ինչ արտահանել եք shell-ում։ Այդ բաժանումը բացատրում է, թե ինչու նույն ընդլայնումը տեղադրվում է նոութբուքում և ձախողվում նույն նախագծում SSH-ի միջոցով։

Կարդացեք տեղադրման վայրը նախքան որևէ բան խմբագրելը։ Երբ մատյանը հաղորդում է հեռավոր տեղադրման մասին, կարևորը կոնտեյների միջավայրն է։

Տեղադրեք պրոքսին այնտեղ, որտեղ սկսվում է հարցումը

Dev Container-ի համար, որն իսկապես HTTP պրոքսի կարիք ունի, փոփոխականը պատկանում է կոնտեյների կոնֆիգուրացիային, որպեսզի վերակառուցումը վերարտադրի այն։ Ստորև բերված հատվածը սահմանում է այն այդ միջավայրի համար։ Տեղապահ հասցեն ներկայացնում է ձեր սեփական դարպասը, իսկ բացառությունները լրացուցիչ լցոն չեն։

"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-ը։ Փուլը, հոսթը և կողմը նշող կարճ գրությունը արժե ավելին, քան ինչ-որ մեկի փոփոխած կարգավորումների ցանկը, որովհետև հենց այդ գրությունն է, որ հաջորդ մարդը կարող է վերարտադրել։