Proxy SOCKS Ansible : quelle machine possède localhost ?

Une tâche qui utilise socks5h://127.0.0.1:65432 doit s'exécuter dans l'environnement réseau où cet écouteur existe. Un tunnel fonctionnant depuis le contrôleur ne le rend pas disponible à l'adresse de boucle locale d'un hôte géré — ni à l'intérieur d'un conteneur d'exécution.

Pour la tâche en échec, établissez quatre faits :

1. L'hôte ou le conteneur qui exécute la requête réseau.
2. Son utilisateur effectif et son interpréteur Python.
3. La bibliothèque HTTP ou le SDK du module.
4. L'adresse à laquelle ce processus peut joindre l'écouteur SOCKS.

La cible d'inventaire de la pièce seule ne répond pas à la première question. Les modules utilisent leur connexion configurée, la délégation peut déplacer l'exécution et une connexion locale peut garder le travail sur le contrôleur. Les recherches côté contrôleur se produisent entièrement hors du module distant.

Pour une tâche d'image OpenStack, examinez les exigences de la collection openstack.cloud installée et son environnement SDK OpenStack. Le succès de curl ailleurs ne prouve ni les capacités SOCKS ni les dépendances de ce SDK.

Si l'opération API doit s'exécuter localement, rendez ce choix d'exécution explicite et fournissez-y le réglage. Si elle s'exécute à distance, choisissez un proxy accessible depuis ce contexte. Le environment: de la tâche Ansible agit sur le processus de la tâche ; il ne reconfigure pas chaque recherche ni chaque greffon, et le SDK doit toujours prendre en charge le schéma dans cet environnement Python.

Gardez deux routes distinctes : SSH ou ProxyJump amène Ansible jusqu'à un hôte, tandis que le client HTTP du module va de son contexte d'exécution jusqu'à l'API. Une première route fonctionnelle ne configure pas la seconde. Exposer un écouteur présent uniquement sur le contrôleur pour résoudre l'accessibilité change aussi qui peut y accéder : c'est donc un choix de déploiement, non une correction d'adresse.