Värdens 127.0.0.1:8118 och containerns 127.0.0.1:8118 är vanligtvis åtskilda loopback-slutpunkter. Att skicka en proxyvariabel till en rootless container kopplar inte samman dessa loopback-gränssnitt.

I en Podman-distribution som använder pasta kan dess TCP-vidarebefordran från namespace till värden exponera den avsedda värdporten inuti namespacet:

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

Använd programmets befintliga image och kommando. Exemplet förutsätter en fungerande HTTP-proxy på värdsidan på port 8118 och en Podman/pasta-version som stöder vidarebefordringsvalet som visas.

Det stora -T i pasta vidarebefordrar från mål-namespacet mot värdens namespace. Det lilla -t och Podmans --publish riktar sig i motsatt riktning. Att publicera containerport 8118 gör därför inte i sig värdens proxy tillgänglig för containern.

Podman stänger av automatisk portvidarebefordran från namespace till värden som standard; den explicita porten väljer den tjänst som behövs här. Det separata alternativet pasta:--map-gw handlar om att nå värden via gateway-adressen, vilket är ett annat arrangemang.

Med Compose, granska den faktiska leverantören och den genererade nätverkskonfigurationen. Ett namngivet bridge-nätverk är inte automatiskt ett pasta-namespace bara för att ett oberoende podman run-kommando använde pasta framgångsrikt. En fjärrstyrd Podman-motor placerar också ”värden” på motorns plats.

Relaterade artiklar