प्रॉक्सी निकासों को प्रतिकृतियों से अलग गिनें

एक अनुवादक गेटवे के पीछे तीन प्रॉक्सी प्रतिकृतियाँ फिर भी एक सार्वजनिक निकास दिखा सकती हैं। निजी कंटेनर पते गंतव्य पर दिखने वाली पहचान तय नहीं करते।

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

चित्र को दो भागों में देखें। प्रकाशित सेवा चुनती है कि ग्राहक किसी प्रतिकृति तक कैसे पहुँचे। इग्रेस मार्ग और NAT उस प्रतिकृति के आगे के कनेक्शन का स्रोत पता चुनते हैं।

Docker Swarm का रूटिंग मेश प्रकाशित सेवा पोर्ट पर ट्रैफ़िक स्वीकार करता है और उसे किसी सक्रिय कार्य को भेजता है। यह प्रवेश वितरण और कार्य स्थान परिवर्तन का समर्थन करता है; यह हर प्रतिकृति को अलग सार्वजनिक निकास नहीं देता।

यदि अलग निकास चाहिए, तो उनके वास्तविक मार्ग और पते डिज़ाइन करें, जैसे अलग रूट किए गए होस्ट या निर्धारित इग्रेस गेटवे, फिर देखी गई बाहरी पहचानें गिनें।

प्रतिकृति बदलने पर उसकी जीवित स्ट्रीम भी बदल जाती हैं

स्थापित CONNECT सुरंग एक ही प्रॉक्सी प्रक्रिया की होती है। उस प्रक्रिया को बदलते समय दूसरा कार्य गंतव्य की TCP और TLS स्थिति को पारदर्शी रूप से फिर से नहीं बना सकता। पुनःकनेक्शन की योजना बनाएँ और रखरखाव के लिए दीर्घकालिक कनेक्शन खाली करें।

ग्राहक प्रमाणीकरण और गंतव्य नीतियाँ भी प्रतिकृतियों तक ले जाएँ। लोड बैलेंसर की सफल पोर्ट जाँच आवश्यक प्रॉक्सी प्रोटोकॉल पर बातचीत करने वाले अनुमत ग्राहक से अधिक सीमित है। क्षमता, निकास पहचान और कनेक्शन का टिकना अलग-अलग मूल्यांकन योग्य आवश्यकताएँ हैं।