Tại sao proxy công ty của bạn lại cố phân giải tên dịch vụ Compose

Một ứng dụng khách HTTP có thể gửi yêu cầu dịch vụ nội bộ đến proxy đã cấu hình trước khi dùng tính năng phân giải tên dịch vụ của Docker. Hãy thêm các đường bỏ qua có chủ đích cho đúng ứng dụng khách.

Ứng dụng truy cập internet qua proxy công ty, nhưng http://catalog:8080/ thất bại và proxy không thể phân giải “catalog”. Có thể yêu cầu đó chưa bao giờ dùng DNS nội bộ của Docker.

Một ứng dụng khách HTTP có thể chọn proxy trước khi tạo kết nối trực tiếp. Proxy bên ngoài sau đó nhận được một cái tên chỉ có ý nghĩa bên trong mạng Compose.

  1. Dùng tên máy chủ trong yêu cầu. Các dịch vụ Compose có thể được phát hiện theo tên dịch vụ trên mạng phù hợp. Thêm catalog vào cấu hình bỏ qua được ứng dụng khách sử dụng hỗ trợ thay vì mã hóa cứng IP container có thể thay đổi.
  2. Giữ nguyên các ngoại lệ hiện có. Với ứng dụng khách nhận biết môi trường, hãy hợp nhất các mục liên quan với danh sách của tổ chức:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Kiểm tra thư viện hoặc tệp thực thi thực tế trong image về cách xử lý chữ hoa chữ thường, phiên bản và ngữ pháp so khớp. Không có bộ phân tích NO_PROXY phổ quát. Một chương trình tên wget trong image nhỏ không nhất thiết phải hành xử như GNU Wget.

Sau khi yêu cầu chọn định tuyến trực tiếp, hãy kiểm tra mạng chia sẻ của bên gọi và dịch vụ, dịch vụ đang lắng nghe và cổng container. Cổng máy chủ được công bố là một điểm cuối khác. Bỏ qua không thể thêm một kết nối mạng còn thiếu, cũng như việc tạo lại mạng không thể dạy cho proxy bên ngoài một tên Compose riêng tư.

Giữ nguyên sự phân tách dự định: yêu cầu nội bộ dùng đường đi nội bộ; yêu cầu bên ngoài giữ proxy đã được phê duyệt. Tắt proxy trên toàn cục có thể che giấu lỗi duy nhất này đồng thời loại bỏ tuyến cần thiết cho yêu cầu bên ngoài tiếp theo.

Bài viết liên quan