Kodėl tarpinio serverio konteineris automatiškai nenaudoja DNS konteinerio

Tarpinio serverio ir DNS serverio paleidimas vienoje Docker priegloboje nesujungia jų DNS kelių. Svarbūs trys atskiri ryšiai:

• Tinklo pasiekiamumas. Atskiri Compose projektai paprastai turi atskirus numatytuosius tinklus. Įdėkite paslaugas į tinkamą bendrinamą tinklą – arba vieno projekto viduje, arba per tinklą, kuris aiškiai bendrinamas tarp projektų.
• Paslaugų aptikimas. Pasirinktinio Docker tinklo įtaisytasis DNS gali išspręsti konteinerių pavadinimus. Tai leidžia programai aptikti kaimyną, bet automatiškai nepasirenka to kaimyno kaip savo DNS resolverio.
• Resolverio pasirinkimas. Nustatykite, koks resolveris naudojamas tarpinio serverio konteineryje. Compose laukas dns priima DNS serverių adresus. Pavadinimas, pavyzdžiui, dns.local, kuris išsprendžiamas programoje, netampa tinkama to lauko reikšme.

Sekite užklausą nuo tarpinio serverio konteinerio iki jo sukonfigūruoto resolverio adreso. Patvirtinkite, kad tame adrese yra maršrutas ir DNS klausytojas. Viešinant prieglobos 53 prievadą sukuriamas prieigos kelias prieglobos pusėje, bet konteineriams nėra sakoma juo naudotis. Tinklą bendrinantys konteineriai gali vietoj to bendrauti tiesiogiai.

Jei konfigūracija nurodo DNS konteinerio adresą, išlaikykite jį stabilų suderinamoje IPAM konfigūracijoje. Dinamiškai priskirtas adresas, nukopijuotas iš vakarėjusio konteinerio, gali nepavykti iš naujo kuriant. Taip pat patikrinkite resolverio aukštupio kelią: neatsakytų užklausų persiuntimas atgal jam pačiam sukuria kitokią gedimą nei nepasiekiamas resolveris.

Galiausiai nustatykite, kas išsprendžia paskirties vietą. HTTP tarpinė, kuri išsprendžia CONNECT pavadinimą, gali naudoti šį konteinerio kelią; SOCKS klientas, kuris sprendžia vietoje, gali ir ne. Prieglobos užklausa įrodo prieglobos maršrutą, o ne tarpinio serverio proceso.