מדוע מכולת פרוקסי אינה משתמשת אוטומטית במכולת ה-DNS
שיתוף מארח Docker, שיתוף רשת ובחירת פותר הם שלושה סידורים שונים. עקבו אחר שאילתת ה-DNS מתוך הפרוקסי.
הרצת פרוקסי ושרת DNS על אותו מארח Docker אינה מחברת את נתיבי ה-DNS שלהם. שלושה קשרים נפרדים חשובים:
- נגישות רשת. לפרויקטי Compose נפרדים יש בדרך כלל רשתות ברירת מחדל נפרדות. הציבו את השירותים ברשת משותפת מתאימה, בין בתוך פרויקט אחד ובין דרך רשת המשותפת במפורש בין פרויקטים.
- גילוי שירותים. ה-DNS המוטמע של רשת Docker מותאמת יכול לפתור שמות מכולות. זה מאפשר ליישום לגלות שכן; אך הוא אינו בוחר באותו שכן אוטומטית כפותר ה-DNS שלו.
- בחירת פותר. זהו את הפותר שבו משתמשים בתוך מכולת הפרוקסי. השדה
dnsשל Compose מקבל כתובות של שרתי DNS. שם כגוןdns.localשנפתר ביישום אינו הופך אותו לערך חוקי עבור אותו שדה.
עקבו אחר השאילתה ממכולת הפרוקסי אל כתובת הפותר המוגדרת שלה. ודאו שקיימים נתיב ומאזין DNS בכתובת זו. פרסום פורט 53 של המארח יוצר נתיב גישה בצד המארח; אך הוא אינו אומר למכולות להשתמש בו. מכולות החולקות רשת יכולות במקום זאת לתקשר ישירות.
אם התצורה מפנה לכתובת מכולת ה-DNS, שמרו עליה יציבה תחת תצורת IPAM תואמת. כתובת שהוקצתה דינמית והועתקה מהמכולה של אתמול עלולה להיכשל בעת יצירה מחדש. בחנו גם את נתיב ה-upstream של הפותר: העברת שאילתות ללא מענה חזרה אליו עצמו יוצרת כשל שונה מפותר שאינו נגיש.
לבסוף, זהו מי פותר את היעד. פרוקסי HTTP שפותר שם CONNECT יכול להשתמש בנתיב המכולה הזה; לקוח SOCKS שפותר מקומית אולי לא. חיפוש מהמארח מוכיח את הנתיב של המארח, לא את זה של תהליך הפרוקסי.