Podman pasta: rootless კონტეინერიდან ჰოსტის loopback პროქსიზე წვდომა

გამოიყენეთ pasta-ს namespace-to-host TCP გადაცემა არსებული loopback პროქსისთვის და გამოყავით იგი კონტეინერის პორტის გამოქვეყნებისგან.

ჰოსტის 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

გამოიყენეთ აპლიკაციის არსებული იმიჯი და ბრძანება. მაგალითი ვარაუდობს, რომ ჰოსტის მხარეს 8118 პორტზე მუშაობს HTTP პროქსი და არსებობს Podman/pasta-ს ვერსია, რომელიც მხარს უჭერს ნაჩვენებ გადაცემის პარამეტრს.

pasta-ს დიდი -T გადასცემს სამიზნე namespace-იდან ჰოსტის namespace-ისკენ. პატარა -t და Podman-ის --publish საპირისპირო მიმართულებას ეხება. ამიტომ 8118 კონტეინერის პორტის გამოქვეყნება თავისთავად ჰოსტის პროქსის კონტეინერისთვის ხელმისაწვდომს არ ხდის.

Podman ნაგულისხმევად გამორთავს namespace-იდან ჰოსტზე პორტების ავტომატურ გადაცემას; ცხადი პორტი ირჩევს აქ საჭირო სერვისს. ცალკე pasta:--map-gw პარამეტრი ეხება ჰოსტზე გეითვეის მისამართით მიღწევას, რაც სხვა განლაგებაა.

Compose-თან შეამოწმეთ რეალური პროვაიდერი და გენერირებული ქსელის კონფიგურაცია. დასახელებული bridge ქსელი ავტომატურად pasta namespace არ არის მხოლოდ იმიტომ, რომ დამოუკიდებელმა podman run ბრძანებამ pasta წარმატებით გამოიყენა. დისტანციური Podman ძრავი ასევე „ჰოსტს“ ძრავის ადგილას ათავსებს.

დაკავშირებული სტატიები