Podman pasta: raggiungere un proxy loopback dell'host da un container senza root

Usate l'inoltro TCP di pasta dallo namespace all'host per un proxy loopback esistente e tenetelo distinto dalla pubblicazione di una porta del container.

Il 127.0.0.1:8118 dell'host e il 127.0.0.1:8118 del container sono normalmente endpoint loopback separati. Passare una variabile proxy in un container senza root non unisce queste interfacce loopback.

In un deployment Podman che usa pasta, il suo inoltro TCP dallo namespace all'host può esporre la porta host prevista all'interno dello namespace:

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

Usate l'immagine e il comando esistenti dell'applicazione. L'esempio presuppone un proxy HTTP funzionante sul lato host sulla porta 8118 e una versione di Podman/pasta che supporta l'opzione di inoltro mostrata.

La -T maiuscola di pasta inoltra dallo namespace di destinazione verso lo namespace dell'host. La -t minuscola e --publish di Podman riguardano la direzione opposta. Pubblicare la porta 8118 del container non rende quindi, da solo, il proxy dell'host disponibile al container.

Podman disattiva per impostazione predefinita l'inoltro automatico delle porte dallo namespace all'host; la porta esplicita sceglie il servizio necessario qui. L'opzione separata pasta:--map-gw riguarda il raggiungimento dell'host tramite l'indirizzo del gateway, che è un'altra disposizione.

Con Compose, ispezionate il provider effettivo e la configurazione di rete generata. Una rete bridge con nome non è automaticamente uno namespace pasta solo perché un comando podman run indipendente ha usato pasta con successo. Un motore Podman remoto colloca inoltre l'«host» nella posizione del motore.

Articoli correlati