ტერმინალში ჩამოტვირთვები მუშაობს, მაგრამ VS Code-ის გაფართოებები VPN-ზე ვერ ინსტალირდება

curl კონტეინერში მუშაობს, გაფართოება კი მაინც არ ინსტალირდება. პროქსის პარამეტრების კოპირებამდე შეადარეთ ლოკალური რედაქტორი და დისტანციური გარემო.

კონტეინერის ტერმინალში წარმატებული ჩამოტვირთვები რეალური მტკიცებულებაა ამ ტერმინალის გარემოს შესახებ. ისინი არაფერს ამბობენ რედაქტორის პროცესზე, გაფართოებების ინსტალატორზე ან ბინარულ ფაილზე, რომელსაც გაფართოება შემდეგ ჩამოტვირთავს. პროქსის ცვლადების კოპირება ამ სამს შორის ერთ წარუმატებელ მოთხოვნას უკავშირო ცვლილებების მთელ შუადღედ აქცევს.

ორი გარემო ჩვეულებრივ ზუსტად ერთ რამეში განსხვავდება. ამ რამის პოვნა უფრო სწრაფია, ვიდრე პროქსის დოკუმენტაციის ორჯერ წაკითხვა.

რომელმა პროცესმა გაგზავნა წარუმატებელი მოთხოვნა

ერთი ინსტალაციის დროს შეიძლება სამი მოთხოვნა ჩავარდეს და თითოეულს საკუთარი ქსელური იდენტობა აქვს. რედაქტორი 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. მოკლე ჩანაწერი, რომელიც ასახელებს ეტაპს, ჰოსტს და მხარეს, უფრო ღირებულია, ვიდრე ვინმეს მიერ შეცვლილი პარამეტრების სია, რადგან სწორედ ამ ჩანაწერის გამეორება შეუძლია შემდეგ ადამიანს.

დაკავშირებული სტატიები