Bakit hindi awtomatikong ginagamit ng proxy container ang DNS container

Ang pagbabahagi ng Docker host, pagbabahagi ng network at pagpili ng resolver ay tatlong magkaibang bagay. Subaybayan ang DNS query mula sa loob ng proxy.

Ang pagpapatakbo ng proxy at DNS server sa isang Docker host ay hindi nag-uugnay sa kanilang mga landas ng DNS. Tatlong magkahiwalay na ugnayan ang mahalaga:

  • Pag-abot ng network. Ang magkahiwalay na proyekto ng Compose ay karaniwang may magkahiwalay na default na network. Ilagay ang mga serbisyo sa angkop na pinagsasaluhang network, maging sa loob ng isang proyekto o sa pamamagitan ng network na tahasang pinagsasaluhan ng mga proyekto.
  • Pagtuklas ng serbisyo. Ang naka-embed na DNS ng pasadyang Docker network ay makakapag-resolve ng mga pangalan ng container. Nakakatulong ito sa application na matuklasan ang isang kapitbahay; ngunit hindi nito awtomatikong pinipili ang kapitbahay na iyon bilang DNS resolver nito.
  • Pagpili ng resolver. Tukuyin ang resolver na ginagamit sa loob ng proxy container. Tumatanggap ang field na dns ng Compose ng mga address ng DNS server. Ang pangalang tulad ng dns.local na nire-resolve sa isang application ay hindi nagiging wastong halaga para sa field na iyon.

Subaybayan ang query mula sa proxy container hanggang sa naka-configure na address ng resolver. Tiyakin na may ruta at DNS listener sa address na iyon. Ang pag-publish ng port 53 ng host ay lumilikha ng landas ng pag-access sa panig ng host; ngunit hindi nito sinasabi sa mga container na gamitin ito. Ang mga container na nagbabahagi ng network ay maaaring direktang mag-usap sa halip.

Kung ang configuration ay tumutukoy sa address ng DNS container, panatilihin itong matatag sa ilalim ng katugmang configuration ng IPAM. Ang address na dinamikong inilaan at kinopya mula sa container kahapon ay maaaring mabigo kapag muling ginawa. Suriin din ang upstream na landas ng resolver: ang pagpapadala ng mga query na walang sagot pabalik dito mismo ay lumilikha ng ibang pagkabigo kaysa sa isang resolver na hindi maabot.

Sa wakas, tukuyin kung sino ang nagre-resolve ng patutunguhan. Ang HTTP proxy na nagre-resolve ng pangalang CONNECT ay maaaring gumamit ng landas na ito sa container; ang SOCKS client na nagre-resolve nang lokal ay maaaring hindi. Ang paghahanap sa host ay nagpapatunay ng ruta ng host, hindi ng proseso ng proxy.

Kaugnay na mga artikulo