Podman pasta: Bereik 'n gasheer-loopbackproxy vanuit 'n rootlose houer

Gebruik pasta se naamruimte-na-gasheer-TCP-aansturing vir 'n bestaande loopbackproxy en hou dit apart van die publisering van 'n houerpoort.

Die gasheer se 127.0.0.1:8118 en die houer se 127.0.0.1:8118 is gewoonlik aparte loopback-eindpunte. Om 'n proxyveranderlike in 'n rootlose houer deur te gee, verenig nie daardie loopback-koppelvlakke nie.

Vir 'n Podman-ontplooiing wat pasta gebruik, kan sy TCP-aansturing van naamruimte na gasheer die bedoelde gasheerpoort binne die naamruimte blootstel:

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

Gebruik die toepassing se bestaande beeld en opdrag. Die voorbeeld aanvaar 'n werkende HTTP-proxy aan die gasheerkant op poort 8118 en 'n Podman/pasta-weergawe wat die getoonde aansturingsopsie ondersteun.

pasta se hoofletter -T stuur van die teikennaamruimte na die gasheernaamruimte. Kleinletter -t en Podman se --publish wys in die teenoorgestelde rigting. Om houerpoort 8118 te publiseer maak dus nie op sigself die gasheer se proxy vir die houer beskikbaar nie.

Podman skakel outomatiese poortaansturing van naamruimte na gasheer by verstek af; die eksplisiete poort kies die diens wat hier nodig is. Die afsonderlike pasta:--map-gw-opsie handel oor die bereik van die gasheer deur die gateway-adres, wat 'n ander reëling is.

Met Compose moet jy die werklike verskaffer en die gegenereerde netwerkkonfigurasie inspekteer. 'n Benoemde brugnetwerk is nie outomaties 'n pasta-naamruimte net omdat 'n onafhanklike podman run-opdrag pasta suksesvol gebruik het nie. 'n Afgeleë Podman-enjin plaas ook “gasheer” op die plek van die enjin.

Verwante artikels