Podman pasta: доступ да loopback-проксі хаста з бескаранёвага кантэйнера

Выкарыстоўвайце TCP-перасылку pasta з прасторы імёнаў на хаст для існуючага loopback-проксі і адрознівайце яе ад публікацыі порта кантэйнера.

127.0.0.1:8118 хаста і 127.0.0.1:8118 кантэйнера звычайна ёсць асобнымі канчатковымі пунктамі loopback. Перадача зменнай проксі ў бескаранёвы кантэйнер не аб’ядноўвае гэтыя інтэрфейсы 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 і опцыя Podman --publish працуюць у адваротным кірунку. Таму публікацыя порта кантэйнера 8118 сама па сабе не робіць проксі хаста даступным кантэйнеру.

Podman па змаўчанні адключае аўтаматычную перасылку портаў з прасторы імёнаў на хаст; згаданы порт выбірае патрэбную тут службу. Асобная опцыя pasta:--map-gw датычыцца доступу да хаста праз адрас шлюза, што ёсць іншай схемай.

З Compose праверце фактычнага правайдера і створаную канфігурацыю сеткі. Імянная мастовая сетка не становіцца прасторай імёнаў pasta аўтаматычна толькі таму, што асобная каманда podman run паспяхова выкарыстала pasta. Аддалены рухавік Podman таксама размяшчае «хаст» па месцы рухавіка.

Падобныя артыкулы