તમારો કોર્પોરેટ પ્રોક્સી શા માટે Compose સેવાનું નામ ઉકેલવાનો પ્રયાસ કરી રહ્યો છે

એપ્લિકેશન તેના કોર્પોરેટ પ્રોક્સી દ્વારા ઇન્ટરનેટ સુધી પહોંચે છે, પરંતુ 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

ઇમેજમાંની વાસ્તવિક લાઇબ્રેરી કે એક્ઝિક્યુટેબલની કેસ હેન્ડલિંગ, સંસ્કરણ અને મેચિંગ ગ્રામર તપાસો. કોઈ સાર્વત્રિક NO_PROXY પાર્સર નથી. નાની ઇમેજમાં wget નામનો પ્રોગ્રામ GNU Wget જેવું વર્તન કરવાની જરૂર નથી.

વિનંતી સીધું રૂટિંગ પસંદ કરે પછી, કૉલર અને સેવાનું સહિયારું નેટવર્ક, સાંભળતી સેવા અને કન્ટેનર પોર્ટ તપાસો. પ્રકાશિત હોસ્ટ પોર્ટ બીજો એન્ડપોઇન્ટ છે. બાયપાસ ખૂટતું નેટવર્ક જોડાણ ઉમેરી શકતું નથી, જેમ નેટવર્ક ફરી બનાવવાથી બાહ્ય પ્રોક્સીને ખાનગી Compose નામ શીખવી શકાતું નથી.

ઇચ્છિત વિભાજન જાળવો: આંતરિક વિનંતીઓ તેમનો આંતરિક માર્ગ વાપરે છે; બાહ્ય વિનંતીઓ મંજૂર પ્રોક્સી રાખે છે. પ્રોક્સીને વૈશ્વિક રીતે અક્ષમ કરવાથી આ એક નિષ્ફળતા છુપાઈ શકે છે અને સાથે જ આગલી બાહ્ય વિનંતી માટે જરૂરી માર્ગ દૂર થઈ શકે છે.