پروکسی SOCKS در Ansible: کدام ماشین مالک localhost است؟
فرآیندی را که درخواست API آنسیبل را انجام می‌دهد مشخص کنید، پیش از آنکه آن را به شنونده SSH SOCKS روی loopback اشاره دهید.
وظیفه‌ای که از socks5h://127.0.0.1:65432 استفاده می‌کند باید در محیط شبکه‌ای اجرا شود که آن شنونده در آن وجود دارد. تونلی که از کنترلر کار می‌کند آن را در نشانی loopback یک میزبان مدیریت‌شده — یا درون یک کانتینر اجرا در دسترس قرار نمی‌دهد.
برای وظیفه‌ای که شکست می‌خورد، چهار واقعیت را مشخص کنید:
- میزبان یا کانتینری که درخواست شبکه را اجرا می‌کند.
- کاربر مؤثر و مفسر Python آن.
- کتابخانه HTTP یا SDK ماژول.
- نشانی‌ای که آن فرآیند می‌تواند از آن به شنونده SOCKS برسد.
هدف فهرست موجودی نمایش به‌تنهایی به پرسش اول پاسخ نمی‌دهد. ماژول‌ها از اتصال پیکربندی‌شدهٔ خود استفاده می‌کنند، واگذاری می‌تواند اجرا را جابه‌جا کند و اتصال محلی می‌تواند کار را روی کنترلر نگه دارد. جست‌وجوهای سمت کنترلر کاملاً خارج از ماژول راه‌دور انجام می‌شوند.
برای وظیفهٔ تصویر OpenStack، الزامات مجموعهٔ نصب‌شدهٔ openstack.cloud و محیط SDK آن را بررسی کنید. موفقیت curl در جای دیگر توانایی‌های SOCKS یا وابستگی‌های آن SDK را اثبات نمی‌کند.
اگر عملیات API قرار است محلی اجرا شود، این انتخاب اجرا را صریح کنید و تنظیم را همان‌جا بدهید. اگر از راه دور اجرا می‌شود، پروکسی‌ای انتخاب کنید که از آن زمینه قابل دسترسی باشد. environment: وظیفهٔ Ansible بر فرآیند وظیفه اثر می‌گذارد؛ هر جست‌وجو یا افزونه را پیکربندی مجدد نمی‌کند و SDK همچنان باید طرح را در آن محیط Python پشتیبانی کند.
دو مسیر را جدا نگه دارید: SSH یا ProxyJump آنسیبل را به میزبان می‌رساند، در حالی که کلاینت HTTP ماژول از زمینهٔ اجرای خود به API می‌رسد. مسیر اولِ کارکننده مسیر دوم را پیکربندی نمی‌کند. افشای شنونده‌ای که فقط روی کنترلر است برای حل دسترسی، همچنین تغییر می‌دهد که چه کسی می‌تواند به آن دسترسی داشته باشد، پس این یک تصمیم استقرار است نه اصلاح نشانی.