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-მდე აღწევს. მომუშავე პირველი მარშრუტი მეორეს არ აკონფიგურირებს. მხოლოდ კონტროლერზე არსებული მსმენელის გამჟღავნება ხელმისაწვდომობის გადასაჭრელად ასევე ცვლის, ვის შეუძლია მასზე წვდომა, ამიტომ ეს განლაგების გადაწყვეტილებაა და არა მისამართის შესწორება.

დაკავშირებული სტატიები