Podman pasta: in host-loopbackproxy berikke fanút in rootless container

Brûk pasta syn TCP-oerdracht fan 'e namespace nei de host foar in besteande loopbackproxy, en hâld dy apart fan it publisearjen fan in containerpoarte.

De 127.0.0.1:8118 fan 'e host en de 127.0.0.1:8118 fan 'e container binne normaal aparte loopback-einpunten. It trochjaan fan in proxyfariabele oan in rootless container ferbynt dy loopback-ynterfaces net.

By in Podman-ynset dy't pasta brûkt, kin syn TCP-oerdracht fan 'e namespace nei de host de bedoelde hostpoarte binnen de namespace bleatstelle:

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

Brûk de besteande image en opdracht fan 'e applikaasje. It foarbyld giet út fan in wurkjende HTTP-proxy oan 'e hostkant op poarte 8118 en in Podman/pasta-ferzje dy't de toande oerdrachtopsje stipet.

De grutte -T fan pasta draacht oer fan 'e doelnnamespace nei de hostnamespace. De lytse -t en Podman syn --publish rjochtsje de tsjinoerstelde kant. It publisearjen fan containerpoarte 8118 makket dus net op himsels de proxy fan 'e host beskikber foar de container.

Podman skeakelet standert automatyske poartoerdracht fan 'e namespacenei de host út; de eksplisite poarte kiest de tsjinst dy't hjir nedich is. De aparte opsje pasta:--map-gw giet oer it berikken fan 'e host fia it gatewayadres, wat in oare regeling is.

Mei Compose moat jo de wirklike provider en de generearre netwurkkonfiguraasje besjen. In neamd bridge-netwurk is net automatysk in pasta-namespace, allinnich om't in selsstannige podman run-opdracht pasta suksesfol brûkt hat. In op ôfstân Podman-engine pleatst ek “host” op it plak fan 'e engine.

Relatearre artikelen