בקונטיינר רגיל ברשת bridge, הכתובת 127.0.0.1 היא כתובת ה־loopback של הקונטיינר עצמו. פרוקסי שמאזין ב־localhost של המחשב הנייד אינו מאזין אוטומטית בתוך כל קונטיינר.

כך אפשר להסביר הבדל נפוץ: אותה כתובת URL של פרוקסי פועלת במסוף המארח, אך בתוך הקונטיינר החיבור נדחה. בכל מקום הכתובת מצביעה על נקודת קצה אחרת ברשת.

אפשר להשתמש בפרוקסי ציבורי ישירות

אם נקודת הקצה שנבחרה משירות או מרשימת פרוקסי HTTP היא אכן כתובת IP ציבורית נגישה, העבירו אותה ליישום במקום להמיר אותה ל־localhost:

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

החליפו את כתובת הדוגמה בתיעוד ואת האימג׳. התוכנית שבתוך האימג׳ עדיין צריכה לתמוך במשתני הסביבה האלה; Docker אינו הופך כל socket לבקשה דרך פרוקסי רק משום שהמשתנים קיימים.

אם הפרוקסי פועל במארח Docker

Docker Desktop מספק את host.docker.internal לצורך גישה לכתובת הפנימית של המארח. בתצורת Engine מקורית שנתמכת, מיפוי מארח יכול לספק את השם המקובל הזה:

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

הפעולה משנה את פענוח השמות; זו אינה פקודה להעברת פורטים. ב־Linux מקורי, שירות שמאוגד רק לכתובת ה־loopback של המארח עלול להישאר בלתי נגיש דרך כתובת ה־bridge של המארח. המאזין, חומת האש והנתיב של הקונטיינר צריכים לאפשר את החיבור. אם משנים את המאזין, הגבילו אותו ללקוחות שזקוקים לגישה במקום ליצור פרוקסי פתוח ללא אימות.

בדקו מאותו מקום שבו פועל היישום

תוצאת curl בצד המארח בודקת רק את נתיב המארח. שלחו את הבקשה המתאימה מתוך סביבת הקונטיינר ובדקו אם היא מגיעה לנקודת הקצה הרצויה.

השם ״מארח״ מתייחס גם למחשב שמפעיל את Docker Engine. כשמשתמשים ב־Engine מרוחק, זה אינו בהכרח המחשב הנייד שלכם. לכן הסיכוי שכתובת IP של loopback שהועתקה מיישום שולחני מקומי תפעל ללא שינוי בבונה או בשרת מרוחק קטן במיוחד.

הפרידו בעיות של משיכת אימג׳: הדמון מוריד את האימג׳ לפני שהיישום יכול להשתמש בסביבה המוצגת לעיל.

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