Почему ваш корпоративный прокси пытается разрешить имя сервиса Compose

HTTP-клиент может отправить запрос к внутреннему сервису на настроенный прокси, прежде чем использовать разрешение имён сервисов Docker. Добавьте осознанные обходы для нужного клиента.

Приложение выходит в интернет через корпоративный прокси, но http://catalog:8080/ завершается ошибкой, и прокси не может разрешить «catalog». Возможно, этот запрос ни разу не использовал внутренний DNS Docker.

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.

Сохраняйте задуманное разделение: внутренние запросы используют свой внутренний путь; внешние запросы сохраняют одобренный прокси. Глобальное отключение прокси может скрыть этот единственный сбой, одновременно убрав маршрут, необходимый для следующего внешнего запроса.

Похожие статьи