પ્રોક્સી એક્ઝિટને રેપ્લિકાથી અલગ ગણો

એક અનુવાદક ગેટવે પાછળની ત્રણ પ્રોક્સી રેપ્લિકા હજી પણ એક જાહેર એક્ઝિટ દર્શાવી શકે છે. ખાનગી કન્ટેનર સરનામાં લક્ષ્ય પર દેખાતી ઓળખ નક્કી કરતા નથી.

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

રેખાચિત્રને બે ભાગમાં અનુસરો. પ્રકાશિત સેવા પસંદ કરે છે કે ક્લાયન્ટ રેપ્લિકા સુધી કેવી રીતે પહોંચે. એગ્રેસ રૂટ અને NAT તે રેપ્લિકાના આગળના કનેક્શનનું સ્રોત સરનામું પસંદ કરે છે.

Docker Swarmની રાઉટિંગ મેશ પ્રકાશિત સેવા પોર્ટ પર ટ્રાફિક સ્વીકારે છે અને તેને સક્રિય કાર્ય પર મોકલે છે. તે પ્રવેશ વિતરણ અને કાર્ય સ્થાન બદલાવને સમર્થન આપે છે; તે દરેક રેપ્લિકાને અલગ જાહેર એક્ઝિટ સોંપતું નથી.

જો અલગ એક્ઝિટ જરૂરી હોય, તો તેમના વાસ્તવિક રૂટ અને સરનામાં ડિઝાઇન કરો, જેમ કે અલગ રાઉટ કરેલા હોસ્ટ અથવા ફાળવેલ એગ્રેસ ગેટવે, પછી અવલોકિત બહાર જતી ઓળખ ગણો.

રેપ્લિકા બદલવાથી તેના જીવંત સ્ટ્રીમ પણ બદલાય છે

સ્થાપિત CONNECT ટનલ એક પ્રોક્સી પ્રોસેસની હોય છે. તે પ્રોસેસને બદલતી વખતે બીજું કાર્ય લક્ષ્યની TCP અને TLS સ્થિતિ પારદર્શક રીતે ફરીથી બનાવી શકતું નથી. પુનઃકનેક્શનનું આયોજન કરો અને જાળવણી માટે લાંબા સમયના કનેક્શન ખાલી કરો.

ક્લાયન્ટ પ્રમાણીકરણ અને લક્ષ્ય નીતિઓ પણ રેપ્લિકામાં લઈ જાઓ. લોડ બેલેન્સરની સફળ પોર્ટ ચકાસણી જરૂરી પ્રોક્સી પ્રોટોકોલ વાટાઘાટ કરતા મંજૂર ક્લાયન્ટ કરતાં સાંકડી છે. ક્ષમતા, એક્ઝિટ ઓળખ અને કનેક્શનનું ટકી રહેવું એ અલગ-અલગ મૂલ્યાંકન કરવાની આવશ્યકતાઓ છે.