Docker: ერთი კონტეინერის VPN-ით გატარება და მეორის პირდაპირ დატოვება
მიეცით გვირაბს საკუთარი კონტეინერი, ნება დართეთ მხოლოდ იმ სერვისებს, რომლებსაც ის სჭირდებათ, გაიზიარონ ეს სახელთა სივრცე, შემდეგ გაითვალისწინეთ ის, რაც მფლობელს მოსდევს: პორტები, localhost, DNS.
ერთი ჰოსტი, ორი დატვირთვა და მოთხოვნა, რომელიც მათ ჰყოფს: ჩამოტვირთვის კლიენტი, რომელიც კომერციული VPN-იდან უნდა გამოვიდეს, და მართვის ინტერფეისი, რომელიც ჰოსტის კავშირის გამოყენებას უნდა გააგრძელოს. VPN კლიენტის ჰოსტზე დაყენება მოთხოვნას მაშინვე არღვევს, რადგან მაშინ ორივე დატვირთვა ერთ გასასვლელს იზიარებს. ნიმუში, რომელიც ნამდვილად მუშაობს, გვირაბის საკუთარ კონტეინერში გადატანაა და მხოლოდ იმ დატვირთვებისთვის დაშვება, რომლებსაც ის სჭირდებათ, შეუერთდნენ ამ კონტეინერის ქსელურ სახელთა სივრცეს. დანარჩენი ყველაფერი Docker-ის ჩვეულ გზას ინარჩუნებს, და შემდგომი დეტალები იმის შედეგია, თუ ვინ ფლობს სახელთა სივრცეს.
რატომ ცვლის საერთო სახელთა სივრცე წესებს
კონტეინერი, რომელიც სხვის სახელთა სივრცეს უერთდება, საკუთარ ქსელურ დასტას არ იღებს. ის ხედავს იმავე ინტერფეისებს, იმავე მარშრუტიზაციის ცხრილს და იმავე loopback-ს, რაც კონტეინერი, რომელსაც შეუერთდა, და სწორედ ამიტომ არის ნიმუში სასარგებლო: დატვირთვა ჩვეულებრივად წყვეტს და უკავშირდება, ხოლო ქვემოთ არსებული გვირაბი ტრაფიკს იჭერს აპლიკაციის უცნობად. ფასი ის არის, რომ ყველა ქსელურ პარამეტრს ახლა ერთი მფლობელი ჰყავს, და შემოერთებული კონტეინერი ის არ არის.
მფლობელობის ეს წესი კონფიგურაციის კითხვების უმეტესობას პასუხობს მათ დასმამდე. თუ პარამეტრი ქსელურ დასტაში ცხოვრობს, ის გვერდით კონტეინერს ეკუთვნის. თუ ის პროცესს აღწერს, ის დატვირთვასთან რჩება.
loopback ის ნაწილია, რომელიც ხალხს აკვირვებს. შემოერთებული კონტეინერის შიგნით, localhost გვერდითი კონტეინერის loopback-ზე წყდება, და არა საკუთარ კერძოზე, ამიტომ სერვისი, რომელიც 127.0.0.1-ს ებმის და იზოლაციას ელოდება, ახლა ამ მისამართს გვირაბის კონტეინერთან იზიარებს.
გამოაქვეყნეთ პორტები კონტეინერზე, რომელიც ფლობს სახელთა სივრცეს
პორტების დაკავშირება სახელთა სივრცის მფლობელს ეკუთვნის, მაშინაც კი როცა მსმენელი პროცესი სხვა კონტეინერში მუშაობს. გამოაცხადეთ დაკავშირება გვერდით კონტეინერზე, და დატვირთვამ შეინარჩუნოს საკუთარი პროცესის კონფიგურაცია უცვლელად. შემოერთებულ სერვისზე დაკავშირება ვერ ამოქმედდება, უარყოფს თუ არა მას ძრავა ან ჩუმად უგულებელყოფს იმის მიხედვით, თუ როგორ იშვება კონტეინერი, და სწორედ ამიტომ ქრება წამის წინ ხელმისაწვდომი ინტერფეისი, როგორც კი ნიმუში გამოიყენება.
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]წაიკითხეთ ეს ბლოკი როგორც სამი გადაწყვეტილება და არა სამი სერვისი. გვერდითი კონტეინერი ფლობს გვირაბს და გამოქვეყნებულ პორტს; შემოერთებული კლიენტი საერთოდ არ აცხადებს ქსელს; პირდაპირი კლიენტი ინარჩუნებს საკუთარ დაკავშირებას ნაგულისხმევ ქსელზე. შესაძლებლობა NET_ADMIN არის ის, რაც გვერდით კონტეინერს ინტერფეისების შექმნისა და მარშრუტების შეცვლის საშუალებას აძლევს, და სწორედ ამიტომ სჭირდება ამ კონტეინერს მეტი უფლება, ვიდრე იმ დატვირთვებს, რომლებსაც ემსახურება.
პირდაპირ დარჩენილი სერვისი ინარჩუნებს საკუთარ ქსელს
დატვირთვა, რომელიც გვირაბში არ უნდა გაიაროს, ინარჩუნებს ნაგულისხმევ ხიდს ან საკუთარ მომხმარებლის მიერ განსაზღვრულ ქსელს, საკუთარი გამოქვეყნებული პორტით და საკუთარი გასასვლელით. მაცდურია მისი გვერდითი კონტეინერის ქსელთან დაკავშირება, რათა ორმა კონტეინერმა სახელით ისაუბროს, მაგრამ ეს ერთი ნაბიჯი მის ტრაფიკს ჩუმად გვირაბში გადააქვს. თუ მათ ერთმანეთამდე მისვლა სჭირდებათ, ააგეთ ცალკე მომხმარებლის მიერ განსაზღვრული ქსელი, დაუკავშირეთ ორივე მას, და გვერდითი კონტეინერი დატოვეთ გარეთ გასვლის ერთადერთ გზად.
გამოყავით ორი კითხვა: რომელი კონტეინერები აღწევენ ერთმანეთამდე, და რომელი საიდან გადის გარეთ. მათი გაერთიანება ყველაზე გავრცელებული გზაა, რომლითაც ეს დიზაინი კვლავ მთელი ჰოსტის VPN-ად იქცევა.
მარცხების მატრიცა პირველი საათისთვის
პირველი ცდების უმეტესობა ოთხიდან ერთი გზით მარცხდება, და თითოეულს განსხვავებული მიზეზი აქვს. შეამოწმეთ ისინი ამ თანმიმდევრობით, რადგან პირველი ორი თითქმის ყველა მოხსენებას ხსნის.
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
მეოთხე სტრიქონია ის, რასაც ხალხი შეცდომით აპლიკაციის ხარვეზად ადგენს. დატვირთვის საკუთარი loopback-ის წინააღმდეგ დაწერილი შემოწმება ახლა გვირაბის კონტეინერს ამოწმებს, ამიტომ ის ან მარცხდება, ან სრულიად არასწორ სერვისს იუწყება.
როცა ერთ ჰოსტის სახელს გვირაბი სჭირდება
ზოგჯერ სრული გვირაბი ზედმეტია: ერთი შიდა სახელი კორპორატიულ VPN-ში უნდა გაიაროს, სანამ ადგილობრივი სოკეტი ან ეკრანის კავშირი აგრძელებს მუშაობას. კონტეინერის შიგნით სრული გვირაბი ამ გზას და ჰოსტზე მიმართულ ყველაფერს ამტვრევს, ამიტომ მარშრუტიზაცია მხოლოდ იმ პრეფიქსს გაუკეთეთ, რომელსაც სჭირდება. კლიენტის გარშემო გაყოფილი მარშრუტიზაციის გარსი ამას აკეთებს, სახელდებულ ჰოსტს გვირაბით აგზავნის და წინა მარშრუტს ყველა დანარჩენისთვის უცვლელად ტოვებს.
ეს აირჩიეთ, როცა მხოლოდ ერთ სერვისამდე გჭირდებათ მისვლა და კონტეინერის მთელი ტრაფიკის გადატანას არ ცდილობთ. ეს გვერდითი კონტეინერისგან განსხვავებული იარაღია და სხვა კითხვას პასუხობს.
გადაამოწმეთ, შემდეგ გახადეთ გადატვირთვისადმი მედეგი
ჰკითხეთ თითოეულ კონტეინერს, რომელი მისამართიდან ჩანს, რომ მოდის. გვირაბში მყოფმა პროვაიდერის მისამართი უნდა დაბეჭდოს, პირდაპირმა კი ჰოსტის გასასვლელი. იდენტური პასუხები ნიშნავს, რომ პირდაპირმა სერვისმა არასწორი სახელთა სივრცე მიიღო მემკვიდრეობით, ან ჰოსტის დონის VPN ჯერ კიდევ ყველაფერს იჭერს, და ეს ორი შესწორება განსხვავებულია. ხელახლა გაუშვით შემოწმება ყოველი compose-ის რედაქტირების შემდეგ, რადგან ერთი დაკოპირებული სერვისის ბლოკი საკმარისია პრობლემის დასაბრუნებლად.
სამი რამ მიდრეკილია გატყდეს მოგვიანებით. DNS სახელთა სივრცის მფლობელს მიჰყვება, ამიტომ გადამწყვეტის და საძიებო დომენის პარამეტრები გვერდით კონტეინერს ეკუთვნის და არა ჰოსტს. პორტების გადამისამართების მქონე VPN ხელახალი დაკავშირებისას თავის მსმენელ პორტს ცვლის, ამიტომ პროვაიდერის გადამისამართებული პორტი და კონტეინერის მხარეს მსმენელი პორტი უნდა გადაიწეროს კლიენტის კონფიგურაციაში ან პორტების დაკავშირებაში, ჩვეულებრივ პატარა განმაახლებლით, რომელიც პროვაიდერის API-ს კითხულობს. და ნებისმიერი შემოწმება, რომელიც დაწერილია localhost-ის წინააღმდეგ, ახლა გვირაბის კონტეინერს ეკითხება და არა დატვირთვას.
ჩაწერეთ ნიმუში, მათ შორის რომელი კონტეინერი ფლობს სახელთა სივრცეს და რომელი პორტები ეკუთვნის მას. შემდეგი ადამიანი დაამატებს სერვისს, დააკოპირებს არასწორ ბლოკს და გაამეორებს ამ სტატიის პირველ მარცხს.