Защо корпоративният ви прокси се опитва да резолвне име на услуга на 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.

Запазете предвиденото разделение: вътрешните заявки използват вътрешния си път; външните заявки запазват одобреното прокси. Глобалното изключване на проксито може да скрие този единствен провал, като същевременно премахне маршрута, необходим за следващата външна заявка.

Подобни статии