Podman pasta: nå en værts-loopbackproxy fra en rootless container

Brug pasta-videresendelse af TCP fra namespace til vært for en eksisterende loopbackproxy, og hold den adskilt fra publicering af en containerport.

Værtens 127.0.0.1:8118 og containerens 127.0.0.1:8118 er normalt adskilte loopback-endepunkter. At sende en proxyvariabel ind i en rootless container forbinder ikke disse loopback-grænseflader.

I en Podman-udrulning, der bruger pasta, kan dens TCP-videresendelse fra namespace til vært eksponere den tilsigtede værtsport inde i namespaceet:

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

Brug applikationens eksisterende image og kommando. Eksemplet forudsætter en fungerende HTTP-proxy på værtsiden på port 8118 og en Podman/pasta-version, der understøtter den viste videresendelsesindstilling.

pastaens store -T videresender fra mål-namespaceet mod værtens namespace. Det lille -t og Podmans --publish peger i den modsatte retning. At publicere containerport 8118 gør derfor ikke i sig selv værtens proxy tilgængelig for containeren.

Podman deaktiverer som standard automatisk portvideresendelse fra namespace til vært; den eksplicitte port vælger den tjeneste, der er nødvendig her. Den separate indstilling pasta:--map-gw handler om at nå værten via gatewayadressen, hvilket er en anden ordning.

Med Compose skal du undersøge den faktiske udbyder og den genererede netværkskonfiguration. Et navngivet bridge-netværk er ikke automatisk et pasta-namespace, bare fordi en uafhængig podman run-kommando brugte pasta med succes. En fjern Podman-motor placerer også “vært” på motorens placering.

Relaterede artikler