Mengapa Proksi Korporat Anda Cuba Menyelesaikan Nama Perkhidmatan Compose

Klien HTTP boleh menghantar permintaan perkhidmatan dalaman kepada proksi yang dikonfigurasikan sebelum menggunakan penyelesaian nama perkhidmatan Docker. Tambah pintasan yang disengajakan untuk klien yang betul.

Aplikasi mencapai internet melalui proksi korporatnya, tetapi http://catalog:8080/ gagal dan proksi tidak dapat menyelesaikan “catalog”. Permintaan itu mungkin tidak pernah menggunakan DNS dalaman Docker.

Klien HTTP boleh memilih proksinya sebelum membuat sambungan langsung. Proksi luaran kemudian menerima nama yang maknanya hanya wujud di dalam rangkaian Compose.

  1. Gunakan nama hos dalam permintaan. Perkhidmatan Compose boleh ditemui mengikut nama perkhidmatan pada rangkaian yang sesuai. Tambah catalog ke konfigurasi pintasan yang disokong klien pengguna dan bukan mengodkan IP kontena secara keras yang boleh berubah.
  2. Kekalkan pengecualian sedia ada. Untuk klien yang sedar persekitaran, gabungkan entri berkaitan dengan senarai organisasi:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Periksa pustaka atau fail boleh laku sebenar dalam imej untuk pengendalian huruf besar dan kecil, versi dan tatabahasa pemadanan. Tiada penghurai NO_PROXY sejagat. Program bernama wget dalam imej kecil tidak semestinya berkelakuan seperti GNU Wget.

Sebaik sahaja permintaan memilih penghalaan langsung, periksa rangkaian kongsi pemanggil dan perkhidmatan, perkhidmatan yang mendengar dan port kontena. Port hos yang diterbitkan ialah titik akhir lain. Pintasan tidak boleh menambah sambungan rangkaian yang hilang, sama seperti mencipta semula rangkaian tidak boleh mengajar proksi luaran nama Compose peribadi.

Kekalkan pembahagian yang dimaksudkan: permintaan dalaman menggunakan laluan dalamannya; permintaan luaran mengekalkan proksi yang diluluskan. Melumpuhkan proksi secara global boleh menyembunyikan satu kegagalan ini sambil membuang laluan yang diperlukan untuk permintaan luaran seterusnya.

Artikel berkaitan