SOCKS proxy v Ansible: který stroj vlastní localhost?

Zjistěte, který proces odesílá požadavek na Ansible API, než jej nasměrujete na SSH SOCKS posluchač na loopbacku.

Úloha používající socks5h://127.0.0.1:65432 musí běžet v síťovém prostředí, kde tento posluchač existuje. Tunel fungující z řadiče jej nezpřístupní na loopback adrese spravovaného hostitele — ani uvnitř prováděcího kontejneru.

U selhávající úlohy zjistěte čtyři skutečnosti:

  1. Hostitel nebo kontejner, který provádí síťový požadavek.
  2. Jeho efektivní uživatel a interpret Pythonu.
  3. HTTP knihovna nebo SDK modulu.
  4. Adresa, na které tento proces dosáhne SOCKS posluchače.

Samotný cíl z inventáře hry na první otázku neodpovídá. Moduly používají své nakonfigurované připojení, delegování může přesunout provádění a lokální připojení může práci ponechat na řadiči. Vyhledávání na straně řadiče probíhají zcela mimo vzdálený modul.

U úlohy s image OpenStack zkontrolujte požadavky nainstalované kolekce openstack.cloud a její prostředí OpenStack SDK. Úspěšný curl jinde neprokazuje schopnosti SOCKS ani závislosti tohoto SDK.

Pokud má operace API běžet lokálně, udělejte tuto volbu provádění explicitní a nastavte příslušné nastavení tam. Pokud běží vzdáleně, zvolte proxy dostupnou z daného kontextu. environment: úlohy Ansible ovlivňuje proces úlohy; nepřekonfigurovává každé vyhledávání ani plugin a SDK stále musí dané schéma v tomto prostředí Pythonu podporovat.

Držte obě trasy oddělené: SSH nebo ProxyJump dostane Ansible na hostitele, zatímco HTTP klient modulu se dostane ze svého prováděcího kontextu k API. Fungující první trasa nenakonfiguruje druhou. Vystavení posluchače, který existuje jen na řadiči, kvůli řešení dostupnosti také mění, kdo k němu má přístup, takže jde o rozhodnutí o nasazení, ne o opravu adresy.

Související články