Podman pasta: dostęp do proxy loopback hosta z kontenera bez roota

Użyj przekazywania TCP pasta z przestrzeni nazw do hosta dla istniejącego proxy loopback i odróżnij je od publikowania portu kontenera.

127.0.0.1:8118 hosta i 127.0.0.1:8118 kontenera to zwykle osobne punkty końcowe loopback. Przekazanie zmiennej proxy do kontenera bez roota nie łączy tych interfejsów loopback.

W przypadku wdrożenia Podmana korzystającego z pasta jego przekazywanie TCP z przestrzeni nazw do hosta może udostępnić zamierzony port hosta wewnątrz przestrzeni nazw:

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

Użyj istniejącego obrazu i polecenia aplikacji. Przykład zakłada działające proxy HTTP po stronie hosta na porcie 8118 oraz wersję Podmana/pasta obsługującą pokazaną opcję przekazywania.

Duże -T w pasta przekazuje z docelowej przestrzeni nazw w stronę przestrzeni nazw hosta. Małe -t i --publish Podmana dotyczą przeciwnego kierunku. Opublikowanie portu 8118 kontenera samo w sobie nie udostępnia więc proxy hosta kontenerowi.

Podman domyślnie wyłącza automatyczne przekazywanie portów z przestrzeni nazw do hosta; jawny port wybiera potrzebną tutaj usługę. Osobna opcja pasta:--map-gw dotyczy docierania do hosta przez adres bramy, co jest innym układem.

W Compose sprawdź rzeczywistego dostawcę i wygenerowaną konfigurację sieci. Nazwana sieć mostkowa nie staje się automatycznie przestrzenią nazw pasta tylko dlatego, że niezależne polecenie podman run z powodzeniem użyło pasta. Zdalny silnik Podmana również umieszcza „hosta” w miejscu silnika.

Powiązane artykuły