Podman pasta: een loopbackproxy op de host bereiken vanuit een rootless container

Gebruik pasta's TCP-doorsturing van namespace naar host voor een bestaande loopbackproxy en houd die gescheiden van het publiceren van een containerpoort.

De 127.0.0.1:8118 van de host en de 127.0.0.1:8118 van de container zijn normaal gesproken afzonderlijke loopback-eindpunten. Een proxyvariabele in een rootless container doorgeven, verbindt die loopbackinterfaces niet.

Bij een Podman-implementatie met pasta kan de TCP-doorsturing van namespace naar host de bedoelde hostpoort binnen de namespace beschikbaar maken:

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 de bestaande image en opdracht van de toepassing. Het voorbeeld gaat uit van een werkende HTTP-proxy aan de hostzijde op poort 8118 en een Podman/pasta-versie die de getoonde doorstuuroptie ondersteunt.

De hoofdletter -T van pasta stuurt door van de doelnnamespace naar de hostnamespace. De kleine -t en Podmans --publish richten zich op de tegenovergestelde richting. Het publiceren van containerpoort 8118 maakt de proxy van de host dus niet vanzelf beschikbaar voor de container.

Podman schakelt standaard automatische poortdoorsturing van namespace naar host uit; de expliciete poort kiest de hier benodigde dienst. De aparte optie pasta:--map-gw gaat over het bereiken van de host via het gatewayadres, wat een andere opstelling is.

Controleer bij Compose de werkelijke provider en de gegenereerde netwerkconfiguratie. Een genoemd bridgenetwerk is niet automatisch een pasta-namespace, alleen omdat een onafhankelijke podman run-opdracht pasta met succes gebruikte. Een externe Podman-engine plaatst ‘host’ ook op de locatie van de engine.

Gerelateerde artikelen