तुमचा कॉर्पोरेट प्रॉक्सी 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 नाव शिकवता येत नाही.

इच्छित विभाजन राखा: अंतर्गत विनंत्या त्यांचा अंतर्गत मार्ग वापरतात; बाह्य विनंत्या मंजूर प्रॉक्सी राखतात. प्रॉक्सी जागतिकरित्या अक्षम केल्याने हे एक अपयश लपू शकते आणि पुढील बाह्य विनंतीसाठी आवश्यक मार्ग काढून टाकू शकतो.