Podman pasta: accesarea unui proxy loopback al gazdei dintr-un container fără root

Folosiți redirecționarea TCP pasta din namespace către gazdă pentru un proxy loopback existent și păstrați-o distinctă de publicarea unui port de container.

127.0.0.1:8118 al gazdei și 127.0.0.1:8118 al containerului sunt de obicei puncte finale loopback separate. Transmiterea unei variabile proxy într-un container fără root nu unește aceste interfețe loopback.

Într-o implementare Podman care folosește pasta, redirecționarea TCP din namespace către gazdă poate expune portul de gazdă dorit în interiorul namespace-ului:

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

Folosiți imaginea și comanda existente ale aplicației. Exemplul presupune un proxy HTTP funcțional pe partea gazdei la portul 8118 și o versiune Podman/pasta care acceptă opțiunea de redirecționare prezentată.

Litera mare -T din pasta redirecționează din namespace-ul țintă spre namespace-ul gazdei. Litera mică -t și --publish din Podman vizează direcția opusă. Publicarea portului 8118 al containerului nu face, prin ea însăși, proxy-ul gazdei disponibil containerului.

Podman dezactivează implicit redirecționarea automată a porturilor din namespace către gazdă; portul explicit alege serviciul necesar aici. Opțiunea separată pasta:--map-gw privește atingerea gazdei prin adresa gateway-ului, ceea ce este o altă configurare.

Cu Compose, inspectați furnizorul real și configurația de rețea generată. O rețea bridge cu nume nu devine automat un namespace pasta doar pentru că o comandă podman run independentă a folosit pasta cu succes. Un motor Podman la distanță plasează și „gazda” la locația motorului.

Articole similare