Podman pasta: nå en verts-loopbackproxy fra en rootless container

Bruk pastas TCP-videresending fra namespace til vert for en eksisterende loopbackproxy, og hold den atskilt fra publisering av en containerport.

Vertens 127.0.0.1:8118 og containerens 127.0.0.1:8118 er vanligvis atskilte loopback-endepunkter. Å sende en proxyvariabel inn i en rootless container kobler ikke disse loopback-grensesnittene sammen.

I en Podman-utrulling som bruker pasta, kan TCP-videresendingen fra namespace til vert eksponere 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 applikasjonens eksisterende image og kommando. Eksempelet forutsetter en fungerende HTTP-proxy på vertssiden på port 8118 og en Podman/pasta-versjon som støtter videresendingsvalget som vises.

Den store -T i pasta videresender fra mål-namespacet mot vertens namespace. Den lille -t og Podmans --publish peker i motsatt retning. Å publisere containerport 8118 gjør derfor ikke i seg selv vertens proxy tilgjengelig for containeren.

Podman deaktiverer automatisk portvideresending fra namespace til vert som standard; den eksplisitte porten velger tjenesten som trengs her. Det separate alternativet pasta:--map-gw handler om å nå verten via gateway-adressen, som er en annen ordning.

Med Compose må du undersøke den faktiske leverandøren og den genererte nettverkskonfigurasjonen. Et navngitt bridge-nettverk er ikke automatisk et pasta-namespace bare fordi en uavhengig podman run-kommando brukte pasta vellykket. En ekstern Podman-motor plasserer også «vert» på motorens plassering.

Relaterte artikler