Ansible SOCKS-proxy: melyik gép birtokolja a localhostot?

Azonosítsa az Ansible API-kérést végző folyamatot, mielőtt egy loopbacken hallgató SSH SOCKS-figyelőre irányítaná.

A socks5h://127.0.0.1:65432-t használó feladatnak abban a hálózati környezetben kell futnia, ahol ez a figyelő létezik. A vezérlőről működő alagút nem teszi elérhetővé egy felügyelt gazdagép loopback-címén — vagy egy végrehajtó konténeren belül.

A sikertelen feladatnál négy tényt kell tisztázni:

  1. A hálózati kérést végrehajtó gazdagép vagy konténer.
  2. Annak tényleges felhasználója és Python-értelmezője.
  3. A modul HTTP-könyvtára vagy SDK-ja.
  4. A cím, ahol ez a folyamat eléri a SOCKS-figyelőt.

A játék leltári célpontja önmagában nem válaszol az első kérdésre. A modulok a beállított kapcsolatukat használják, a delegálás áthelyezheti a végrehajtást, és egy helyi kapcsolat a vezérlőn tarthatja a munkát. A vezérlő oldali keresések teljesen a távoli modulon kívül történnek.

Egy OpenStack-lemezkép-feladatnál vizsgálja meg a telepített openstack.cloud gyűjtemény követelményeit és annak OpenStack SDK-környezetét. A curl máshol való sikere nem bizonyítja az adott SDK SOCKS-képességeit vagy függőségeit.

Ha az API-műveletet helyben kell futtatni, tegye egyértelművé ezt a végrehajtási választást, és ott adja meg a beállítást. Ha távolról fut, válasszon az adott környezetből elérhető proxyt. Az Ansible-feladat environment: beállítása a feladatfolyamatra hat; nem konfigurálja újra az összes keresést vagy bővítményt, és az SDK-nak továbbra is támogatnia kell a sémát abban a Python-környezetben.

Tartsa külön a két útvonalat: az SSH vagy a ProxyJump eljuttatja az Ansible-t egy gazdagéphez, míg a modul HTTP-kliense a végrehajtási környezetéből az API-hoz jut. Egy működő első útvonal nem konfigurálja a másodikat. A csak a vezérlőn létező figyelő elérhetőség miatti kitettsége azt is megváltoztatja, ki férhet hozzá, tehát ez telepítési döntés, nem címjavítás.

Kapcsolódó cikkek