SOCKS-прокси в Ansible: какой машине принадлежит localhost?
Определите процесс, отправляющий запрос к API Ansible, прежде чем направлять его на SSH SOCKS-слушатель на loopback.
Задача, использующая socks5h://127.0.0.1:65432, должна выполняться в той сетевой среде, где существует этот слушатель. Туннель, работающий с контроллера, не делает его доступным по адресу loopback управляемого хоста — или внутри контейнера выполнения.
Для сбойной задачи установите четыре факта:
- Хост или контейнер, выполняющий сетевой запрос.
- Его действующий пользователь и интерпретатор Python.
- HTTP-библиотека или SDK модуля.
- Адрес, по которому этот процесс может достичь SOCKS-слушателя.
Только целевой хост из инвентаря пьесы не отвечает на первый вопрос. Модули используют настроенное подключение, делегирование может перенести выполнение, а локальное подключение может оставить работу на контроллере. Поиски на стороне контроллера происходят полностью вне удалённого модуля.
Для задачи с образом OpenStack проверьте требования установленной коллекции openstack.cloud и её окружение OpenStack SDK. Успешный curl в другом месте не доказывает поддержку SOCKS или зависимости этого SDK.
Если операция API должна выполняться локально, сделайте этот выбор выполнения явным и задайте настройку там. Если она выполняется удалённо, выберите прокси, доступный из этого контекста. environment: задачи Ansible влияет на процесс задачи; он не перенастраивает каждый поиск или плагин, и SDK по-прежнему должен поддерживать схему в этой среде Python.
Держите два маршрута раздельно: SSH или ProxyJump доставляет Ansible на хост, а HTTP-клиент модуля идёт из своего контекста выполнения к API. Работающий первый маршрут не настраивает второй. Открытие слушателя, существующего только на контроллере, ради доступности также меняет, кто может к нему подключиться, поэтому это решение о развёртывании, а не исправление адреса.