Извршувањето прокси и DNS сервер на ист Docker домаќин не ги поврзува нивните DNS патеки. Важни се три одделни врски:

  • Мрежна достапност. Одделните Compose проекти обично имаат одделни стандардни мрежи. Ставете ги услугите на соодветна споделена мрежа, или во еден проект или преку мрежа што е експлицитно споделена меѓу проекти.
  • Откривање услуги. Вградениот DNS на прилагодена Docker мрежа може да ги реши имињата на контејнерите. Тоа му овозможува на апликацијата да открие сосед; но не го избира автоматски тој сосед како свој DNS resolver.
  • Избор на resolver. Определете го resolver-от што се користи внатре во прокси контејнерот. Полето dns на Compose прима адреси на DNS сервери. Име како dns.local што се решава во апликација не го прави валидна вредност за тоа поле.

Следете го барањето од прокси контејнерот до неговата конфигурирана адреса на resolver. Потврдете дека на таа адреса има рута и DNS слушател. Објавувањето на портата 53 на домаќинот создава пристапен пат од страната на домаќинот; но не им кажува на контејнерите да го користат. Контејнерите што споделуваат мрежа можат наместо тоа да комуницираат директно.

Ако конфигурацијата се однесува на адресата на DNS контејнерот, одржувајте ја стабилна при компатибилна IPAM конфигурација. Динамички доделена адреса копирана од вчерашниот контејнер може да не успее при повторно создавање. Проверете ја и горната патека на resolver-от: препраќањето неодговорени барања назад кон самиот него создава поинаков неуспех од недостапен resolver.

На крај, определете кој ја решава дестинацијата. HTTP прокси што решава CONNECT име може да ја користи оваа контејнерска патека; SOCKS клиент што решава локално можеби не. Пребарувањето на домаќинот ја докажува рутата на домаќинот, не онаа на прокси процесот.

Поврзани статии