Proxy SOCKS w Ansible: który komputer posiada localhost?
Zidentyfikuj proces wysyłający żądanie do API Ansible, zanim skierujesz je do nasłuchującego SSH SOCKS na loopbacku.
Zadanie używające socks5h://127.0.0.1:65432 musi działać w środowisku sieciowym, w którym istnieje ten nasłuch. Tunel działający z kontrolera nie czyni go dostępnym pod adresem loopback hosta zarządzanego — ani wewnątrz kontenera wykonawczego.
Dla nieudanego zadania ustal cztery fakty:
- Host lub kontener wykonujący żądanie sieciowe.
- Jego efektywny użytkownik i interpreter Pythona.
- Biblioteka HTTP lub SDK modułu.
- Adres, pod którym ten proces może dotrzeć do nasłuchu SOCKS.
Sam cel inwentarza sztuki nie odpowiada na pierwsze pytanie. Moduły korzystają z skonfigurowanego połączenia, delegowanie może przenieść wykonanie, a połączenie lokalne może pozostawić pracę na kontrolerze. Wyszukiwania po stronie kontrolera odbywają się całkowicie poza modułem zdalnym.
W zadaniu z obrazem OpenStack sprawdź wymagania zainstalowanej kolekcji openstack.cloud i jej środowisko OpenStack SDK. Sukces curl gdzie indziej nie dowodzi możliwości SOCKS ani zależności tego SDK.
Jeśli operacja API ma działać lokalnie, uczyń ten wybór wykonania jawnym i podaj ustawienie tam. Jeśli działa zdalnie, wybierz proxy osiągalne z tego kontekstu. environment: zadania Ansible wpływa na proces zadania; nie rekonfiguruje każdego wyszukiwania ani wtyczki, a SDK nadal musi obsługiwać schemat w tym środowisku Pythona.
Trzymaj dwie trasy osobno: SSH lub ProxyJump doprowadza Ansible do hosta, natomiast klient HTTP modułu przechodzi ze swojego kontekstu wykonania do API. Działająca pierwsza trasa nie konfiguruje drugiej. Wystawienie nasłuchu istniejącego tylko na kontrolerze, aby rozwiązać osiągalność, zmienia też to, kto może uzyskać do niego dostęp, więc jest to decyzja wdrożeniowa, a nie korekta adresu.