Эмне үчүн корпоративдик проксиңиз 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

Сүрөттөгү чыныгы китепкананы же аткарылуучу файлды тамга регистрин иштетүү, версия жана дал келүү грамматикасы боюнча текшериңиз. Universal NO_PROXY анализатору жок. Кичинекей сүрөттөгү wget аттуу программа GNU Wget сыяктуу иштей берүүгө милдеттүү эмес.

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

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

Тектеш макалалар