एउटा अनुवादक गेटवे पछाडिका तीन प्रोक्सी प्रतिलिपिले अझै एउटै सार्वजनिक निकास देखाउन सक्छन्। निजी कन्टेनर ठेगानाहरूले गन्तव्यमा देखिने पहिचान निर्धारण गर्दैनन्।

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

चित्रलाई दुई भागमा पछ्याउनुहोस्। प्रकाशित सेवाले ग्राहक कसरी प्रतिलिपिमा पुग्छ भन्ने छनोट गर्छ। इग्रेस मार्ग र NAT ले त्यो प्रतिलिपिको अर्को जडानको स्रोत ठेगाना छनोट गर्छन्।

Docker Swarm को राउटिङ मेशले प्रकाशित सेवा पोर्टमा ट्राफिक स्वीकार गरी सक्रिय कार्यमा पठाउँछ। यसले प्रवेश वितरण र कार्य स्थान परिवर्तनलाई समर्थन गर्छ; यसले प्रत्येक प्रतिलिपिलाई छुट्टै सार्वजनिक निकास दिँदैन।

यदि छुट्टै निकास चाहिन्छ भने, तिनीहरूका वास्तविक मार्ग र ठेगाना डिजाइन गर्नुहोस्, जस्तै अलग राउट गरिएका होस्ट वा तोकिएका इग्रेस गेटवे, त्यसपछि अवलोकन गरिएका बाह्य पहिचानहरू गन्नुहोस्।

प्रतिलिपि बदल्दा त्यसका जीवित स्ट्रिमहरू पनि बदलिन्छन्

स्थापित CONNECT सुरुङ एउटै प्रोक्सी प्रक्रियाको हुन्छ। त्यो प्रक्रिया बदल्दा अर्को कार्यले गन्तव्यको TCP र TLS अवस्था पारदर्शी रूपमा पुनः सिर्जना गर्न सक्दैन। पुनःजडानको योजना बनाउनुहोस् र मर्मतका लागि दीर्घकालीन जडानहरू खाली गर्नुहोस्।

ग्राहक प्रमाणीकरण र गन्तव्य नीतिहरू पनि प्रतिलिपिहरूमा सार्नुहोस्। लोड ब्यालेन्सरको सफल पोर्ट जाँच आवश्यक प्रोक्सी प्रोटोकलमा वार्ता गर्ने अनुमति प्राप्त ग्राहकभन्दा साँघुरो हुन्छ। क्षमता, निकास पहिचान र जडानको टिकाइ अलग-अलग मूल्याङ्कन गर्नुपर्ने आवश्यकताहरू हुन्।

सम्बन्धित लेखहरू