NO_PROXY-ის თავსებადობა curl-ს, .NET-სა და კონტეინერებს შორის
გადააქციეთ საერთო პირდაპირი მარშრუტიზაციის პოლიტიკა კლიენტისთვის სპეციფიკურ კონფიგურაციად რამდენიმე წარმომადგენლობითი დანიშნულების გამოყენებით.
გუნდი ერთ გვერდის ავლის სტრიქონს საერთო გარემოს ფაილში დებს. curl პირდაპირ მიდის, სხვა აპლიკაცია პროქსის იყენებს, კონტეინერი კი ისევ სხვანაირად იქცევა. საერთო ფაილმა იგივე სიმბოლოები გაავრცელა. მაგრამ მან ერთი საერთო პარსერი არ გაავრცელა.
მდგრადი ობიექტი პოლიტიკაა: რომელი დანიშნულებები უნდა იყოს პირდაპირი და რა პირობებში? გამოყავით ის სტრიქონისგან, რომელიც თითოეულ პროგრამას სჭირდება.
ჯერ დაწერეთ მოსალოდნელი მარშრუტები
გამოიყენეთ წარმომადგენლობითი მისამართები, მათ შორის საზღვრები და არა მხოლოდ მარტივი წარმატებები:
| დანიშნულების ფორმა | კითხვა პოლიტიკის მფლობელისთვის |
|---|---|
| მშობელი დომენი | უნდა გვერდი ავუაროთ მას თუ მხოლოდ მის შვილებს? |
| ქვედომენი | მემკვიდრეობით იღებს იმავე მარშრუტს? |
| ლიტერალური კერძო IP | ეს მისამართი პირდაპირ ხელმისაწვდომია ამ კლიენტიდან? |
| იგივე სერვისი ჰოსტის სახელის ქვეშ | უნდა დაემთხვეს თუ არა სახელზე და მისამართზე დაფუძნებული მოთხოვნები? |
| სერვისის სხვა პორტი | გამონაკლისი მოიცავს ჰოსტს თუ ერთ მსმენელს? |
შემდეგ დაადგინეთ მომხმარებლები: იმიჯის ჩამომქაჩი დემონი, კონტეინერის შიგნით არსებული პროგრამა, ენის HTTP ბიბლიოთეკა და ინტერაქტიული ბრაუზერი შეიძლება იყოს ცალკეული ჩანაწერები. Docker კლიენტის პროქსის კონფიგურაციას შეუძლია კონტეინერის გარემოს მნიშვნელობების შევსება იმის გარეშე, რომ შიგნით ყოველ კლიენტს იგივე შესაბამისობის წესები დანერგოს.
თარგმნეთ და ნუ დააკოპირებთ ბრმად
რეალური განსხვავების ერთი დოკუმენტირებული მაგალითია მშობელი დომენის საზღვარი. curl-ის დომენის გამორიცხვა მოიცავს დასახელებულ დომენს და შესაბამის შვილებს. .NET-ის გარემოს პოლიტიკა განასხვავებს შიშველ სახელს წინა წერტილიანი ქვედომენის ფორმისგან. უნივერსალური წესი ყოველთვის დაამატე წინა წერტილი ვერ გამოხატავს ორივე პოლიტიკას საიმედოდ.
IP დიაპაზონების მხარდაჭერა ასევე დამოკიდებულია მომხმარებელზე და მის ვერსიაზე. ახალი დამოუკიდებელი curl-ის მქონე მანქანას მაინც შეუძლია გაუშვას ძველ libcurl-ზე მიბმული აპლიკაცია ან სულ სხვა ბიბლიოთეკის გამოყენებით მომუშავე კლიენტი. ოპერაციული სისტემის გამოშვება არ არის კლიენტების სრული ინვენტარი.
თითოეული მომხმარებლისთვის ჩაწერეთ მისი მხარდაჭერილი კონფიგურაციის ინტერფეისი და განზრახული მარშრუტების უმცირესი გამოხატულება. მოკლე ცხადი ჰოსტების სია შეიძლება უკეთესი იყოს, ვიდრე ჭკვიანური ნიმუში, რომლის მნიშვნელობას ვერავინ ხსნის.
კონფიგურაციის მტკიცებულებები ცალკე შეინახეთ კავშირის მტკიცებულებებისგან
გაანალიზებული პარამეტრი ან მარშრუტიზაციის გადაწყვეტილების API შეიძლება აჩვენოს, რა აირჩია პროგრამამ. მოთხოვნის შედეგი შემდეგ აჩვენებს, იყო თუ არა ეს მარშრუტი გამოსაყენებელი. .NET-ში, HttpClient.DefaultProxy.IsBypassed უზრუნველყოფს ამ კონფიგურაციის მხარის შემოწმებას, როდესაც ნაგულისხმევი პროქსი გამოყენებული პოლიტიკაა. ნუ დაადგენთ მიუწვდომელ პირდაპირ სერვისს გვერდის ავლის პარსერის უკმარისობად მხოლოდ იმიტომ, რომ მოთხოვნის დრო ამოიწურა.
შეინარჩუნეთ სასაზღვრო დანიშნულებები კლიენტის ან საბაზისო იმიჯის განახლებისას. ისინი ხილვადს ხდიან მომავალ თავსებადობის ცვლილებებს მთელი გუნდისთვის ხელახლა აღმოჩენის გარეშე, თუ რატომ შეიცავს ფაილი ორ მსგავს დომენის ჩანაწერს.