რატომ არ იყენებს პროქსი-კონტეინერი DNS კონტეინერს ავტომატურად

პროქსისა და DNS სერვერის ერთ Docker ჰოსტზე გაშვება მათ DNS გზებს არ აკავშირებს. მნიშვნელოვანია სამი ცალკე კავშირი:

• ქსელური ხელმისაწვდომობა. ცალკე Compose პროექტებს ჩვეულებრივ ცალკე ნაგულისხმევი ქსელები აქვთ. განათავსეთ სერვისები შესაბამის საზიარო ქსელში, ან ერთი პროექტის შიგნით, ან პროექტებს შორის ცხადად გაზიარებული ქსელის მეშვეობით.
• სერვისების აღმოჩენა. მორგებული Docker ქსელის ჩაშენებულ DNS-ს შეუძლია კონტეინერის სახელების ამოხსნა. ეს აპლიკაციას მეზობლის აღმოჩენის საშუალებას აძლევს, მაგრამ ავტომატურად არ ირჩევს ამ მეზობელს თავის DNS რეზოლვერად.
• რეზოლვერის არჩევა. დაადგინეთ პროქსი-კონტეინერის შიგნით გამოყენებული რეზოლვერი. Compose-ის dns ველი იღებს DNS სერვერების მისამართებს. dns.local-ის მსგავსი სახელი, რომელიც აპლიკაციაში იხსნება, ამ ველისთვის ნამდვილ მნიშვნელობად არ იქცევა.

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

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

დაბოლოს, დაადგინეთ, ვინ ხსნის დანიშნულებას. HTTP პროქსის, რომელიც CONNECT სახელს ხსნის, შეუძლია ამ კონტეინერის გზის გამოყენება; ლოკალურად ხსნილ SOCKS კლიენტს შეიძლება არ შეეძლოს. ჰოსტზე ძებნა ჰოსტის მარშრუტს ამტკიცებს, არა პროქსი პროცესისას.