Podman pasta: دسترسی به پروکسی loopback میزبان از یک کانتینر بدون root

از ارسال TCP pasta از فضای نام به میزبان برای پروکسی loopback موجود استفاده کنید و آن را از انتشار پورت کانتینر جدا نگه دارید.

127.0.0.1:8118 میزبان و 127.0.0.1:8118 کانتینر معمولاً نقاط پایانی loopback جداگانه هستند. فرستادن متغیر پروکسی به کانتینر بدون root این رابط‌های 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 و گزینه --publish در Podman جهت مخالف را هدف می‌گیرند. بنابراین انتشار پورت 8118 کانتینر به‌خودی‌خود پروکسی میزبان را برای کانتینر در دسترس نمی‌کند.

Podman به‌طور پیش‌فرض ارسال خودکار پورت از فضای نام به میزبان را غیرفعال می‌کند؛ پورت صریح سرویس لازم در اینجا را انتخاب می‌کند. گزینه جداگانه pasta:--map-gw به دسترسی به میزبان از طریق نشانی دروازه مربوط است که ترتیب دیگری است.

با Compose، ارائه‌دهنده واقعی و پیکربندی شبکه تولیدشده را بررسی کنید. یک شبکه پل نام‌دار به‌طور خودکار فضای نام pasta نیست، فقط به این دلیل که یک فرمان مستقل podman run با موفقیت از pasta استفاده کرده است. موتور Podman راه‌دور نیز «میزبان» را در مکان موتور قرار می‌دهد.

مقالات مرتبط