Неліктен корпоративтік проксиіңіз Compose қызметінің атауын шешуге тырысады

HTTP клиенті Docker-дің қызмет атауын шешуді қолданбас бұрын ішкі қызмет сұрауын конфигурацияланған проксиге жібере алады. Дұрыс клиент үшін әдейі айналып өтулерді қосыңыз.

Қолданба интернетке корпоративтік проксиі арқылы қосылады, бірақ http://catalog:8080/ сәтсіз аяқталады және прокси “catalog” атауын шеше алмайды. Бұл сұрау Docker-дің ішкі DNS-ін ешқашан қолданбаған болуы мүмкін.

HTTP клиенті тікелей қосылым орнатпас бұрын өз проксиін таңдай алады. Содан кейін сыртқы прокси мағынасы тек Compose желісінің ішінде болатын атауды алады.

  1. Сұрауда хост атауын қолданыңыз. Compose қызметтері тиісті желіде қызмет атауы бойынша табылады. Өзгеруі мүмкін контейнер IP-ін қатты кодтаудың орнына catalog-ді тұтынушы клиенттің қолдайтын айналып өту конфигурациясына қосыңыз.
  2. Қолданыстағы ерекшеліктерді сақтаңыз. Ортаны ескеретін клиент үшін тиісті жазбаларды ұйым тізімімен біріктіріңіз:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Кескіндегі нақты кітапхананы немесе орындалатын файлды әріп регистрін өңдеу, нұсқа және сәйкестендіру грамматикасы тұрғысынан тексеріңіз. Әмбебап NO_PROXY талдағышы жоқ. Шағын кескіндегі wget атты бағдарлама GNU Wget сияқты әрекет етуге міндетті емес.

Сұрау тікелей маршруттауды таңдағаннан кейін, шақырушы мен қызметтің ортақ желісін, тыңдайтын қызметті және контейнер портын тексеріңіз. Жарияланған хост порты — басқа шеткі нүкте. Айналып өту жетіспейтін желілік қосылымды қоса алмайды, дәл желіні қайта құру сыртқы проксиге жеке Compose атауын үйрете алмайтыны сияқты.

Көзделген бөліністі сақтаңыз: ішкі сұраулар өз ішкі жолын қолданады; сыртқы сұраулар мақұлданған проксиді сақтайды. Проксиді жаһандық өшіру осы бір ақауды жасырып, келесі сыртқы сұрау үшін қажетті маршрутты жоюы мүмкін.

Қатысты мақалалар