Podman pasta: રૂટલેસ કન્ટેનરમાંથી હોસ્ટ લૂપબેક પ્રોક્સી સુધી પહોંચો

હાલની લૂપબેક પ્રોક્સી માટે pasta ના namespace-to-host TCP ફોરવર્ડિંગનો ઉપયોગ કરો અને તેને કન્ટેનર પોર્ટ પ્રકાશિત કરવાથી અલગ રાખો.

હોસ્ટનું 127.0.0.1:8118 અને કન્ટેનરનું 127.0.0.1:8118 સામાન્ય રીતે અલગ લૂપબેક એન્ડપોઇન્ટ હોય છે. રૂટલેસ કન્ટેનરમાં પ્રોક્સી વેરિયેબલ પસાર કરવાથી તે લૂપબેક ઇન્ટરફેસ જોડાતા નથી.

pasta વાપરતા Podman ડિપ્લોયમેન્ટમાં, તેનું namespace-to-host TCP ફોરવર્ડિંગ namespaceની અંદર ઇચ્છિત હોસ્ટ પોર્ટ ખુલ્લું કરી શકે છે:

podman run --network=pasta:-T,8118 \
  --env http_proxy=http://127.0.0.1:8118 \
  --env https_proxy=http://127.0.0.1:8118 \
  existing-image application-command

એપ્લિકેશનની હાલની ઇમેજ અને કમાન્ડ વાપરો. ઉદાહરણ ધારે છે કે હોસ્ટ બાજુએ પોર્ટ 8118 પર કાર્યરત HTTP પ્રોક્સી છે અને બતાવેલ ફોરવર્ડિંગ વિકલ્પને સમર્થન આપતું Podman/pasta સંસ્કરણ છે.

pasta નું મોટું -T લક્ષ્ય namespaceથી હોસ્ટ namespace તરફ ફોરવર્ડ કરે છે. નાનું -t અને Podman નું --publish વિરુદ્ધ દિશા લે છે. તેથી કન્ટેનર પોર્ટ 8118 પ્રકાશિત કરવાથી હોસ્ટની પ્રોક્સી પોતાની રીતે કન્ટેનર માટે ઉપલબ્ધ થતી નથી.

Podman ડિફોલ્ટ રીતે namespace-to-host પોર્ટનું સ્વયં ફોરવર્ડિંગ બંધ કરે છે; સ્પષ્ટ પોર્ટ અહીં જરૂરી સેવા પસંદ કરે છે. અલગ pasta:--map-gw વિકલ્પ ગેટવે સરનામા દ્વારા હોસ્ટ સુધી પહોંચવાનો છે, જે બીજી ગોઠવણ છે.

Compose સાથે, વાસ્તવિક પ્રોવાઇડર અને જનરેટ થયેલ નેટવર્ક રૂપરેખા તપાસો. નામવાળું બ્રિજ નેટવર્ક આપોઆપ pasta namespace નથી, ફક્ત એટલા માટે કે સ્વતંત્ર podman run કમાન્ડે pasta સફળતાપૂર્વક વાપર્યું. રિમોટ Podman એન્જિન પણ “હોસ્ટ”ને એન્જિનના સ્થાને મૂકે છે.

સંબંધિત લેખો