network_mode: service:vpn და დაკარგული db ჰოსტის სახელი

თქვენ ამატებთ network_mode: service:vpn-ს აპლიკაციას, გადატვირთავთ სტეკს და აპლიკაცია კვდება, რადგან db აღარ იხსნება. compose ფაილში არაფერი გადარქმეულა, ამიტომ აშკარა ეჭვმიტანილები DNS და მონაცემთა ბაზაა. ნამდვილი ცვლილება უფრო მცირე და უცნაურია: აპლიკაციამ შეწყვიტა იმ Compose ქსელის წევრობა, სადაც ეს სახელი არსებობს. სანამ არ გადაწყვეტთ, რომელი სახელთა სივრციდან უნდა პასუხობდეს მონაცემთა ბაზა, ჰოსტის სახელის ყოველი შესწორება ვარაუდია.

რატომ შეწყვიტა db ჰოსტის სახელმა გადაწყვეტა

network_mode-ის გამოყენებელ სერვისს Compose ქსელში საკუთარი მისამართი არ აქვს; ის სესხულობს დასახელებული სერვისის სახელთა სივრცეს. ეს სივრცე მოაქვს საკუთარი ინტერფეისები, მარშრუტები, პორტების სივრცე და გადამწყვეტი, და ის ცვლის აპლიკაციის მიერთებას backend ქსელთან. სახელი db არასოდეს ყოფილა აბსტრაქტული: ის ცხოვრობდა ამ ქსელში და იხსნებოდა მისი ჩაშენებული DNS-ით. მოხსენით მიერთება და სახელს არსად აქვს გადასაწყვეტი.

დაადასტურეთ ეს კონტეინერების შიგნიდან და არა ჰოსტიდან. ძიება, რომელიც აპლიკაციაში ვერ ხერხდება, მაგრამ მონაცემთა ბაზის კონტეინერში წარმატებულია, ნიშნავს, რომ სახელი რიგზეა და წევრობა არა. ეს შედეგი შესწორებას compose ტოპოლოგიაში ათავსებს და არა აპლიკაციის გადამწყვეტის პარამეტრებში.

სამი კითხვა ფაილის რედაქტირებამდე

უპასუხეთ მათ რიგრიგობით, რადგან თითოეული ავიწროებს ტოპოლოგიას. რაზე უნდა პასუხობდეს მონაცემთა ბაზა: ჰოსტის სახელზე, რომელსაც სხვა კონტეინერები იყენებენ, თუ მხოლოდ აპლიკაციაზე loopback-ზე? უნდა გამოაქვეყნოს აპლიკაციამ პორტი ჰოსტზე, და რომელი სერვისი იქნებოდა მისი მფლობელი? უნდა იყოს მონაცემთა ბაზა ხელმისაწვდომი ჰოსტიდან თუ სხვა მანქანიდან, თუ მხოლოდ გვირაბის შიგნიდან?

თუ მონაცემთა ბაზას საკუთარი სახელი სჭირდება და აპლიკაცია არაფერს აქვეყნებს, დააყოვნეთ ისინი ცალკე მიერთებებზე. თუ აპლიკაციამ პორტი უნდა გამოაქვეყნოს და ყველაფერი გვირაბში გადის, მოათავსეთ მონაცემთა ბაზა VPN-ის სახელთა სივრცეში და გამოიყენეთ loopback. ორივეს შერევა ქმნის სტეკს, რომელიც სუფთად იწყება და კავშირის დროს ფუჭდება.

დატოვეთ მონაცემთა ბაზა იქ, სადაც არის

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

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

არ დაამატოთ networks ასევე აპლიკაციას. Compose უარყოფს ამ თვისებას network_mode-თან ერთად იმავე სერვისში, და შეცდომა ფაილზე მიუთითებს და არა წყვილზე. თუ VPN კლიენტი ფილტრავს backend დანიშნულებას თავის სახელთა სივრცეში, მოარგეთ მისი მხარდაჭერილი ლოკალური ქსელის პოლიტიკაც; საერთო მიერთება გზას გვთავაზობს, მაგრამ არ აუქმებს ამ ფილტრს.

გადაიტანეთ მონაცემთა ბაზა სახელთა სივრცეში

უფრო დიდი ცვლილება მონაცემთა ბაზას იმავე სახელთა სივრცეში ათავსებს და აპლიკაციას ნამდვილი პორტით 127.0.0.1-ზე მიმართავს. ორ პროცესს არ შეუძლია ორივემ ერთი და იმავე მისამართი და პორტი დააბას მხოლოდ იმიტომ, რომ სხვადასხვა კონტეინერში დაიწყეს, ამიტომ wildcard მისამართზეც მომსმენი მონაცემთა ბაზა დაეჯახება ყველაფერს, რაც ამას აკეთებს. გადატანამდე შეამოწმეთ მსმენელი.

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

მზადყოფნა, ბლოკირება და გადამწყვეტი

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

სახელთა სივრცის გაზიარება ასევე ნიშნავს, რომ აპლიკაცია მემკვიდრეობით იღებს VPN კონტეინერის გადამწყვეტს, რაც ეხმარება, როცა გვირაბი DNS სერვერებს აწვება, და აბნევს, როცა არ აკეთებს. შეამოწმეთ, რას შეიცავს სახელთა სივრცე სინამდვილეში, იმის ნაცვლად, რომ ივარაუდოთ ჰოსტის გადამწყვეტის მოქმედება. Compose სერვისების ცნობარი ერთ ადგილას აფიქსირებს network_mode-ს, ports-ს და დამოკიდებულებების ქცევას, მათ შორის, რატომ არ აქვს network_mode სერვისს საკუთარი მისამართი.