מדוע ה-proxy הארגוני שלך מנסה לפתור שם שירות של Compose
לקוח HTTP יכול לשלוח בקשת שירות פנימית ל-proxy המוגדר שלו לפני שהוא משתמש בפתרון שמות השירותים של Docker. הוסף עקיפות מכוונות עבור הלקוח הנכון.
היישום מגיע לאינטרנט דרך ה-proxy הארגוני שלו, אך http://catalog:8080/ נכשל וה-proxy אינו יכול לפתור את “catalog”. ייתכן שהבקשה הזו מעולם לא השתמשה ב-DNS הפנימי של Docker.
לקוח HTTP יכול לבחור את ה-proxy שלו לפני יצירת חיבור ישיר. ה-proxy החיצוני מקבל אז שם שמשמעותו קיימת רק בתוך רשת ה-Compose.
- השתמש בשם המארח בבקשה. ניתן לגלות שירותי Compose לפי שם שירות ברשת המתאימה. הוסף את
catalogלתצורת העקיפה הנתמכת של הלקוח הצורך, במקום לקודד באופן קשיח כתובת IP של מכולה שעלולה להשתנות. - שמור על החריגים הקיימים. עבור לקוח המודע לסביבה, מזג את הערכים הרלוונטיים עם רשימת הארגון:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogבדוק את הספרייה או קובץ ההרצה בפועל בתמונה בכל הנוגע לטיפול באותיות רישיות וקטנות, גרסה ודקדוק התאמה. אין מנתח NO_PROXY אוניברסלי. תוכנית בשם wget בתמונה קטנה אינה חייבת להתנהג כמו GNU Wget.
לאחר שהבקשה בוחרת בניתוב ישיר, בדוק את הרשת המשותפת של הקורא והשירות, את השירות המאזין ואת פורט המכולה. פורט מארח מפורסם הוא נקודת קצה אחרת. עקיפה אינה יכולה להוסיף חיבור רשת חסר, כשם שיצירה מחדש של רשת אינה יכולה ללמד proxy חיצוני שם Compose פרטי.
שמור על החלוקה המיועדת: בקשות פנימיות משתמשות בנתיב הפנימי שלהן; בקשות חיצוניות שומרות על ה-proxy המאושר. השבתת ה-proxy באופן גלובלי עלולה להסתיר את הכשל הבודד הזה ובמקביל להסיר את הנתיב הדרוש לבקשה החיצונית הבאה.