docker pull qua VPN: daemon có mạng riêng của nó

Laptop của bạn đang ở trên VPN của công ty, curl truy cập được registry nội bộ, vậy mà docker pull vẫn chết với EOF. Sự kết hợp đó không phải mâu thuẫn. Lệnh bạn gõ chạy trong shell của bạn, nhưng quá trình truyền tải chạy trong daemon mà Docker CLI đã chọn, và daemon đó có thể nằm trên một máy chủ hoàn toàn khác. Đường mạng của nó mới là thứ phải hoạt động, và cấu hình proxy của nó mới là thứ được áp dụng.

Hãy bắt đầu bằng việc xác định engine, không phải đường đi

Chạy docker context show và docker version. Kết quả của phiên bản in ra một phần client và một phần server, và khối server cho bạn biết thứ gì đã trả lời: một engine gốc cục bộ, máy ảo Docker Desktop, hay một daemon trên máy từ xa. docker context inspect sẽ hiển thị điểm cuối của ngữ cảnh đã chọn nếu bạn muốn chắc chắn, và không lệnh nào trong số này thay đổi điều gì.

Một biến môi trường như DOCKER_HOST có thể âm thầm hướng CLI tới một engine khác với engine bạn giả định, và đó là lời giải thích thông thường cho chiếc laptop trông như đang ở trên VPN trong khi quá trình kéo đi nơi khác.

Daemon có danh tính mạng riêng

Một engine từ xa cần đường đi được phê duyệt riêng tới registry riêng tư. Việc kết nối client VPN của laptop cho laptop đó một tuyến đường; nó không cho một daemon nằm trong phòng thí nghiệm hay trong subnet đám mây cùng địa chỉ riêng tư đó. Nếu engine là Docker Desktop, quá trình kéo diễn ra bên trong máy ảo của nó, máy này có cấu hình mạng và proxy riêng, tách biệt với môi trường shell của bạn.

Đó là lý do một curl thành công trên máy chủ chỉ là bằng chứng về máy chủ và không hơn thế.

Tìm ra trao đổi nào với registry đã kết thúc

Kéo một image là một chuỗi: xác thực, lấy manifest, rồi các lần truyền blob thường được chuyển hướng tới kho đối tượng hoặc một điểm cuối CDN. Một docker login thành công chỉ chứng minh bước đầu tiên, và một token có thể hoàn toàn hợp lệ trong khi máy chủ blob được chuyển hướng không thể truy cập từ mạng của daemon. Hãy ghi lại thời điểm chính xác, tham chiếu image và sự kiện hữu ích đầu tiên từ log của daemon hoặc client trước khi bạn thay đổi bất cứ điều gì.

EOF tự nó không nêu nguyên nhân nào. Đó có thể là kết nối bị cắt, một proxy đã bỏ dòng dữ liệu, hết thời gian chờ hay một vấn đề MTU, và việc đoán giữa chúng mà không có sự kiện được đóng dấu thời gian chính là cách người ta đi đến chỗ dựng lại một engine vốn khỏe mạnh. Hãy coi độ lệch byte trong kết quả của client là dữ liệu, vì một lần truyền dừng ở cùng kích thước mỗi lần là một con vật khác với lần truyền không bao giờ bắt đầu. Ghi lại cả hai kết quả và so sánh chúng giữa các lần thử.

Cấu hình thành phần thực hiện việc truyền

Với một engine Linux gốc, proxy thuộc về môi trường của dịch vụ, không phải shell của bạn. Một tệp drop-in dưới /etc/systemd/system/docker.service.d/ với các mục HTTP_PROXY, HTTPS_PROXY và NO_PROXY, tiếp theo là systemctl daemon-reload và khởi động lại, là cách bố trí được tài liệu hóa. Docker Desktop hiển thị các giá trị tương tự qua cài đặt riêng của nó, và việc sửa một hồ sơ shell không đụng tới cả hai.

Nếu phải tới registry trực tiếp qua VPN, daemon cần một trình phân giải, một tuyến đường và một ngoại lệ proxy có chủ đích, chứ không chỉ một ngoại lệ. Việc khớp NO_PROXY là so sánh chuỗi cho từng thành phần, và một ngoại lệ không có tuyến đường bên dưới tạo ra lỗi trông giống vấn đề proxy.

Khi kiểm tra TLS của doanh nghiệp nằm trên đường đi được phê duyệt, hãy cài gốc đã xác minh của nó thông qua quy trình của engine hoặc Desktop. Thêm registry vào insecure-registries là một thay đổi khác làm tắt việc xác thực, và đó không phải cấu hình kho tin cậy.

Lặp lại một lần kéo có kiểm soát và xem điều gì đã thay đổi

Thay đổi một ranh giới, khởi động lại thành phần sở hữu nó, và lặp lại lần kéo tương tự từ cùng ngữ cảnh. Hãy xác minh tham chiếu image và digest thu được, chứ không phải sự vắng mặt của lỗi, vì một lớp được lưu trong bộ nhớ đệm có thể khiến lần thử thứ hai đi qua ít đường hơn nhiều so với lần đầu. Giữ lại trong phiếu các lần truyền thực sự đã xảy ra, vì chúng là bản ghi duy nhất về những gì lần thử lại thực sự kiểm tra.

Các bước build và container đang chạy có ngữ cảnh mạng riêng, vì vậy hãy coi chúng là những câu hỏi riêng sau khi bản thân việc kéo đã hoạt động.