Zergatik proxy edukiontziak ez du automatikoki DNS edukiontzia erabiltzen

Proxy bat eta DNS zerbitzari bat Docker ostalari berean exekutatzeak ez ditu haien DNS bideak lotzen. Hiru erlazio bereizik dute garrantzia:

• Sarearen irisgarritasuna. Compose proiektu bereiziek normalean lehenetsitako sare bereiziak izaten dituzte. Jarri zerbitzuak egoki den sare partekatu batean, proiektu baten barruan edo proiektuen artean berariaz partekatutako sare baten bidez.
• Zerbitzuen aurkikuntza. Docker sare pertsonalizatu baten barneko DNSak edukiontzi-izenak ebatzi ditzake. Horrek aplikazio bati bizilagun bat aurkitzea ahalbidetzen dio; baina ez du bizilagun hori automatikoki bere DNS resolver gisa hautatzen.
• Resolver hautaketa. Identifikatu proxy edukiontziaren barruan erabiltzen den resolverra. Compose-ren dns eremuak DNS zerbitzarien helbideak onartzen ditu. Aplikazio batean ebazten den dns.local bezalako izen batek ez du eremu horretarako balio baliodun bihurtzen.

Jarraitu kontsulta proxy edukiontzitik haren resolver helbide konfiguratura arte. Egiaztatu bide bat eta DNS entzule bat daudela helbide horretan. Ostalariaren 53 portua argitaratzeak ostalariaren aldeko sarbide-bide bat sortzen du; baina ez die edukiontziei hura erabiltzeko esaten. Sare bat partekatzen duten edukiontzik zuzenean komunika daitezke horren ordez.

Konfigurazioak DNS edukiontziaren helbidea aipatzen badu, mantendu egonkor IPAM konfigurazio bateragarriaren pean. Atzoko edukiontzitik kopiatutako dinamikoki esleitutako helbide batek huts egin dezake birsortzean. Aztertu resolverraren gorako bidea ere: erantzun gabeko kontsultak berari itzultzeak resolver eskuraezin batena ez bezalako hutsegitea sortzen du.

Azkenik, identifikatu nork ebazten duen helmuga. CONNECT izen bat ebazten duen HTTP proxyak edukiontzi-bide hau erabil dezake; tokian bertan ebazten duen SOCKS bezeroak agian ez. Ostalarian egindako bilaketak ostalariaren bidea frogatzen du, ez proxy prozesuarena.