127.0.0.1:8118 របស់ម៉ាស៊ីន និង 127.0.0.1:8118 របស់ container ជាធម្មតាជា ចំណុចបញ្ចប់ loopback ដាច់ដោយឡែក។ ការបញ្ជូនអថេរ proxy ចូល container ដែលគ្មាន root មិនភ្ជាប់ចំណុចប្រទាក់ loopback ទាំងនោះទេ។

ក្នុងការដាក់ពង្រាយ Podman ដែលប្រើ pasta ការបញ្ជូន TCP ពី namespace ទៅម៉ាស៊ីនរបស់វាអាចបង្ហាញ port ម៉ាស៊ីនដែលចង់បាននៅក្នុង 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

ប្រើ image និងពាក្យបញ្ជាដែលមានស្រាប់របស់កម្មវិធី។ ឧទាហរណ៍សន្មតថាមាន HTTP proxy ដំណើរការនៅខាងម៉ាស៊ីនលើ port 8118 និងកំណែ Podman/pasta ដែលគាំទ្រជម្រើសបញ្ជូនដែលបានបង្ហាញ។

អក្សរ -T ធំរបស់ pasta បញ្ជូនពី namespace គោលដៅឆ្ពោះទៅ namespace របស់ម៉ាស៊ីន។ អក្សរ -t តូច និង --publish របស់ Podman ឆ្ពោះទៅទិសផ្ទុយ។ ដូច្នេះការផ្សព្វផ្សាយ port 8118 របស់ container មិនធ្វើឱ្យ proxy របស់ម៉ាស៊ីនអាចប្រើបានសម្រាប់ container ដោយខ្លួនឯងទេ។

Podman បិទការបញ្ជូន port ដោយស្វ័យប្រវត្តិពី namespace ទៅម៉ាស៊ីនតាមលំនាំដើម។ port ច្បាស់លាស់ជ្រើសសេវាដែលត្រូវការនៅទីនេះ។ ជម្រើស pasta:--map-gw ដាច់ដោយឡែកនិយាយអំពីការទៅដល់ម៉ាស៊ីនតាមរយៈអាសយដ្ឋាន gateway ដែលជាការរៀបចំផ្សេង។

ជាមួយ Compose សូមពិនិត្យអ្នកផ្តល់សេវាពិតប្រាកដ និងការកំណត់បណ្តាញដែលបានបង្កើត។ បណ្តាញ bridge ដែលមានឈ្មោះមិនក្លាយជា pasta namespace ដោយស្វ័យប្រវត្តិទេ គ្រាន់តែដោយសារពាក្យបញ្ជា podman run ឯករាជ្យបានប្រើ pasta ដោយជោគជ័យ។ ម៉ាស៊ីន Podman ពីចម្ងាយក៏ដាក់ «ម៉ាស៊ីន» នៅទីតាំងរបស់ម៉ាស៊ីនដែរ។

អត្ថបទពាក់ព័ន្ធ