พร็อกซี SOCKS ของ Ansible: localhost เป็นของเครื่องใด

ระบุโปรเซสที่ส่งคำขอ Ansible API ก่อนชี้นำไปยังตัวรับฟัง SSH SOCKS บน loopback

งานที่ใช้ socks5h://127.0.0.1:65432 ต้องทำงานในสภาพแวดล้อมเครือข่ายที่มีตัวรับฟังนั้นอยู่ อุโมงค์ที่ทำงานจากคอนโทรลเลอร์ไม่ได้ทำให้มันเข้าถึงได้ที่ ที่อยู่ loopback ของโฮสต์ที่จัดการ — หรือภายในคอนเทนเนอร์ที่ใช้เรียกใช้

สำหรับงานที่ล้มเหลว ให้กำหนดข้อเท็จจริงสี่ประการ:

  1. โฮสต์หรือคอนเทนเนอร์ที่ดำเนินการคำขอเครือข่าย
  2. ผู้ใช้ที่มีผลจริงและตัวแปลภาษา Python ของมัน
  3. ไลบรารี HTTP หรือ SDK ของโมดูล
  4. ที่อยู่ที่โปรเซสนั้นเข้าถึงตัวรับฟัง SOCKS ได้

เป้าหมายในคลังของเพลย์เพียงอย่างเดียวไม่ตอบคำถามแรก โมดูลใช้การเชื่อมต่อที่กำหนดไว้ การมอบหมายสามารถย้ายการทำงาน และการเชื่อมต่อภายในเครื่องสามารถเก็บงานไว้ที่คอนโทรลเลอร์ การค้นหาฝั่งคอนโทรลเลอร์เกิดขึ้นภายนอกโมดูลระยะไกลทั้งหมด

สำหรับงานอิมเมจ OpenStack ให้ตรวจสอบข้อกำหนดของคอลเลกชัน openstack.cloud ที่ติดตั้งและสภาพแวดล้อม OpenStack SDK ของมัน การที่ curl สำเร็จที่อื่นไม่ได้พิสูจน์ความสามารถ SOCKS หรือการพึ่งพาของ SDK นั้น

หากการดำเนินการ API ตั้งใจให้ทำงานภายในเครื่อง ให้ระบุการเลือกใช้การทำงานนั้นอย่างชัดเจนและกำหนดค่าที่นั่น หากทำงานจากระยะไกล ให้เลือกพร็อกซีที่เข้าถึงได้จากบริบทนั้น environment: ของงาน Ansible ส่งผลต่อโปรเซสของงาน มันไม่ได้กำหนดค่าใหม่ให้ทุกการค้นหาหรือปลั๊กอิน และ SDK ยังต้องรองรับสคีมาในสภาพแวดล้อม Python นั้น

แยกสองเส้นทางออกจากกัน: SSH หรือ ProxyJump พา Ansible ไปยังโฮสต์ ขณะที่ไคลเอนต์ HTTP ของโมดูลไปจากบริบทการทำงานของมันไปยัง API เส้นทางแรกที่ใช้งานได้ไม่ได้กำหนดค่าเส้นทางที่สอง การเปิดเผยตัวรับฟังที่มีอยู่เฉพาะบนคอนโทรลเลอร์เพื่อแก้ปัญหาการเข้าถึงยังเปลี่ยนว่าใครเข้าถึงได้ ดังนั้นจึงเป็นการตัดสินใจด้านการติดตั้งใช้งาน ไม่ใช่การแก้ไขที่อยู่

บทความที่เกี่ยวข้อง