एका भाषांतर गेटवेमागील तीन प्रॉक्सी प्रतिकृती तरीही एकच सार्वजनिक निर्गम दाखवू शकतात. खाजगी कंटेनर पत्ते गंतव्यस्थानी दिसणारी ओळख ठरवत नाहीत.

client → published service → proxy replica → egress/NAT → destination

चित्र दोन भागांत पाहा. प्रकाशित सेवा ठरवते की ग्राहक प्रतिकृतीपर्यंत कसा पोहोचतो. इग्रेस मार्ग आणि NAT त्या प्रतिकृतीच्या पुढील कनेक्शनचा स्रोत पत्ता निवडतात.

Docker Swarm चे राउटिंग मेश प्रकाशित सेवा पोर्टवर रहदारी स्वीकारते आणि ती सक्रिय कार्याकडे पाठवते. हे प्रवेश वितरण आणि कार्य स्थान बदलांना आधार देते; ते प्रत्येक प्रतिकृतीला वेगळे सार्वजनिक निर्गम देत नाही.

जर वेगळे निर्गम हवे असतील, तर त्यांचे खरे मार्ग आणि पत्ते रचा, जसे वेगळे राउट केलेले होस्ट किंवा नेमून दिलेले इग्रेस गेटवे, मग निरीक्षित बाह्य ओळखी मोजा.

प्रतिकृती बदलल्यास तिचे जिवंत स्ट्रीमही बदलतात

स्थापित CONNECT बोगदा एका प्रॉक्सी प्रक्रियेचा असतो. ती प्रक्रिया बदलताना दुसरे कार्य गंतव्यस्थानाची TCP आणि TLS स्थिती पारदर्शकपणे पुन्हा तयार करू शकत नाही. पुनर्कनेक्शनचे नियोजन करा आणि देखभालीसाठी दीर्घकालीन कनेक्शन रिकामी करा.

ग्राहक प्रमाणीकरण आणि गंतव्य धोरणे प्रतिकृतींमध्येही न्या. लोड बॅलन्सरची यशस्वी पोर्ट तपासणी आवश्यक प्रॉक्सी प्रोटोकॉलवर वाटाघाटी करणाऱ्या परवानगी असलेल्या ग्राहकापेक्षा अरुंद आहे. क्षमता, निर्गम ओळख आणि कनेक्शन टिकून राहणे ही स्वतंत्रपणे मूल्यांकन करण्याची आवश्यकता आहे.

संबंधित लेख