ເປັນຫຍັງ proxy ຂອງບໍລິສັດຂອງທ່ານຈຶ່ງພະຍາຍາມແກ້ໄຂຊື່ບໍລິການ Compose
ລູກຄ້າ HTTP ສາມາດສົ່ງຄຳຮ້ອງບໍລິການພາຍໃນໄປຫາ proxy ທີ່ຕັ້ງຄ່າໄວ້ ກ່ອນທີ່ຈະໃຊ້ການແກ້ໄຂຊື່ບໍລິການຂອງ Docker. ເພີ່ມການຂ້າມທີ່ເຈດຕະນາ ສຳລັບລູກຄ້າທີ່ເໝາະສົມ.
ແອັບພລິເຄຊັນເຂົ້າເຖິງອິນເຕີເນັດຜ່ານ proxy ຂອງບໍລິສັດ, ແຕ່ http://catalog:8080/ ລົ້ມເຫລວ ແລະ proxy ບໍ່ສາມາດແກ້ໄຂ “catalog” ໄດ້. ຄຳຮ້ອງນັ້ນອາດຈະບໍ່ເຄີຍໃຊ້ DNS ພາຍໃນຂອງ Docker.
ລູກຄ້າ HTTP ສາມາດເລືອກ proxy ຂອງຕົນ ກ່ອນທີ່ຈະເຊື່ອມຕໍ່ໂດຍກົງ. ແລ້ວ proxy ພາຍນອກຈະໄດ້ຮັບຊື່ທີ່ຄວາມໝາຍຂອງມັນມີຢູ່ພາຍໃນເຄືອຂ່າຍ Compose ເທົ່ານັ້ນ.
- ໃຊ້ຊື່ໂຮສໃນຄຳຮ້ອງ. ບໍລິການ Compose ສາມາດຄົ້ນພົບໄດ້ດ້ວຍຊື່ບໍລິການໃນເຄືອຂ່າຍທີ່ເໝາະສົມ. ເພີ່ມ
catalogໃສ່ການຕັ້ງຄ່າການຂ້າມທີ່ຮອງຮັບໂດຍລູກຄ້າຜູ້ໃຊ້ ແທນການຂຽນ IP ຂອງຄອນເທນເນີແບບຄົງທີ່ທີ່ອາດປ່ຽນໄດ້. - ຮັກສາຂໍ້ຍົກເວັ້ນທີ່ມີຢູ່. ສຳລັບລູກຄ້າທີ່ຮູ້ສະພາບແວດລ້ອມ, ລວມລາຍການທີ່ກ່ຽວຂ້ອງກັບລາຍຊື່ຂອງອົງກອນ:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogກວດເບິ່ງຫ້ອງສະໝຸດ ຫຼືໄຟລ໌ທີ່ປະຕິບັດຕົວຈິງໃນອິມເອສ ສຳລັບການຈັດການຕົວພິມນ້ອຍ-ໃຫຍ່, ສະບັບ ແລະໄວຍາກອນການຈັບຄູ່. ບໍ່ມີຕົວແຍກ NO_PROXY ທົ່ວໄປ. ໂປຣແກຣມຊື່ wget ໃນອິມເອສນ້ອຍໆ ບໍ່ຈຳເປັນຕ້ອງປະພຶດຄື GNU Wget.
ເມື່ອຄຳຮ້ອງເລືອກການເສັ້ນທາງໂດຍກົງແລ້ວ, ກວດເບິ່ງເຄືອຂ່າຍຮ່ວມຂອງຜູ້ເອີ້ນ ແລະບໍລິການ, ບໍລິການທີ່ຮັບຟັງ ແລະພອດຂອງຄອນເທນເນີ. ພອດໂຮສທີ່ເຜີຍແຜ່ແມ່ນຈຸດປາຍທາງອື່ນ. ການຂ້າມບໍ່ສາມາດເພີ່ມການເຊື່ອມຕໍ່ເຄືອຂ່າຍທີ່ຂາດຫາຍໄປໄດ້, ຄືກັນກັບການສ້າງເຄືອຂ່າຍຄືນໃໝ່ບໍ່ສາມາດສອນຊື່ Compose ສ່ວນຕົວໃຫ້ proxy ພາຍນອກໄດ້.
ຮັກສາການແບ່ງທີ່ຕັ້ງໃຈ: ຄຳຮ້ອງພາຍໃນໃຊ້ເສັ້ນທາງພາຍໃນ; ຄຳຮ້ອງພາຍນອກຮັກສາ proxy ທີ່ໄດ້ຮັບອະນຸມັດ. ການປິດ proxy ໃນທົ່ວໂລກອາດປິດບັງຄວາມຜິດພາດດຽວນີ້ ໃນຂະນະທີ່ລຶບເສັ້ນທາງທີ່ຈຳເປັນສຳລັບຄຳຮ້ອງພາຍນອກຕໍ່ໄປ.