Ինչու պրոքսի կոնտեյները ինքնաշխատ չի օգտագործում DNS կոնտեյները

Պրոքսին և DNS սերվերը մեկ Docker-հոսթի վրա գործարկելը չի միացնում նրանց DNS ուղիները։ Կարևոր են երեք առանձին կապեր.

• Ցանցային հասանելիություն։ Առանձին Compose նախագծերը սովորաբար ունեն առանձին լռելյայն ցանցեր։ Տեղադրեք ծառայությունները համապատասխան համօգտագործվող ցանցում՝ կա՛մ մեկ նախագծի ներսում, կա՛մ նախագծերի միջև բացահայտ համօգտագործվող ցանցի միջոցով։
• Ծառայությունների հայտնաբերում։ Հատուկ Docker ցանցի ներկառուցված DNS-ը կարող է լուծել կոնտեյներների անունները։ Դա թույլ է տալիս հավելվածին հայտնաբերել հարևանին, սակայն այն ինքնաշխատ չի ընտրում այդ հարևանին որպես իր DNS լուծիչ։
• Լուծիչի ընտրություն։ Որոշեք պրոքսի կոնտեյների ներսում օգտագործվող լուծիչը։ Compose-ի dns դաշտը ընդունում է DNS սերվերների հասցեներ։ dns.local-ի նման անունը, որը լուծվում է հավելվածում, այն վավեր արժեք չի դարձնում այդ դաշտի համար։

Հետևեք հարցմանը պրոքսի կոնտեյներից մինչև դրա կարգավորված լուծիչի հասցեն։ Հաստատեք, որ այդ հասցեում կա երթուղի և DNS լսող։ Հոսթի 53 պորտը հրապարակելը ստեղծում է մուտքի ուղի հոսթի կողմից, բայց չի ասում կոնտեյներներին օգտագործել այն։ Ցանցը համօգտագործող կոնտեյներները կարող են փոխարենը շփվել ուղղակիորեն։

Եթե կարգավորումը հղում է DNS կոնտեյների հասցեին, պահեք այն կայուն համատեղելի IPAM կարգավորման ներքո։ Երեկվա կոնտեյներից պատճենված դինամիկ հատկացված հասցեն կարող է ձախողվել վերստեղծման ժամանակ։ Ստուգեք նաև լուծիչի վերին ուղին․ չպատասխանված հարցումները հետ ուղարկելը հենց իրեն ստեղծում է այլ ձախողում, քան անհասանելի լուծիչը։

Վերջապես, որոշեք, թե ով է լուծում նպատակակետը։ CONNECT անունը լուծող HTTP պրոքսին կարող է օգտագործել այս կոնտեյներային ուղին, իսկ տեղում լուծող SOCKS հաճախորդը՝ գուցե ոչ։ Հոսթի որոնումը ապացուցում է հոսթի երթուղին, ոչ թե պրոքսի գործընթացինը։