Ansible-ի SOCKS վստահված անցք: ո՞ր մեքենան է տիրապետում localhost-ին:

Գտեք այն գործընթացը, որը կատարում է Ansible API հարցում, նախքան այն ուղղելը loopback-ի վրա գտնվող SSH SOCKS լսողին:

socks5h://127.0.0.1:65432 օգտագործող առաջադրանքը պետք է աշխատի այն ցանցային միջավայրում, որտեղ գոյություն ունի այդ լսողը: Կառավարչից աշխատող թունելը այն հասանելի չի դարձնում կառավարվող հոսթի loopback հասցեում — կամ կատարման կոնտեյների ներսում:

Ձախողվող առաջադրանքի համար պարզեք չորս փաստ:

  1. Ցանցային հարցումը կատարող հոսթը կամ կոնտեյները:
  2. Նրա արդյունավետ օգտատերը և Python ինտերպրետատորը:
  3. Մոդուլի HTTP գրադարանը կամ SDK-ն:
  4. Այն հասցեն, որտեղից այդ գործընթացը կարող է հասնել SOCKS լսողին:

Միայն փիեսի գույքագրման թիրախը չի պատասխանում առաջին հարցին: Մոդուլները օգտագործում են իրենց կարգավորված կապը, պատվիրակումը կարող է տեղափոխել կատարումը, և տեղական կապը կարող է աշխատանքը թողնել կառավարչի վրա: Կառավարչի կողմի որոնումները տեղի են ունենում հեռավոր մոդուլից լիովին դուրս:

OpenStack պատկերի առաջադրանքի համար ստուգեք տեղադրված openstack.cloud հավաքածուի պահանջները և դրա OpenStack SDK միջավայրը: curl-ի հաջողությունը այլ տեղ չի ապացուցում այդ SDK-ի SOCKS հնարավորությունները կամ կախվածությունները:

Եթե API գործողությունը նախատեսված է տեղում աշխատելու, արեք այդ կատարման ընտրությունը բացահայտ և տվեք կարգավորումը այնտեղ: Եթե այն աշխատում է հեռվից, ընտրեք վստահված անցք, որը հասանելի է այդ համատեքստից: Ansible-ի առաջադրանքի environment: ազդում է առաջադրանքի գործընթացի վրա. այն չի վերակարգավորում յուրաքանչյուր որոնում կամ փլագին, և SDK-ն դեռ պետք է աջակցի սխեմային այդ Python միջավայրում:

Առանձնացրեք երկու ուղիներ. SSH-ը կամ ProxyJump-ը Ansible-ը հասցնում է հոսթ, իսկ մոդուլի HTTP հաճախորդը իր կատարման համատեքստից հասնում է API-ին: Աշխատող առաջին ուղին չի կարգավորում երկրորդը: Միայն կառավարչի վրա գտնվող լսողի բացումը հասանելիությունը լուծելու համար նաև փոխում է, թե ով կարող է մուտք գործել դրան, ուստի սա տեղակայման որոշում է, ոչ թե հասցեի ուղղում:

Առնչվող հոդվածներ