Հոսթի 127.0.0.1:8118-ը և կոնտեյների 127.0.0.1:8118-ը սովորաբար առանձին loopback ծայրակետեր են։ Պրոքսի փոփոխականը rootless կոնտեյներ փոխանցելը չի միավորում այդ loopback ինտերֆեյսները։

pasta օգտագործող Podman տեղադրման դեպքում նրա namespace-to-host TCP փոխանցումը կարող է ցանկալի հոսթի պորտը բացել 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

Օգտագործեք հավելվածի գոյություն ունեցող պատկերն ու հրամանը։ Օրինակը ենթադրում է աշխատող HTTP պրոքսի հոսթի կողմում 8118 պորտում և Podman/pasta տարբերակ, որն աջակցում է ցուցադրված փոխանցման տարբերակին։

pasta-ի մեծ -T-ն փոխանցում է թիրախ namespace-ից դեպի հոսթի namespace։ Փոքր -t-ն և Podman-ի --publish-ը ուղղված են հակառակ ուղղությամբ։ Այսպիսով, 8118 կոնտեյների պորտի հրապարակումն ինքնին հոսթի պրոքսին հասանելի չի դարձնում կոնտեյների համար։

Podman-ը լռելյայն անջատում է namespace-ից հոսթ պորտերի ավտոմատ փոխանցումը. բացահայտ պորտը ընտրում է այստեղ անհրաժեշտ ծառայությունը։ Առանձին pasta:--map-gw տարբերակը վերաբերում է դարպասի հասցեով հոսթին հասնելուն, ինչը այլ դասավորություն է։

Compose-ի դեպքում ստուգեք իրական մատակարարին և գեներացված ցանցային կոնֆիգուրացիան։ Անվանված bridge ցանցը ինքնաբերաբար pasta namespace չէ միայն այն պատճառով, որ անկախ podman run հրամանը հաջողությամբ օգտագործել է pasta։ Հեռավոր Podman շարժիչը նույնպես «հոսթը» տեղադրում է շարժիչի տեղում։

Առնչվող հոդվածներ