ดาวน์โหลดในเทอร์มินัลทำงาน แต่ส่วนขยาย VS Code ล้มเหลวบน VPN

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

สภาพแวดล้อมสองแบบมักแตกต่างกันในจุดเดียวเท่านั้น การหาจุดนั้นเร็วกว่าการอ่านเอกสารพร็อกซีสองครั้ง

กระบวนการใดเป็นผู้ส่งคำขอที่ล้มเหลว

คำขอสามรายการอาจล้มเหลวระหว่างการติดตั้งครั้งเดียว และแต่ละรายการมีตัวตนบนเครือข่ายของตัวเอง ตัวแก้ไขขอเมทาดาทาและ URL แพ็กเกจจาก Marketplace แล้วดาวน์โหลดแพ็กเกจ หลังจากนั้นโฮสต์ของส่วนขยายจึงรันโค้ดที่อาจดึงเซิร์ฟเวอร์ภาษาหรือไบนารีของตัวเอง ขั้นตอนที่เสียหายเป็นตัวกำหนดว่ากระบวนการใดต้องการพร็อกซี และพื้นผิวของข้อผิดพลาดแทบไม่ระบุขั้นตอนนั้น

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

ตัวแก้ไขในเครื่องกับคอนเทนเนอร์ระยะไกลเป็นสองสภาพแวดล้อม

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

อ่านตำแหน่งการติดตั้งก่อนแก้ไขสิ่งใด เมื่อบันทึกรายงานการติดตั้งระยะไกล สภาพแวดล้อมของคอนเทนเนอร์คือสิ่งที่สำคัญ

วางพร็อกซีไว้ที่จุดที่คำขอเริ่มต้น

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

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

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

แยกความล้มเหลวด้านความเชื่อถือออกจากความสามารถในการเข้าถึง

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

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

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

บันทึกว่าด้านใดของพื้นที่ทำงานสร้าง URL นั้น โน้ตสั้น ๆ ที่ระบุขั้นตอน โฮสต์ และด้านมีค่ามากกว่ารายการการตั้งค่าที่ใครบางคนเปลี่ยน เพราะโน้ตนั้นคือสิ่งที่คนถัดไปสามารถทำซ้ำได้