Bilangin ang mga labasan ng proxy nang hiwalay sa mga replica

Tatlong replica ng proxy sa likod ng isang gateway na nagsasalin ay maaari pa ring magpakita ng isang pampublikong labasan. Hindi tinutukoy ng mga pribadong address ng container ang pagkakakilanlang nakikita sa destinasyon.

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

Sundin ang guhit sa dalawang bahagi. Pinipili ng nailathalang serbisyo kung paano naaabot ng kliyente ang isang replica. Pinipili ng ruta ng labasan at NAT ang source address ng susunod na koneksyon ng replica na iyon.

Tinatanggap ng routing mesh ng Docker Swarm ang trapiko sa isang nailathalang port ng serbisyo at ipinapadala ito sa aktibong gawain. Sinusuportahan nito ang pamamahagi ng pasukan at mga pagbabago sa paglalagay ng gawain; hindi ito naglalaan ng natatanging pampublikong labasan sa bawat replica.

Kung kailangan ang magkakaibang labasan, idisenyo ang kanilang tunay na ruta at address, tulad ng hiwalay na niruruta na host o itinalagang gateway ng labasan, pagkatapos ay bilangin ang mga naobserbahang panlabas na pagkakakilanlan.

Ang pagpapalit ng replica ay nagpapalit din ng mga live na stream nito

Ang isang naitatag na tunnel ng CONNECT ay pag-aari ng isang proseso ng proxy. Hindi maaaring muling likhain ng ibang gawain nang malinaw ang estado ng TCP at TLS ng destinasyon kapag pinalitan nito ang prosesong iyon. Planuhin ang mga muling pagkonekta at alisan ng laman ang mga pangmatagalang koneksyon para sa maintenance.

Ilipat din ang pagpapatunay ng kliyente at mga patakaran ng destinasyon sa mga replica. Ang matagumpay na pagsusuri ng port ng isang load balancer ay mas makitid kaysa sa isang pinapayagang kliyenteng nakikipag-usap sa kinakailangang protocol ng proxy. Ang kapasidad, pagkakakilanlan ng labasan at pagpapatuloy ng koneksyon ay magkakahiwalay na pangangailangang suriin.