Podman pasta: достъп до loopback прокси на хоста от контейнер без root

Използвайте TCP препращането на pasta от пространството от имена към хоста за съществуващ loopback прокси и го разграничавайте от публикуването на порт на контейнер.

127.0.0.1:8118 на хоста и 127.0.0.1:8118 на контейнера обикновено са отделни loopback крайни точки. Предаването на прокси променлива в контейнер без root не обединява тези loopback интерфейси.

При внедряване на Podman с pasta неговото TCP препращане от пространството от имена към хоста може да изложи желания порт на хоста вътре в пространството от имена:

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

Използвайте съществуващия образ и команда на приложението. Примерът предполага работещ HTTP прокси от страна на хоста на порт 8118 и версия на Podman/pasta, която поддържа показаната опция за препращане.

Голямата буква -T на pasta препраща от целевото пространство от имена към пространството от имена на хоста. Малката буква -t и --publish на Podman адресират обратната посока. Затова публикуването на порт 8118 на контейнера самó по себе си не прави проксито на хоста достъпно за контейнера.

Podman по подразбиране изключва автоматичното препращане на портове от пространството от имена към хоста; явният порт избира услугата, нужна тук. Отделната опция pasta:--map-gw се отнася до достигане на хоста през адреса на шлюза, което е друга подредба.

С Compose проверявайте действителния доставчик и генерираната мрежова конфигурация. Именувана bridge мрежа не е автоматично pasta пространство от имена само защото независима команда podman run е използвала pasta успешно. Отдалечен Podman двигател също поставя „хоста“ на мястото на двигателя.

Подобни статии