Ansible SOCKS प्रॉक्सी: localhost किस मशीन का है?

Ansible API अनुरोध करने वाली प्रक्रिया का पता लगाएँ, फिर उसे loopback पर SSH SOCKS श्रोता की ओर इंगित करें।

socks5h://127.0.0.1:65432 का उपयोग करने वाला कार्य उस नेटवर्क परिवेश में चलना चाहिए जहाँ वह श्रोता मौजूद है। नियंत्रक से काम करने वाली सुरंग उसे किसी प्रबंधित होस्ट के loopback पते पर — या किसी निष्पादन कंटेनर के भीतर उपलब्ध नहीं कराती।

विफल हो रहे कार्य के लिए चार तथ्य स्थापित करें:

  1. नेटवर्क अनुरोध निष्पादित करने वाला होस्ट या कंटेनर।
  2. उसका प्रभावी उपयोगकर्ता और Python इंटरप्रेटर।
  3. मॉड्यूल की HTTP लाइब्रेरी या SDK।
  4. वह पता जहाँ से वह प्रक्रिया SOCKS श्रोता तक पहुँच सकती है।

केवल प्ले का इन्वेंटरी लक्ष्य पहले प्रश्न का उत्तर नहीं देता। मॉड्यूल अपने कॉन्फ़िगर किए गए कनेक्शन का उपयोग करते हैं, प्रत्यायोजन निष्पादन को स्थानांतरित कर सकता है, और स्थानीय कनेक्शन काम को नियंत्रक पर रख सकता है। नियंत्रक-पक्ष की लुकअप रिमोट मॉड्यूल के पूरी तरह बाहर होती हैं।

OpenStack इमेज कार्य के लिए, स्थापित openstack.cloud संग्रह की आवश्यकताएँ और उसका OpenStack SDK परिवेश जाँचें। कहीं और curl का सफल होना उस SDK की SOCKS क्षमताओं या निर्भरताओं को सिद्ध नहीं करता।

यदि API संक्रिया स्थानीय रूप से चलानी है, तो उस निष्पादन विकल्प को स्पष्ट करें और वहीं सेटिंग दें। यदि यह दूर से चलती है, तो उस संदर्भ से पहुँचने योग्य प्रॉक्सी चुनें। Ansible कार्य का environment: कार्य प्रक्रिया को प्रभावित करता है; यह हर लुकअप या प्लगइन को पुनः कॉन्फ़िगर नहीं करता, और SDK को अभी भी उस Python परिवेश में योजना का समर्थन करना होगा।

दो मार्ग अलग रखें: SSH या ProxyJump, Ansible को होस्ट तक पहुँचाता है, जबकि मॉड्यूल का HTTP क्लाइंट अपने निष्पादन संदर्भ से API तक पहुँचता है। काम करने वाला पहला मार्ग दूसरे को कॉन्फ़िगर नहीं करता। केवल नियंत्रक पर मौजूद श्रोता को पहुँच के लिए खोलने से यह भी बदलता है कि उस तक कौन पहुँच सकता है, इसलिए यह पता सुधार नहीं, परिनियोजन का निर्णय है।

संबंधित लेख