เข้าถึงพร็อกซีของโฮสต์จากคอนเทนเนอร์ Docker แบบ bridge

ในคอนเทนเนอร์ 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 ไม่ได้ทำให้ทุกซ็อกเก็ตเป็นคำขอผ่านพร็อกซีเพียงเพราะมีตัวแปร

ถ้าพร็อกซีทำงานบนโฮสต์ Docker

Docker Desktop มี host.docker.internal สำหรับเข้าถึงที่อยู่ภายในโฮสต์ ใน Engine เนทีฟที่รองรับ อาจเพิ่ม host mapping เพื่อให้ชื่อตามธรรมเนียมนี้ได้:

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 ระยะไกลจึงไม่จำเป็นต้องเป็นแล็ปท็อป ที่อยู่ loopback ที่คัดลอกจากแอปเดสก์ท็อปในเครื่องจึงมีโอกาสน้อยเป็นพิเศษที่จะใช้ได้โดยไม่เปลี่ยนบน builder หรือเซิร์ฟเวอร์ระยะไกล

แยกปัญหาดึงอิมเมจไว้ต่างหาก: daemon ดาวน์โหลดอิมเมจก่อนที่แอปจะใช้สภาพแวดล้อมข้างต้นได้