Ինչու ձեր կորպորատիվ պրոքսին փորձում է լուծել Compose ծառայության անունը

HTTP հաճախորդը կարող է ներքին ծառայության հարցումն ուղարկել իր կազմաձևված պրոքսիին նախքան Docker-ի ծառայության անվան լուծումն օգտագործելը: Ավելացրեք դիտավորյալ շրջանցումներ ճիշտ հաճախորդի համար:

Հավելվածը համացանցին հասնում է իր կորպորատիվ պրոքսիի միջոցով, բայց http://catalog:8080/ ձախողվում է, և պրոքսին չի կարող լուծել “catalog”-ը: Հնարավոր է, որ այդ հարցումը երբեք չի օգտագործել Docker-ի ներքին DNS-ը:

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 անուն:

Պահպանեք նախատեսված բաժանումը. ներքին հարցումները օգտագործում են իրենց ներքին ուղին. արտաքին հարցումները պահպանում են հաստատված պրոքսին: Պրոքսիի գլոբալ անջատումը կարող է թաքցնել այս մեկ ձախողումը՝ միաժամանակ հեռացնելով հաջորդ արտաքին հարցման համար անհրաժեշտ ուղին:

Առնչվող հոդվածներ