Tải xuống trong terminal hoạt động nhưng tiện ích VS Code thất bại qua VPN

curl chạy trong container mà tiện ích vẫn không cài được. Hãy so sánh trình soạn thảo cục bộ và môi trường từ xa trước khi sao chép cài đặt proxy.

Các lượt tải xuống thành công trong terminal của container là bằng chứng thật về môi trường của terminal đó. Chúng không nói gì về tiến trình soạn thảo, trình cài đặt tiện ích hay tệp nhị phân mà tiện ích tải về sau đó. Việc sao chép biến proxy giữa ba thứ đó biến một yêu cầu thất bại thành cả một buổi chiều chỉnh sửa không liên quan.

Hai môi trường thường khác nhau đúng ở một điểm. Tìm ra điểm đó nhanh hơn đọc tài liệu proxy hai lần.

Tiến trình nào đã thực hiện yêu cầu thất bại

Ba yêu cầu có thể thất bại trong một lần cài đặt, và mỗi yêu cầu có danh tính mạng riêng. Trình soạn thảo hỏi Marketplace siêu dữ liệu và URL gói, sau đó tải gói về. Chỉ sau đó máy chủ tiện ích mới chạy mã có thể tải máy chủ ngôn ngữ hoặc tệp nhị phân của chính nó. Giai đoạn nào hỏng quyết định tiến trình nào cần proxy, và bề mặt lỗi hiếm khi gọi tên giai đoạn đó.

Một terminal hoạt động chứng minh container truy cập được internet, không chứng minh trình soạn thảo làm được. Đọc nhật ký tiện ích để tìm URL cuối cùng nó đã thử. Máy chủ được nêu ở đó xác định tiến trình và chính sách áp dụng cho nó.

Trình soạn thảo cục bộ và container từ xa là hai môi trường

Trong không gian làm việc từ xa, tiện ích chạy ở phía mà loại của nó khai báo. Tiện ích giao diện ở lại với trình soạn thảo cục bộ, còn tiện ích không gian làm việc chạy trong container. Proxy đặt ở phía này thì phía kia không thấy, và việc dựng lại tạo môi trường container từ tệp cấu hình của nó chứ không phải từ thứ bạn xuất trong shell. Sự tách biệt đó giải thích vì sao cùng một tiện ích cài được trên laptop và thất bại trong cùng dự án qua SSH.

Đọc vị trí cài đặt trước khi sửa bất cứ thứ gì. Khi nhật ký báo cài đặt từ xa, môi trường của container mới là thứ quan trọng.

Đặt proxy ở nơi yêu cầu bắt đầu

Với Dev Container thực sự cần proxy HTTP, biến phải nằm trong cấu hình container để việc dựng lại tái tạo nó. Đoạn dưới đây đặt nó cho môi trường đó. Địa chỉ giữ chỗ thay cho cổng của bạn, và các trường loại trừ không phải phần đệm tùy chọn.

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

Tên biến mô tả giao thức đích, nên giá trị HTTPS_PROXY có thể bắt đầu bằng http một cách hợp lệ. Áp dụng thay đổi qua đường dựng lại được hỗ trợ và giữ các trường loại trừ, vì proxy chặn máy chủ nội bộ sẽ phá vỡ các dịch vụ mà container cần.

Tách lỗi tin cậy khỏi khả năng kết nối

Một proxy kết nối rồi trả về lỗi xác minh chứng chỉ đã đạt giai đoạn muộn hơn so với proxy từ chối kết nối. Lỗi thứ nhất cần tài liệu tin cậy đã được tổ chức phê duyệt được cài trong môi trường thực hiện yêu cầu. Lỗi thứ hai cần một địa chỉ và cổng có thể kết nối. Coi cả hai là một vấn đề sẽ tạo ra bản sửa không dùng được cho cả hai.

Tắt xác minh, hoặc chạy trình soạn thảo với quyền cao hơn, không phải là sửa chữa cho proxy thiếu hay chuỗi tin cậy thiếu. Cả hai đánh đổi một lỗi hiển thị lấy một lỗi im lặng. Sau đó thử lại cùng tiện ích và ghi lại URL tiếp theo thất bại.

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

Ghi lại phía nào của không gian làm việc đã tạo ra URL đó. Một ghi chú ngắn nêu giai đoạn, máy chủ và phía đáng giá hơn danh sách cài đặt ai đó đã thay đổi, vì chính ghi chú đó là thứ người tiếp theo có thể tái tạo.

Bài viết liên quan