Ansible SOCKS پراکسی: localhost کس مشین کا ہے؟
Ansible API درخواست کرنے والا عمل شناخت کریں، پھر اسے loopback پر SSH SOCKS سننے والے کی طرف موڑیں۔
socks5h://127.0.0.1:65432 استعمال کرنے والا کام اسی نیٹ ورک ماحول میں چلنا چاہیے جہاں وہ سننے والا موجود ہو۔ کنٹرولر سے چلنے والی سرنگ اسے زیرِ انتظام میزبان کے loopback پتے پر — یا کسی ایگزیکیوشن کنٹینر کے اندر دستیاب نہیں کرتی۔
ناکام ہونے والے کام کے لیے چار حقائق قائم کریں:
- نیٹ ورک درخواست چلانے والا میزبان یا کنٹینر۔
- اس کا مؤثر صارف اور Python انٹرپریٹر۔
- ماڈیول کی HTTP لائبریری یا SDK۔
- وہ پتہ جہاں سے وہ عمل SOCKS سننے والے تک پہنچ سکتا ہے۔
صرف ڈرامے کا انوینٹری ہدف پہلے سوال کا جواب نہیں دیتا۔ ماڈیول اپنا تشکیل شدہ کنکشن استعمال کرتے ہیں، تفویض عمل کو منتقل کر سکتی ہے، اور مقامی کنکشن کام کو کنٹرولر پر رکھ سکتا ہے۔ کنٹرولر کی طرف کی تلاشیں ریموٹ ماڈیول سے مکمل طور پر باہر ہوتی ہیں۔
OpenStack امیج کے کام کے لیے، نصب شدہ openstack.cloud مجموعے کی ضروریات اور اس کے OpenStack SDK ماحول کا جائزہ لیں۔ کہیں اور curl کی کامیابی اس SDK کی SOCKS صلاحیتوں یا انحصار کو ثابت نہیں کرتی۔
اگر API کارروائی مقامی طور پر چلانے کے لیے ہے تو اس ایگزیکیوشن انتخاب کو واضح کریں اور ترتیب وہیں دیں۔ اگر یہ دور سے چلتی ہے تو اس سیاق سے قابلِ رسائی پراکسی منتخب کریں۔ Ansible کام کا environment: کام کے عمل پر اثر ڈالتا ہے؛ یہ ہر تلاش یا پلگ اِن کو دوبارہ ترتیب نہیں دیتا، اور SDK کو اب بھی اس Python ماحول میں اسکیم کی معاونت کرنی ہوگی۔
دو راستے الگ رکھیں: SSH یا ProxyJump Ansible کو میزبان تک پہنچاتا ہے، جبکہ ماڈیول کا HTTP کلائنٹ اپنے ایگزیکیوشن سیاق سے API تک جاتا ہے۔ کام کرنے والا پہلا راستہ دوسرے کو ترتیب نہیں دیتا۔ صرف کنٹرولر پر موجود سننے والے کو رسائی کے لیے کھولنا یہ بھی بدلتا ہے کہ اس تک کون رسائی رکھتا ہے، لہٰذا یہ پتے کی اصلاح نہیں بلکہ تعیناتی کا فیصلہ ہے۔