Чому ваш корпоративний проксі намагається розв'язати ім'я сервісу Compose

Застосунок виходить в інтернет через корпоративний проксі, але 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.

Зберігайте задуманий поділ: внутрішні запити використовують свій внутрішній шлях; зовнішні запити зберігають схвалений проксі. Глобальне вимкнення проксі може приховати цю єдину несправність, водночас прибравши маршрут, потрібний для наступного зовнішнього запиту.