docker pull ผ่าน VPN: ดีมอนมีเครือข่ายของตัวเอง

แล็ปท็อปของคุณอยู่ใน VPN ขององค์กร curl เข้าถึง registry ภายในได้ แต่ docker pull ยังคงล้มเหลวด้วย EOF การรวมกันนี้ไม่ใช่ความขัดแย้ง คำสั่งที่คุณพิมพ์ทำงานในเชลล์ของคุณ แต่การถ่ายโอนทำงานในดีมอนที่ Docker CLI เลือก และดีมอนนั้นอาจอยู่บนโฮสต์อื่นโดยสิ้นเชิง เส้นทางเครือข่ายของดีมอนนั้นคือสิ่งที่ต้องทำงาน และการตั้งค่าพร็อกซี่ของดีมอนนั้นคือสิ่งที่บังคับใช้

เริ่มจากการระบุเอนจิน ไม่ใช่เส้นทาง

รัน docker context show และ docker version เอาต์พุตของเวอร์ชันจะพิมพ์ส่วนไคลเอนต์และส่วนเซิร์ฟเวอร์ และบล็อกเซิร์ฟเวอร์จะบอกคุณว่าอะไรตอบกลับ: เอนจินพื้นเมืองในเครื่อง, เครื่องเสมือนของ Docker Desktop หรือดีมอนบนเครื่องระยะไกล docker context inspect จะแสดงปลายทางของบริบทที่เลือกหากคุณต้องการความแน่ใจ และคำสั่งเหล่านี้ไม่เปลี่ยนอะไรเลย

ตัวแปรสภาพแวดล้อมอย่าง DOCKER_HOST สามารถชี้ CLI ไปยังเอนจินอื่นที่คุณไม่ได้คาดไว้ได้อย่างเงียบ ๆ และนั่นคือคำอธิบายปกติของแล็ปท็อปที่ดูเหมือนอยู่ใน VPN ขณะที่การดึงไปที่อื่น

ดีมอนมีอัตลักษณ์เครือข่ายของตัวเอง

เอนจินระยะไกลต้องมีเส้นทางที่ได้รับอนุมัติของตัวเองไปยัง registry ส่วนตัว การเชื่อมต่อไคลเอนต์ VPN ของแล็ปท็อปทำให้แล็ปท็อปนั้นมีเส้นทาง แต่ไม่ได้ให้ที่อยู่ส่วนตัวเดียวกันกับดีมอนที่อยู่ในห้องแล็บหรือซับเน็ตคลาวด์ หากเอนจินคือ Docker Desktop การดึงจะเกิดขึ้นภายในเครื่องเสมือนของมัน ซึ่งมีการกำหนดค่าเครือข่ายและพร็อกซี่แยกจากสภาพแวดล้อมเชลล์ของคุณ

นั่นคือเหตุผลที่ curl ที่สำเร็จบนโฮสต์เป็นหลักฐานเกี่ยวกับโฮสต์เท่านั้น ไม่มากไปกว่านั้น

ค้นหาว่าการแลกเปลี่ยนใดกับ registry ที่สิ้นสุดลง

การดึงอิมเมจเป็นลำดับ: การพิสูจน์ตัวตน การดึง manifest แล้วจึงเป็นการถ่ายโอน blob ที่มักถูกเปลี่ยนเส้นทางไปยังที่เก็บออบเจกต์หรือปลายทาง CDN docker login ที่สำเร็จพิสูจน์เพียงขั้นตอนแรก และโทเคนอาจใช้ได้สมบูรณ์ขณะที่โฮสต์ blob ที่ถูกเปลี่ยนเส้นทางเข้าถึงไม่ได้จากเครือข่ายของดีมอน บันทึกเวลาที่แน่นอน การอ้างอิงอิมเมจ และเหตุการณ์ที่มีประโยชน์เหตุการณ์แรกจากบันทึกของดีมอนหรือไคลเอนต์ก่อนที่คุณจะเปลี่ยนอะไร

EOF เพียงอย่างเดียวไม่ได้ระบุสาเหตุ อาจเป็นการเชื่อมต่อที่ถูกตัด พร็อกซี่ที่ทิ้งสตรีม หมดเวลา หรือปัญหา MTU และการเดาระหว่างกันโดยไม่มีเหตุการณ์ที่มีการประทับเวลาเป็นวิธีที่ผู้คนลงเอยด้วยการสร้างเอนจินที่ดีต่อสุขภาพใหม่ ให้ถือว่าการเลื่อนไบต์ในเอาต์พุตของไคลเอนต์เป็นข้อมูล เพราะการถ่ายโอนที่หยุดที่ขนาดเดิมทุกครั้งเป็นสัตว์คนละตัวกับการถ่ายโอนที่ไม่เคยเริ่ม บันทึกผลลัพธ์ทั้งสองและเปรียบเทียบระหว่างความพยายาม

กำหนดค่าองค์ประกอบที่ทำการถ่ายโอน

สำหรับเอนจิน Linux พื้นเมือง พร็อกซี่อยู่ในสภาพแวดล้อมของบริการ ไม่ใช่ในเชลล์ของคุณ ไฟล์ drop-in ใต้ /etc/systemd/system/docker.service.d/ ที่มีรายการ HTTP_PROXY HTTPS_PROXY และ NO_PROXY ตามด้วย systemctl daemon-reload และการรีสตาร์ท คือรูปแบบที่มีเอกสารกำกับ Docker Desktop เปิดเผยค่าเดียวกันผ่านการตั้งค่าของตัวเอง และการแก้ไขโปรไฟล์เชลล์ไม่ได้แตะทั้งสองอย่าง

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

เมื่อการตรวจสอบ TLS ขององค์กรอยู่ในเส้นทางที่ได้รับอนุมัติ ให้ติดตั้งรูทที่ตรวจสอบแล้วผ่านเวิร์กโฟลว์ของเอนจินหรือ Desktop การเพิ่ม registry ลงใน insecure-registries เป็นการเปลี่ยนแปลงอีกอย่างที่ปิดการตรวจสอบความถูกต้อง และไม่ใช่การกำหนดค่าที่เก็บความเชื่อถือ

ทำการดึงที่ควบคุมได้หนึ่งครั้งซ้ำและตรวจสอบว่าอะไรเปลี่ยนไป

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

ขั้นตอน build และคอนเทนเนอร์ที่กำลังทำงานมีบริบทเครือข่ายของตัวเอง ดังนั้นจงถือว่าเป็นคำถามแยกกันเมื่อการดึงเองทำงานได้