ทำไมคอนเทนเนอร์พร็อกซีจึงไม่ใช้คอนเทนเนอร์ DNS โดยอัตโนมัติ

การรันพร็อกซีและเซิร์ฟเวอร์ DNS บนโฮสต์ Docker เดียวกันไม่ได้เชื่อมเส้นทาง DNS ของทั้งสองเข้าด้วยกัน มีความสัมพันธ์แยกกันสามอย่างที่สำคัญ:

• การเข้าถึงเครือข่าย โปรเจกต์ Compose ที่แยกกันมักมีเครือข่ายเริ่มต้นแยกกัน วางบริการไว้บนเครือข่ายที่แชร์กันอย่างเหมาะสม ไม่ว่าจะภายในโปรเจกต์เดียวหรือผ่านเครือข่ายที่แชร์กันอย่างชัดเจนระหว่างโปรเจกต์
• การค้นหาบริการ DNS ที่ฝังอยู่ในเครือข่าย Docker แบบกำหนดเองสามารถแก้ชื่อคอนเทนเนอร์ได้ ซึ่งช่วยให้แอปพลิเคชันค้นพบเพื่อนบ้านได้ แต่ไม่ได้เลือกเพื่อนบ้านนั้นเป็นตัวแก้ไขชื่อ DNS ของตนโดยอัตโนมัติ
• การเลือกตัวแก้ไขชื่อ ระบุตัวแก้ไขชื่อที่ใช้ภายในคอนเทนเนอร์พร็อกซี ฟิลด์ dns ของ Compose รับที่อยู่เซิร์ฟเวอร์ DNS ชื่ออย่าง dns.local ที่แก้ได้ในแอปพลิเคชันไม่ได้ทำให้เป็นค่าที่ถูกต้องสำหรับฟิลด์นั้น

ติดตามคำถามจากคอนเทนเนอร์พร็อกซีไปยังที่อยู่ตัวแก้ไขชื่อที่กำหนดไว้ ยืนยันว่ามีเส้นทางและตัวรับฟัง DNS ที่ที่อยู่นั้น การเผยแพร่พอร์ต 53 ของโฮสต์สร้างเส้นทางเข้าถึงฝั่งโฮสต์ แต่ไม่ได้บอกให้คอนเทนเนอร์ใช้งาน คอนเทนเนอร์ที่แชร์เครือข่ายอาจสื่อสารกันโดยตรงแทน

หากการกำหนดค่าอ้างอิงที่อยู่ของคอนเทนเนอร์ DNS ให้คงที่ภายใต้การกำหนดค่า IPAM ที่เข้ากันได้ ที่อยู่ที่จัดสรรแบบไดนามิกและคัดลอกจากคอนเทนเนอร์เมื่อวานอาจล้มเหลวเมื่อสร้างใหม่ ตรวจสอบเส้นทางต้นทางของตัวแก้ไขชื่อด้วย การส่งคำถามที่ไม่ได้รับคำตอบกลับไปยังตัวเองทำให้เกิดความล้มเหลวที่ต่างจากตัวแก้ไขชื่อที่เข้าถึงไม่ได้

สุดท้าย ระบุว่าใครแก้ไขปลายทาง พร็อกซี HTTP ที่แก้ชื่อ CONNECT สามารถใช้เส้นทางคอนเทนเนอร์นี้ได้ ไคลเอนต์ SOCKS ที่แก้ในเครื่องอาจไม่ใช้ การค้นหาบนโฮสต์พิสูจน์เส้นทางของโฮสต์ ไม่ใช่ของกระบวนการพร็อกซี