Podman pasta: রুটলেস কন্টেইনার থেকে হোস্ট লুপব্যাক প্রক্সিতে পৌঁছানো

হোস্টের 127.0.0.1:8118 এবং কন্টেইনারের 127.0.0.1:8118 সাধারণত আলাদা লুপব্যাক এন্ডপয়েন্ট। রুটলেস কন্টেইনারে প্রক্সি ভেরিয়েবল পাঠালে সেই লুপব্যাক ইন্টারফেসগুলো একত্র হয় না।

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-to-host পোর্ট ফরওয়ার্ডিং বন্ধ রাখে; স্পষ্ট পোর্ট এখানে প্রয়োজনীয় সার্ভিস বেছে নেয়। আলাদা pasta:--map-gw অপশনটি গেটওয়ে ঠিকানার মাধ্যমে হোস্টে পৌঁছানোর বিষয়, যা অন্য একটি ব্যবস্থা।

Compose-এর সঙ্গে প্রকৃত প্রোভাইডার ও উৎপন্ন নেটওয়ার্ক কনফিগারেশন পরীক্ষা করুন। একটি নামযুক্ত ব্রিজ নেটওয়ার্ক স্বয়ংক্রিয়ভাবে pasta namespace নয়, কেবল একটি স্বতন্ত্র podman run কমান্ড pasta সফলভাবে ব্যবহার করেছে বলেই। দূরবর্তী Podman ইঞ্জিনও “হোস্ট”-কে ইঞ্জিনের অবস্থানে রাখে।