Ansible-SOCKS-Proxy: Welche Maschine besitzt localhost?

Eine Aufgabe, die socks5h://127.0.0.1:65432 verwendet, muss in der Netzwerkumgebung laufen, in der dieser Listener existiert. Ein Tunnel, der vom Controller aus funktioniert, macht ihn nicht unter der Loopback-Adresse eines verwalteten Hosts — oder in einem Ausführungscontainer verfügbar.

Für die fehlschlagende Aufgabe sind vier Fakten zu klären:

1. Der Host oder Container, der die Netzwerkanfrage ausführt.
2. Sein effektiver Benutzer und Python-Interpreter.
3. Die HTTP-Bibliothek oder das SDK des Moduls.
4. Die Adresse, unter der dieser Prozess den SOCKS-Listener erreicht.

Das Inventarziel des Playbooks allein beantwortet die erste Frage nicht. Module verwenden ihre konfigurierte Verbindung, Delegation kann die Ausführung verschieben, und eine lokale Verbindung kann die Arbeit auf dem Controller belassen. Lookups auf der Controller-Seite finden völlig außerhalb des entfernten Moduls statt.

Prüfen Sie bei einer OpenStack-Image-Aufgabe die Anforderungen der installierten openstack.cloud-Collection und ihre OpenStack-SDK-Umgebung. Ein anderswo erfolgreiches curl belegt weder die SOCKS-Fähigkeiten noch die Abhängigkeiten dieses SDK.

Soll der API-Vorgang lokal laufen, machen Sie diese Ausführungswahl explizit und setzen Sie die Einstellung dort. Läuft er entfernt, wählen Sie einen Proxy, der aus diesem Kontext erreichbar ist. environment: der Ansible-Aufgabe wirkt auf den Aufgabenprozess; es konfiguriert nicht jeden Lookup oder jedes Plugin neu, und das SDK muss das Schema in dieser Python-Umgebung weiterhin unterstützen.

Halten Sie zwei Wege getrennt: SSH oder ProxyJump bringt Ansible zu einem Host, während der HTTP-Client des Moduls von seinem Ausführungskontext zur API gelangt. Ein funktionierender erster Weg konfiguriert den zweiten nicht. Einen nur auf dem Controller vorhandenen Listener freizugeben, um Erreichbarkeit zu lösen, ändert auch, wer darauf zugreifen kann; es ist daher eine Bereitstellungsentscheidung und keine Adresskorrektur.