உங்கள் கார்ப்பரேட் ப்ராக்ஸி ஏன் 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 பெயரைக் கற்பிக்க முடியாதது போல.

எண்ணப்பட்ட பிரிவைப் பராமரிக்கவும்: உள் கோரிக்கைகள் அவற்றின் உள் பாதையைப் பயன்படுத்துகின்றன; வெளிப்புற கோரிக்கைகள் அங்கீகரிக்கப்பட்ட ப்ராக்ஸியை வைத்திருக்கின்றன. ப்ராக்ஸியை உலகளவில் முடக்குவது இந்த ஒரு தோல்வியை மறைக்கலாம், அதே வேளையில் அடுத்த வெளிப்புற கோரிக்கைக்குத் தேவையான பாதையை அகற்றலாம்.