የድርጅትዎ ፕሮክሲ የCompose አገልግሎት ስም ለመፍታት የሚሞክረው ለምን ነው
የHTTP ደንበኛ የDocker አገልግሎት-ስም መፍታትን ከመጠቀሙ በፊት የውስጥ አገልግሎት ጥያቄን ወደ ተዋቀረው ፕሮክሲ ሊልክ ይችላል። ለትክክለኛው ደንበኛ ሆን ተብሎ የማለፍ ማዋቀሪያዎችን ይጨምሩ።
መተግበሪያው በድርጅት ፕሮክሲው በኩል ወደ ኢንተርኔት ይደርሳል፣ ነገር ግን http://catalog:8080/ አይሳካም እና ፕሮክሲው “catalog” ማፍታት አይችልም። ያ ጥያቄ የDocker ውስጣዊ DNS በጭራሽ ላይጠቀም ይችላል።
የHTTP ደንበኛ ቀጥተኛ ግንኙነት ከመፍጠሩ በፊት ፕሮክሲውን መምረጥ ይችላል። ከዚያ ውጫዊው ፕሮክሲ ትርጉሙ በCompose አውታረ መረብ ውስጥ ብቻ የሚኖር ስም ይቀበላል።
- በጥያቄው ውስጥ የአስተናጋጁን ስም ይጠቀሙ። የCompose አገልግሎቶች በሚገባው አውታረ መረብ ላይ በአገልግሎት ስም ይታወቃሉ። ሊለወጥ የሚችል የኮንቴይነር IP በጠንካራ ኮድ ከመጻፍ ይልቅ
catalogን በተጠቃሚው ደንበኛ የሚደገፈው የማለፍ ውቅር ውስጥ ይጨምሩ። - ነባር ልዩ ሁኔታዎችን ይጠብቁ። አካባቢን ለሚለይ ደንበኛ ተጓዳኝ ግቤቶችን ከድርጅቱ ዝርዝር ጋር ያዋህዱ፦
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogበምስሉ ውስጥ ያለውን ቤተ-መጽሐፍት ወይም ፕሮግራም ለፊደል አያያዝ፣ ስሪት እና የማዛመጃ ሰዋሰው ይመልከቱ። ሁሉን አቀፍ NO_PROXY ተንታኝ የለም። በትንሽ ምስል ውስጥ wget የሚባል ፕሮግራም እንደ GNU Wget መሆን የለበትም።
ጥያቄው ቀጥተኛ መንገድን ከመረጠ በኋላ የጠሪውን እና የአገልግሎቱን የጋራ አውታረ መረብ፣ የሚያዳምጠውን አገልግሎት እና የኮንቴይነር ወደብ ያረጋግጡ። የታተመ የአስተናጋጅ ወደብ ሌላ መጨረሻ ነው። የማለፍ ውቅር የጎደለ የአውታረ መረብ ግንኙነት ማከል አይችልም፤ አውታረ መረብን እንደገና መፍጠር ውጫዊ ፕሮክሲን የግል Compose ስም ማስተማር እንደማይችል ሁሉ።
የታሰበውን ክፍፍል ይጠብቁ፦ የውስጥ ጥያቄዎች የውስጥ መንገዳቸውን ይጠቀማሉ፤ ውጫዊ ጥያቄዎች የተፈቀደውን ፕሮክሲ ይይዛሉ። ፕሮክሲውን በአጠቃላይ ማሰናከል ይህን አንድ ውድቀት ሊደብቅ ይችላል፣ ለሚቀጥለው ውጫዊ ጥያቄ የሚያስፈልገውን መንገድ ሲያስወግድ።