Зашто ваш корпоративни прокси покушава да разреши назив Compose сервиса

HTTP клијент може послати захтев за интерним сервисом свом конфигурисаном проксију пре него што употреби Docker-ово разрешавање назива сервиса. Додајте намерна заобилажења за прави клијент.

Апликација долази на интернет преко свог корпоративног проксија, али http://catalog:8080/ не успева и прокси не може да разреши “catalog”. Тај захтев можда никада није користио Docker-ов интерни DNS.

HTTP клијент може да одабере свој прокси пре успостављања директне везе. Спољни прокси тада прима назив чије значење постоји само унутар Compose мреже.

  1. Користите име хоста у захтеву. Compose сервиси су доступни по називу сервиса на одговарајућој мрежи. Додајте catalog у подржану конфигурацију заобилажења клијента који га користи, уместо да тврдо кодирате IP контејнера који се може променити.
  2. Сачувајте постојеће изузетке. За клијент који познаје окружење, спојите релевантне уносе са листом организације:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Проверите стварну библиотеку или извршну датотеку у слици у погледу руковања великим и малим словима, верзије и граматике упаривања. Не постоји универзални парсер NO_PROXY. Програм по имену wget у малој слици не мора да се понаша као GNU Wget.

Након што захтев одабере директно усмеравање, проверите заједничку мрежу позиваоца и сервиса, сервис који слуша и порт контејнера. Објављени порт хоста је друга крајња тачка. Заобилажење не може да дода недостајућу мрежну везу, као што ни поновно стварање мреже не може спољни прокси да научи приватни Compose назив.

Задржите предвиђену поделу: интерни захтеви користе своју интерну путању; спољни захтеви задржавају одобрени прокси. Глобално онемогућавање проксија може сакрити овај један квар док уклања путању потребну за следећи спољни захтев.

Повезани чланци