SOCKS прокси во Ansible: кој компјутер го поседува localhost?
Лоцирајте го процесот што испраќа Ansible API барање пред да го насочите кон 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. Работниот прв правец не го конфигурира вториот. Изложувањето на слушател што постои само на контролорот за да се реши достапноста исто така менува кој може да му пристапи, така што тоа е одлука за распоредување, а не исправка на адреса.