ເປັນຫຍັງຄອນເທນເນີພຣັອກຊີຈຶ່ງບໍ່ໃຊ້ຄອນເທນເນີ DNS ອັດຕະໂນມັດ

ການເຮັດວຽກຂອງພຣັອກຊີ ແລະ ເຊີບເວີ DNS ໃນໂຮສ Docker ດຽວກັນບໍ່ໄດ້ເຊື່ອມເສັ້ນທາງ DNS ຂອງພວກມັນ. ມີສາມຄວາມສໍາພັນແຍກຕ່າງຫາກທີ່ສໍາຄັນ:

• ການເຂົ້າເຖິງເຄືອຂ່າຍ. ໂຄງການ Compose ແຍກຕ່າງຫາກໂດຍປົກກະຕິມີເຄືອຂ່າຍເລີ່ມຕົ້ນແຍກຕ່າງຫາກ. ວາງບໍລິການໄວ້ໃນເຄືອຂ່າຍຮ່ວມທີ່ເໝາະສົມ ບໍ່ວ່າຈະຢູ່ໃນໂຄງການດຽວ ຫຼື ຜ່ານເຄືອຂ່າຍທີ່ແບ່ງປັນຢ່າງຊັດເຈນລະຫວ່າງໂຄງການ.
• ການຄົ້ນພົບບໍລິການ. DNS ທີ່ຝັງຢູ່ໃນເຄືອຂ່າຍ Docker ແບບກຳນົດເອງສາມາດແກ້ໄຂຊື່ຄອນເທນເນີໄດ້. ສິ່ງນີ້ເຮັດໃຫ້ແອັບພລິເຄຊັນຄົ້ນພົບເພື່ອນບ້ານໄດ້ ແຕ່ມັນບໍ່ໄດ້ເລືອກເພື່ອນບ້ານນັ້ນເປັນຕົວແກ້ໄຂ DNS ຂອງຕົນໂດຍອັດຕະໂນມັດ.
• ການເລືອກຕົວແກ້ໄຂ. ກຳນົດຕົວແກ້ໄຂທີ່ໃຊ້ພາຍໃນຄອນເທນເນີພຣັອກຊີ. ຊ່ອງຂໍ້ມູນ dns ຂອງ Compose ຮັບທີ່ຢູ່ຂອງເຊີບເວີ DNS. ຊື່ຢ່າງ dns.local ທີ່ແກ້ໄຂໃນແອັບພລິເຄຊັນບໍ່ໄດ້ເຮັດໃຫ້ມັນເປັນຄ່າທີ່ຖືກຕ້ອງສຳລັບຊ່ອງຂໍ້ມູນນັ້ນ.

ຕິດຕາມຄຳຖາມຈາກຄອນເທນເນີພຣັອກຊີໄປຫາທີ່ຢູ່ຕົວແກ້ໄຂທີ່ຕັ້ງໄວ້. ຢືນຢັນວ່າມີເສັ້ນທາງ ແລະ ຕົວຮັບຟັງ DNS ຢູ່ທີ່ຢູ່ນັ້ນ. ການເຜີຍແຜ່ພອດ 53 ຂອງໂຮສສ້າງເສັ້ນທາງເຂົ້າເຖິງທາງຝ່າຍໂຮສ ແຕ່ມັນບໍ່ໄດ້ບອກຄອນເທນເນີໃຫ້ໃຊ້ມັນ. ຄອນເທນເນີທີ່ແບ່ງປັນເຄືອຂ່າຍອາດສື່ສານກັນໂດຍກົງແທນ.

ຖ້າການຕັ້ງຄ່າອ້າງອີງທີ່ຢູ່ຂອງຄອນເທນເນີ DNS ໃຫ້ຮັກສາມັນໃຫ້ໝັ້ນຄົງພາຍໃຕ້ການຕັ້ງຄ່າ IPAM ທີ່ເຂົ້າກັນໄດ້. ທີ່ຢູ່ທີ່ຖືກຈັດສັນແບບເຄື່ອນທີ ແລະ ຄັດລອກມາຈາກຄອນເທນເນີຂອງມື້ວານນີ້ອາດລົ້ມເຫຼວເມື່ອສ້າງໃໝ່. ກວດເບິ່ງເສັ້ນທາງຕົ້ນນ້ຳຂອງຕົວແກ້ໄຂດ້ວຍ: ການສົ່ງຄຳຖາມທີ່ບໍ່ມີຄຳຕອບກັບໄປຫາຕົວມັນເອງສ້າງຄວາມລົ້ມເຫຼວຕ່າງຈາກຕົວແກ້ໄຂທີ່ເຂົ້າບໍ່ເຖິງ.

ສຸດທ້າຍ ກຳນົດວ່າໃຜແກ້ໄຂປາຍທາງ. ພຣັອກຊີ HTTP ທີ່ແກ້ໄຂຊື່ CONNECT ສາມາດໃຊ້ເສັ້ນທາງຄອນເທນເນີນີ້ໄດ້ ແຕ່ລູກຂ່າຍ SOCKS ທີ່ແກ້ໄຂໃນເຄື່ອງອາດບໍ່ໃຊ້. ການຄົ້ນຫາເທິງໂຮສພິສູດເສັ້ນທາງຂອງໂຮສ ບໍ່ແມ່ນຂອງຂະບວນການພຣັອກຊີ.