Podman pasta: nå ein verts-loopbackproxy frå ein rootless container

Bruk pasta sin TCP-vidareføring frå namespace til vert for ein eksisterande loopbackproxy, og hald han skild frå publisering av ein containerport.

Verten sin 127.0.0.1:8118 og containeren sin 127.0.0.1:8118 er vanlegvis skilde loopback-endepunkt. Å senda ein proxyvariabel inn i ein rootless container koplar ikkje desse loopback-grensesnitta saman.

I ein Podman-utrulling som brukar pasta, kan TCP-vidareføringa frå namespace til vert eksponera den tiltenkte vertsporten inne i 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

Bruk den eksisterande imaga og kommandoen til applikasjonen. Eksempelet føreset ein fungerande HTTP-proxy på vertssida på port 8118 og ein Podman/pasta-versjon som støttar vidareføringsvalet som vert vist.

Den store -T i pasta vidarefører frå mål-namespacet mot verten sitt namespace. Den vesle -t og Podman sin --publish peikar i motsett retning. Å publisera containerport 8118 gjer derfor ikkje i seg sjølv proxyen til verten tilgjengeleg for containeren.

Podman slår av automatisk portvidareføring frå namespace til vert som standard; den eksplisitte porten vel tenesta som trengst her. Det separate valet pasta:--map-gw handlar om å nå verten via gateway-adressa, som er ei anna ordning.

Med Compose må du undersøkja den faktiske leverandøren og den genererte nettverkskonfigurasjonen. Eit namngjeve bridge-nettverk er ikkje automatisk eit pasta-namespace berre fordi ein uavhengig podman run-kommando brukte pasta med suksess. Ein ekstern Podman-motor plasserer òg «vert» på plasseringa til motoren.

Relaterte artiklar