פרוקסי SOCKS של Ansible: איזה מחשב מחזיק ב-localhost?

אתרו את התהליך ששולח בקשת API של Ansible לפני שתפנו אותו למאזין SSH SOCKS ב-loopback.

משימה שמשתמשת ב-socks5h://127.0.0.1:65432 חייבת לרוץ בסביבת הרשת שבה קיים המאזין הזה. מנהרה שעובדת מהבקר אינה הופכת אותו לזמין בכתובת ה-loopback של מארח מנוהל — או בתוך מכולת הרצה.

עבור המשימה שנכשלת, קבעו ארבעה עובדות:

  1. המארח או המכולה שמבצעים את בקשת הרשת.
  2. המשתמש האפקטיבי ומפרש ה-Python שלהם.
  3. ספריית ה-HTTP או ה-SDK של המודול.
  4. הכתובת שבה אותו תהליך יכול להגיע למאזין ה-SOCKS.

יעד המלאי של המחזה לבדו אינו עונה על השאלה הראשונה. מודולים משתמשים בחיבור המוגדר שלהם, האצלה יכולה להעביר את ההרצה, וחיבור מקומי יכול להשאיר את העבודה בבקר. חיפושים בצד הבקר מתרחשים לגמרי מחוץ למודול המרוחק.

עבור משימת תמונת OpenStack, בדקו את הדרישות של אוסף openstack.cloud המותקן ואת סביבת ה-OpenStack SDK שלו. הצלחה של curl במקום אחר אינה מוכיחה את יכולות ה-SOCKS או את התלויות של אותו SDK.

אם פעולת ה-API אמורה לרוץ מקומית, הפכו את בחירת ההרצה הזו למפורשת וספקו את ההגדרה שם. אם היא רצה מרחוק, בחרו פרוקסי שנגיש מאותו הקשר. ה-environment: של משימת Ansible משפיע על תהליך המשימה; הוא אינו מגדיר מחדש כל חיפוש או תוסף, וה-SDK עדיין צריך לתמוך בסכימה בסביבת ה-Python הזו.

הפרידו בין שני מסלולים: SSH או ProxyJump מביאים את Ansible למארח, ואילו לקוח ה-HTTP של המודול עובר מסביבת ההרצה שלו אל ה-API. מסלול ראשון שעובד אינו מגדיר את השני. חשיפת מאזין שקיים רק בבקר כדי לפתור נגישות משנה גם מי יכול לגשת אליו, ולכן זו בחירת פריסה ולא תיקון כתובת.

מאמרים קשורים