ສະບາຍດີທຸກຄົນ! ຂ້ອຍຊື່ Pavel Agaletsky. ຂ້ອຍເຮັດວຽກເປັນຫົວຫນ້າທີມໃນທີມທີ່ພັດທະນາລະບົບການຈັດສົ່ງ Lamoda. ໃນປີ 2018, ຂ້າພະເຈົ້າໄດ້ເວົ້າຢູ່ໃນກອງປະຊຸມ HighLoad ++, ແລະໃນມື້ນີ້ຂ້າພະເຈົ້າຢາກນໍາສະເຫນີບົດບັນທຶກຂອງບົດລາຍງານຂອງຂ້າພະເຈົ້າ.

ຫົວຂໍ້ຂອງຂ້ອຍແມ່ນອຸທິດຕົນໃຫ້ກັບປະສົບການຂອງບໍລິສັດຂອງພວກເຮົາໃນການນໍາໃຊ້ລະບົບແລະການບໍລິການກັບສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ. ເລີ່ມຕົ້ນຈາກສະ ໄໝ ກ່ອນປະຫວັດສາດຂອງພວກເຮົາ, ເມື່ອພວກເຮົາ ນຳ ໃຊ້ລະບົບທັງ ໝົດ ເຂົ້າໄປໃນເຊີບເວີສະເໝືອນ ທຳ ມະດາ, ສິ້ນສຸດດ້ວຍການປ່ຽນເທື່ອລະກ້າວຈາກ Nomad ໄປສູ່ການ ນຳ ໃຊ້ Kubernetes. ຂ້ອຍຈະບອກເຈົ້າວ່າເປັນຫຍັງພວກເຮົາເຮັດມັນ ແລະບັນຫາໃດທີ່ພວກເຮົາມີຢູ່ໃນຂະບວນການ.

ນຳໃຊ້ແອັບພລິເຄຊັນໄປຍັງ VM

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຄວາມຈິງທີ່ວ່າ 3 ປີທີ່ຜ່ານມາລະບົບແລະການບໍລິການຂອງບໍລິສັດທັງຫມົດໄດ້ຖືກນໍາໄປໃຊ້ໃນເຄື່ອງແມ່ຂ່າຍ virtual ປົກກະຕິ. ທາງດ້ານເທກນິກ, ມັນຖືກຈັດໃສ່ໃນລັກສະນະທີ່ລະຫັດທັງຫມົດສໍາລັບລະບົບຂອງພວກເຮົາຖືກເກັບຮັກສາແລະປະກອບໂດຍໃຊ້ເຄື່ອງມືປະກອບອັດຕະໂນມັດ, ໂດຍໃຊ້ jenkins. ການນໍາໃຊ້ Ansible, ມັນໄດ້ຖືກ rolled ອອກຈາກລະບົບການຄວບຄຸມສະບັບຂອງພວກເຮົາກັບເຄື່ອງແມ່ຂ່າຍ virtual. ຍິ່ງໄປກວ່ານັ້ນ, ແຕ່ລະລະບົບທີ່ບໍລິສັດຂອງພວກເຮົາໄດ້ຖືກນໍາໃຊ້ກັບຢ່າງຫນ້ອຍ 2 ເຄື່ອງແມ່ຂ່າຍ: ຫນຶ່ງໃນນັ້ນຢູ່ເທິງຫົວ, ທີສອງຢູ່ຫາງ. ສອງລະບົບນີ້ແມ່ນຄ້າຍຄືກັນຢ່າງແທ້ຈິງກັບກັນແລະກັນໃນທຸກການຕັ້ງຄ່າ, ພະລັງງານ, ການຕັ້ງຄ່າ, ແລະອື່ນໆ. ຄວາມແຕກຕ່າງພຽງແຕ່ລະຫວ່າງພວກເຂົາແມ່ນວ່າຫົວໄດ້ຮັບການຈະລາຈອນຂອງຜູ້ໃຊ້, ໃນຂະນະທີ່ຫາງບໍ່ເຄີຍໄດ້ຮັບການຈະລາຈອນຂອງຜູ້ໃຊ້.

ເປັນຫຍັງອັນນີ້ຈຶ່ງສຳເລັດ?

ເມື່ອພວກເຮົານຳໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຮົາອອກໃໝ່, ພວກເຮົາຕ້ອງການຮັບປະກັນການເປີດຕົວແບບບໍ່ລຽບງ່າຍ, ນັ້ນແມ່ນ, ໂດຍບໍ່ມີຜົນສະທ້ອນທີ່ຈະແຈ້ງສຳລັບຜູ້ໃຊ້. ນີ້ແມ່ນບັນລຸໄດ້ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າການປ່ອຍລວບລວມຕໍ່ໄປໂດຍໃຊ້ Ansible ໄດ້ຖືກມ້ວນອອກໄປຫາຫາງ. ຢູ່ທີ່ນັ້ນ, ຜູ້ທີ່ມີສ່ວນຮ່ວມໃນການປະຕິບັດສາມາດກວດສອບແລະໃຫ້ແນ່ໃຈວ່າທຸກຢ່າງແມ່ນດີ: ຕົວຊີ້ວັດ, ພາກສ່ວນແລະຄໍາຮ້ອງສະຫມັກທັງຫມົດເຮັດວຽກ; scripts ທີ່ຈໍາເປັນໄດ້ຖືກເປີດຕົວ. ພຽງແຕ່ຫຼັງຈາກທີ່ພວກເຂົາຫມັ້ນໃຈວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ການຈະລາຈອນໄດ້ປ່ຽນໄປ. ມັນເລີ່ມຕົ້ນໄປຫາເຄື່ອງແມ່ຂ່າຍທີ່ເຄີຍເປັນຫາງ. ແລະອັນທີ່ເຄີຍເປັນຫົວຫນ້າຍັງຄົງຢູ່ໂດຍບໍ່ມີການຈະລາຈອນຂອງຜູ້ໃຊ້, ໃນຂະນະທີ່ຍັງມີເວີຊັນກ່ອນຫນ້າຂອງແອັບພລິເຄຊັນຂອງພວກເຮົາຢູ່ໃນມັນ.

ສະນັ້ນມັນແມ່ນ seamless ສໍາລັບຜູ້ໃຊ້. ເນື່ອງຈາກວ່າການສະຫຼັບແມ່ນທັນທີທັນໃດ, ເນື່ອງຈາກວ່າມັນແມ່ນພຽງແຕ່ສະຫຼັບ balancer. ທ່ານສາມາດມ້ວນກັບຄືນໄປຫາສະບັບທີ່ຜ່ານມາໄດ້ຢ່າງງ່າຍດາຍຫຼາຍໂດຍການປ່ຽນຕົວດຸ່ນດ່ຽງກັບຄືນໄປບ່ອນ. ພວກເຮົາຍັງສາມາດກວດສອບໄດ້ວ່າແອັບພລິເຄຊັນສາມາດຜະລິດໄດ້ເຖິງແມ່ນວ່າກ່ອນທີ່ຈະໄດ້ຮັບການຈະລາຈອນຂອງຜູ້ໃຊ້, ເຊິ່ງຂ້ອນຂ້າງສະດວກ.

ພວກເຮົາເຫັນຂໍ້ດີອັນໃດໃນສິ່ງທັງໝົດນີ້?

1. ຫນ້າທໍາອິດຂອງການທັງຫມົດ, ມັນພຽງພໍ ມັນພຽງແຕ່ເຮັດວຽກ. ທຸກຄົນເຂົ້າໃຈວິທີການປະຕິບັດໂຄງການດັ່ງກ່າວເຮັດວຽກ, ເພາະວ່າປະຊາຊົນສ່ວນໃຫຍ່ເຄີຍນໍາໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍ virtual ປົກກະຕິ.
2. ນີ້ແມ່ນພຽງພໍ ເຊື່ອຖືໄດ້, ເນື່ອງຈາກວ່າເຕັກໂນໂລຊີການນໍາໃຊ້ແມ່ນງ່າຍດາຍ, ການທົດສອບໂດຍຫລາຍພັນບໍລິສັດ. ເຊີບເວີນັບລ້ານຖືກນຳໃຊ້ດ້ວຍວິທີນີ້. ມັນເປັນການຍາກທີ່ຈະທໍາລາຍບາງສິ່ງບາງຢ່າງ.
3. ແລະສຸດທ້າຍພວກເຮົາສາມາດໄດ້ຮັບ ການ​ນຳ​ໃຊ້​ນິວ​ເຄຼຍ. ການນຳໃຊ້ທີ່ເກີດຂື້ນພ້ອມໆກັນສຳລັບຜູ້ໃຊ້, ໂດຍບໍ່ມີຂັ້ນຕອນທີ່ຈະແຈ້ງຂອງການປ່ຽນລະຫວ່າງລຸ້ນເກົ່າ ແລະ ຮຸ່ນໃໝ່.

ແຕ່ພວກເຮົາຍັງເຫັນຂໍ້ບົກຜ່ອງຫຼາຍຢ່າງໃນສິ່ງທັງຫມົດນີ້:

1. ນອກ​ຈາກ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ຜະ​ລິດ, ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ພັດ​ທະ​ນາ, ຍັງ​ມີ​ສະ​ພາບ​ແວດ​ລ້ອມ​ອື່ນໆ. ຕົວຢ່າງ, qa ແລະ preproduction. ໃນເວລານັ້ນພວກເຮົາມີເຄື່ອງແມ່ຂ່າຍຫຼາຍແລະປະມານ 60 ບໍລິການ. ສໍາລັບເຫດຜົນນີ້, ມັນເປັນສິ່ງຈໍາເປັນ ສໍາລັບແຕ່ລະບໍລິການ, ຮັກສາສະບັບຫລ້າສຸດສໍາລັບມັນ ເຄື່ອງ virtual. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າທ່ານຕ້ອງການປັບປຸງຫ້ອງສະຫມຸດຫຼືຕິດຕັ້ງການເພິ່ງພາອາໄສໃຫມ່, ທ່ານຈໍາເປັນຕ້ອງເຮັດສິ່ງນີ້ໃນທຸກສະພາບແວດລ້ອມ. ນອກນັ້ນທ່ານຍັງຈໍາເປັນຕ້ອງໄດ້ synchronize ເວລາທີ່ທ່ານກໍາລັງຈະນໍາໃຊ້ເວີຊັນໃຫມ່ຂອງແອັບພລິເຄຊັນຂອງທ່ານກັບເວລາທີ່ devops ປະຕິບັດການຕັ້ງຄ່າສະພາບແວດລ້ອມທີ່ຈໍາເປັນ. ໃນກໍລະນີນີ້, ມັນງ່າຍທີ່ຈະເຂົ້າໄປໃນສະຖານະການທີ່ສະພາບແວດລ້ອມຂອງພວກເຮົາຈະແຕກຕ່າງກັນບາງຢ່າງໃນທຸກສະພາບແວດລ້ອມໃນເວລາດຽວກັນ. ຕົວຢ່າງ, ໃນສະພາບແວດລ້ອມ QA ຈະມີບາງສະບັບຂອງຫ້ອງສະຫມຸດ, ແລະໃນສະພາບແວດລ້ອມການຜະລິດຈະມີທີ່ແຕກຕ່າງກັນ, ເຊິ່ງຈະນໍາໄປສູ່ບັນຫາ.
2. ຄວາມຫຍຸ້ງຍາກໃນການປັບປຸງການຂຶ້ນກັບ ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​. ມັນບໍ່ໄດ້ຂຶ້ນກັບທ່ານ, ແຕ່ຢູ່ໃນທີມງານອື່ນໆ. ຄື, ຈາກທີມງານ devops ທີ່ຮັກສາເຄື່ອງແມ່ຂ່າຍ. ເຈົ້າຕ້ອງມອບວຽກທີ່ເໝາະສົມໃຫ້ເຂົາເຈົ້າ ແລະລາຍລະອຽດກ່ຽວກັບສິ່ງທີ່ເຈົ້າຢາກເຮັດ.
3. ໃນ​ເວ​ລາ​ນັ້ນ, ພວກ​ເຮົາ​ຍັງ​ຕ້ອງ​ການ​ທີ່​ຈະ​ແບ່ງ monoliths ຂະ​ຫນາດ​ໃຫຍ່​ຂະ​ຫນາດ​ໃຫຍ່​ທີ່​ພວກ​ເຮົາ​ມີ​ອອກ​ເປັນ​ການ​ບໍ​ລິ​ການ​ຂະ​ຫນາດ​ນ້ອຍ​ແຍກ​ຕ່າງ​ຫາກ, ເນື່ອງ​ຈາກ​ວ່າ​ພວກ​ເຮົາ​ເຂົ້າ​ໃຈ​ວ່າ​ຈະ​ມີ​ຫຼາຍ​ຂຶ້ນ. ໃນເວລານັ້ນ, ພວກເຮົາມີຫຼາຍກວ່າ 100 ຂອງພວກເຂົາແລ້ວ, ສໍາລັບແຕ່ລະບໍລິການໃຫມ່, ມັນຈໍາເປັນຕ້ອງສ້າງເຄື່ອງ virtual ໃຫມ່ແຍກຕ່າງຫາກ, ເຊິ່ງຈໍາເປັນຕ້ອງໄດ້ຮັກສາແລະນໍາໃຊ້. ນອກຈາກນັ້ນ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງລົດຫນຶ່ງ, ແຕ່ຢ່າງຫນ້ອຍສອງ. ເພີ່ມໃສ່ທັງຫມົດນີ້ແມ່ນສະພາບແວດລ້ອມ QA. ນີ້ເຮັດໃຫ້ເກີດບັນຫາແລະເຮັດໃຫ້ມັນຍາກຫຼາຍສໍາລັບທ່ານທີ່ຈະສ້າງແລະດໍາເນີນການລະບົບໃຫມ່. ຂະບວນການທີ່ສັບສົນ, ລາຄາແພງແລະຍາວ.

ດັ່ງນັ້ນ, ພວກເຮົາຈຶ່ງຕັດສິນໃຈວ່າມັນຈະສະດວກກວ່າທີ່ຈະຍ້າຍຈາກການໃຊ້ເຄື່ອງ virtual ປົກກະຕິໄປສູ່ການໃຊ້ງານຂອງພວກເຮົາໃນ docker container. ຖ້າທ່ານມີ docker, ທ່ານຕ້ອງການລະບົບທີ່ສາມາດດໍາເນີນການຄໍາຮ້ອງສະຫມັກໃນກຸ່ມ, ເພາະວ່າທ່ານບໍ່ສາມາດພຽງແຕ່ຍົກພາຊະນະ. ປົກກະຕິແລ້ວທ່ານຕ້ອງການຕິດຕາມວິທີການຍົກຕູ້ຄອນເທນເນີຫຼາຍປານໃດເພື່ອໃຫ້ພວກມັນຍົກອັດຕະໂນມັດ. ສໍາລັບເຫດຜົນນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງເລືອກລະບົບການຄວບຄຸມ.

ພວກ​ເຮົາ​ໄດ້​ຄິດ​ເປັນ​ເວ​ລາ​ດົນ​ນານ​ກ່ຽວ​ກັບ​ການ​ທີ່​ພວກ​ເຮົາ​ສາ​ມາດ​ເອົາ​. ຄວາມຈິງແລ້ວແມ່ນວ່າໃນເວລານັ້ນ stack ການຕິດຕັ້ງນີ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ virtual ປົກກະຕິແມ່ນຂ້ອນຂ້າງລ້າສະໄຫມ, ເນື່ອງຈາກວ່າພວກເຂົາເຈົ້າບໍ່ມີສະບັບຫລ້າສຸດຂອງລະບົບປະຕິບັດການ. ໃນບາງຈຸດ, ມີແມ້ກະທັ້ງ FreeBSD, ເຊິ່ງບໍ່ສະດວກຫຼາຍທີ່ຈະສະຫນັບສະຫນູນ. ພວກເຮົາເຂົ້າໃຈວ່າພວກເຮົາຈໍາເປັນຕ້ອງຍ້າຍໄປ docker ໄວເທົ່າທີ່ຈະໄວໄດ້. devops ຂອງພວກເຮົາເບິ່ງປະສົບການທີ່ມີຢູ່ແລ້ວຂອງເຂົາເຈົ້າກັບວິທີແກ້ໄຂທີ່ແຕກຕ່າງກັນແລະເລືອກລະບົບເຊັ່ນ Nomad.

ປ່ຽນເປັນ Nomad

Nomad ແມ່ນຜະລິດຕະພັນຂອງບໍລິສັດ HashiCorp. ພວກເຂົາເຈົ້າຍັງເປັນທີ່ຮູ້ຈັກສໍາລັບວິທີແກ້ໄຂອື່ນໆຂອງເຂົາເຈົ້າ:

"ກົງສຸນ" ເປັນເຄື່ອງມືສໍາລັບການຄົ້ນພົບການບໍລິການ.

"ພື້ນທີ່" - ລະບົບສໍາລັບການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດ configure ໃຫ້ເຂົາເຈົ້າໂດຍຜ່ານການຕັ້ງຄ່າ, ອັນທີ່ເອີ້ນວ່າໂຄງສ້າງພື້ນຖານ -as-a-code.

"Vagrant" ອະນຸຍາດໃຫ້ທ່ານນໍາໃຊ້ເຄື່ອງ virtual ຢູ່ໃນທ້ອງຖິ່ນຫຼືຢູ່ໃນຄລາວໂດຍຜ່ານໄຟລ໌ການຕັ້ງຄ່າສະເພາະ.

Nomad ໃນ​ເວ​ລາ​ນັ້ນ​ເບິ່ງ​ຄື​ວ່າ​ເປັນ​ການ​ແກ້​ໄຂ​ທີ່​ງ່າຍ​ດາຍ​ທີ່​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ສະ​ຫຼັບ​ຢ່າງ​ວ່ອງ​ໄວ​ໂດຍ​ບໍ່​ມີ​ການ​ປ່ຽນ​ແປງ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​ທັງ​ຫມົດ​. ນອກຈາກນັ້ນ, ມັນແມ່ນຂ້ອນຂ້າງງ່າຍທີ່ຈະຮຽນຮູ້. ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາເລືອກມັນເປັນລະບົບການກັ່ນຕອງສໍາລັບຖັງຂອງພວກເຮົາ.

ເຈົ້າຕ້ອງການຫຍັງເພື່ອນຳໃຊ້ລະບົບຂອງເຈົ້າໃຫ້ກັບ Nomad?

1. ກ່ອນອື່ນ ໝົດ, ທ່ານຕ້ອງການ ຮູບພາບ docker ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​. ທ່ານຈໍາເປັນຕ້ອງສ້າງມັນແລະວາງໄວ້ໃນບ່ອນເກັບຮູບພາບ docker. ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນເຄື່ອງປະດິດ - ລະບົບທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຍູ້ສິ່ງປະດິດຂອງປະເພດຕ່າງໆເຂົ້າໄປໃນມັນ. ມັນ​ສາ​ມາດ​ເກັບ​ຮັກ​ສາ​ຮວບ​ຮວມ​, ຮູບ​ພາບ docker​, ການ​ຫຸ້ມ​ຫໍ່ PHP composer​, ການ​ຫຸ້ມ​ຫໍ່ NPM​, ແລະ​ອື່ນໆ​.
2. ຍັງຕ້ອງການ ໄຟລ໌ການຕັ້ງຄ່າ, ເຊິ່ງຈະບອກ Nomad ແມ່ນຫຍັງ, ຢູ່ໃສແລະໃນປະລິມານໃດທີ່ທ່ານຕ້ອງການນໍາໄປໃຊ້.

ເມື່ອພວກເຮົາເວົ້າກ່ຽວກັບ Nomad, ມັນໃຊ້ພາສາ HCL ເປັນຮູບແບບເອກະສານຂໍ້ມູນຂອງມັນ, ເຊິ່ງຫມາຍເຖິງ ພາສາການຕັ້ງຄ່າ HashiCorp. ນີ້ແມ່ນ superset ຂອງ Yaml ທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດອະທິບາຍການບໍລິການຂອງທ່ານໃນຂໍ້ກໍານົດ Nomad.

ມັນອະນຸຍາດໃຫ້ທ່ານເວົ້າວ່າຈໍານວນບັນຈຸທີ່ທ່ານຕ້ອງການທີ່ຈະນໍາໄປໃຊ້, ຈາກຮູບພາບທີ່ຈະຜ່ານຕົວກໍານົດການຕ່າງໆໃຫ້ເຂົາເຈົ້າໃນລະຫວ່າງການປະຕິບັດ. ດັ່ງນັ້ນ, ທ່ານໃຫ້ອາຫານໄຟລ໌ນີ້ໃຫ້ກັບ Nomad, ແລະມັນເປີດຕົວບັນຈຸເຂົ້າໃນການຜະລິດຕາມມັນ.

ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາຮັບຮູ້ວ່າພຽງແຕ່ການຂຽນໄຟລ໌ HCL ຄືກັນຢ່າງແທ້ຈິງສໍາລັບແຕ່ລະບໍລິການຈະບໍ່ສະດວກຫຼາຍ, ເພາະວ່າມີການບໍລິການຫຼາຍຢ່າງແລະບາງຄັ້ງທ່ານຕ້ອງການປັບປຸງພວກມັນ. ມັນເກີດຂື້ນວ່າການບໍລິການຫນຶ່ງຖືກນໍາໄປໃຊ້ບໍ່ແມ່ນຢູ່ໃນຕົວຢ່າງຫນຶ່ງ, ແຕ່ໃນຫຼາຍໆອັນທີ່ແຕກຕ່າງກັນ. ຕົວຢ່າງ, ຫນຶ່ງໃນລະບົບທີ່ພວກເຮົາມີຢູ່ໃນການຜະລິດມີຫຼາຍກວ່າ 100 ຕົວຢ່າງໃນການຜະລິດ. ພວກມັນດໍາເນີນການຈາກຮູບພາບດຽວກັນ, ແຕ່ແຕກຕ່າງກັນໃນການຕັ້ງຄ່າການຕັ້ງຄ່າແລະໄຟລ໌ການຕັ້ງຄ່າ.

ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈວ່າມັນຈະສະດວກສໍາລັບພວກເຮົາທີ່ຈະເກັບຮັກສາໄຟລ໌ການຕັ້ງຄ່າຂອງພວກເຮົາທັງຫມົດສໍາລັບການນໍາໃຊ້ໃນ repository ທົ່ວໄປ. ດ້ວຍວິທີນີ້ພວກເຂົາເຫັນໄດ້ວ່າ: ພວກມັນງ່າຍຕໍ່ການຮັກສາແລະພວກເຮົາສາມາດເຫັນໄດ້ວ່າພວກເຮົາມີລະບົບໃດ. ຖ້າຈໍາເປັນ, ມັນຍັງງ່າຍຕໍ່ການປັບປຸງຫຼືປ່ຽນແປງບາງສິ່ງບາງຢ່າງ. ການເພີ່ມລະບົບໃຫມ່ກໍ່ບໍ່ແມ່ນເລື່ອງຍາກ - ທ່ານພຽງແຕ່ຕ້ອງການສ້າງໄຟລ໌ການຕັ້ງຄ່າພາຍໃນໄດເລກະທໍລີໃຫມ່. ພາຍໃນມັນມີໄຟລ໌ຕໍ່ໄປນີ້: service.hcl, ເຊິ່ງປະກອບດ້ວຍຄໍາອະທິບາຍກ່ຽວກັບການບໍລິການຂອງພວກເຮົາ, ແລະບາງໄຟລ໌ env ທີ່ອະນຸຍາດໃຫ້ບໍລິການນີ້, ຖືກນໍາໄປໃຊ້ໃນການຜະລິດ, ຈະຖືກຕັ້ງຄ່າ.

ຢ່າງໃດກໍຕາມ, ບາງລະບົບຂອງພວກເຮົາຖືກນໍາໄປໃຊ້ໃນການຜະລິດບໍ່ແມ່ນໃນຫນຶ່ງສໍາເນົາ, ແຕ່ໃນຫຼາຍໆຄັ້ງໃນເວລາດຽວກັນ. ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈວ່າມັນຈະເປັນການສະດວກສໍາລັບພວກເຮົາທີ່ຈະເກັບຮັກສາບໍ່ແມ່ນ configs ໃນຮູບແບບທີ່ບໍລິສຸດຂອງເຂົາເຈົ້າ, ແຕ່ຮູບແບບ templated ຂອງເຂົາເຈົ້າ. ແລະພວກເຮົາເລືອກ ຈິນຈາ 2. ໃນຮູບແບບນີ້, ພວກເຮົາເກັບຮັກສາທັງ configs ຂອງການບໍລິການຕົວມັນເອງແລະໄຟລ໌ env ທີ່ຈໍາເປັນສໍາລັບມັນ.

ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ວາງໄວ້ໃນ repository script deployment ທົ່ວໄປກັບໂຄງການທັງຫມົດ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເປີດຕົວແລະນໍາໃຊ້ການບໍລິການຂອງທ່ານໃນການຜະລິດ, ເຂົ້າໄປໃນສະພາບແວດລ້ອມທີ່ຕ້ອງການ, ເຂົ້າໄປໃນເປົ້າຫມາຍທີ່ຕ້ອງການ. ໃນກໍລະນີທີ່ພວກເຮົາຫັນ HCL config ຂອງພວກເຮົາເຂົ້າໄປໃນແມ່ແບບ, ຫຼັງຈາກນັ້ນໄຟລ໌ HCL, ເຊິ່ງກ່ອນຫນ້າຈະເປັນ Nomad config ປົກກະຕິ, ໃນກໍລະນີນີ້ເລີ່ມມີຄວາມແຕກຕ່າງເລັກນ້ອຍ.

ນັ້ນແມ່ນ, ພວກເຮົາໄດ້ປ່ຽນບາງຕົວແປທີ່ຕັ້ງ config ດ້ວຍຕົວແປທີ່ເອົາມາຈາກໄຟລ໌ env ຫຼືແຫຼ່ງອື່ນໆ. ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ຮັບໂອກາດທີ່ຈະເກັບກໍາໄຟລ໌ HCL ແບບໄດນາມິກ, ນັ້ນແມ່ນ, ພວກເຮົາສາມາດນໍາໃຊ້ບໍ່ພຽງແຕ່ການແຊກຕົວແປທໍາມະດາ. ເນື່ອງຈາກ jinja ສະຫນັບສະຫນູນ loops ແລະເງື່ອນໄຂ, ທ່ານຍັງສາມາດສ້າງໄຟລ໌ການຕັ້ງຄ່າຢູ່ທີ່ນັ້ນ, ເຊິ່ງມີການປ່ຽນແປງຂຶ້ນຢູ່ກັບບ່ອນທີ່ທ່ານນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຂອງທ່ານ.

ຕົວຢ່າງ, ທ່ານຕ້ອງການໃຊ້ການບໍລິການຂອງເຈົ້າໄປສູ່ການຜະລິດກ່ອນການຜະລິດແລະການຜະລິດ. ໃຫ້ສົມມຸດວ່າໃນການຜະລິດກ່ອນ, ທ່ານບໍ່ຕ້ອງການໃຊ້ cron script, ແຕ່ພຽງແຕ່ຕ້ອງການເບິ່ງການບໍລິການຢູ່ໃນໂດເມນແຍກຕ່າງຫາກເພື່ອໃຫ້ແນ່ໃຈວ່າມັນເຮັດວຽກ. ສໍາລັບໃຜທີ່ນໍາໃຊ້ການບໍລິການ, ຂະບວນການເບິ່ງງ່າຍດາຍຫຼາຍແລະໂປ່ງໃສ. ສິ່ງທີ່ທ່ານຕ້ອງເຮັດຄືການດຳເນີນການໄຟລ໌ deploy.sh, ລະບຸວ່າທ່ານຕ້ອງການນຳໃຊ້ບໍລິການໃດ ແລະໄປທີ່ເປົ້າໝາຍໃດ. ຕົວຢ່າງ, ທ່ານຕ້ອງການໃຊ້ລະບົບສະເພາະກັບລັດເຊຍ, ເບລາຣູດ ຫຼື ຄາຊັກສະຖານ. ເພື່ອເຮັດສິ່ງນີ້, ພຽງແຕ່ປ່ຽນຫນຶ່ງຂອງຕົວກໍານົດການ, ແລະທ່ານຈະມີໄຟລ໌ການຕັ້ງຄ່າທີ່ຖືກຕ້ອງ.

ເມື່ອບໍລິການ Nomad ຖືກນຳໃຊ້ກັບກຸ່ມຂອງທ່ານແລ້ວ, ມັນເບິ່ງຄືວ່ານີ້.

ຫນ້າທໍາອິດ, ທ່ານຕ້ອງການບາງປະເພດຂອງການດຸ່ນດ່ຽງພາຍນອກ, ເຊິ່ງຈະໄດ້ຮັບການເຂົ້າຊົມຜູ້ໃຊ້ທັງຫມົດ. ມັນຈະເຮັດວຽກຮ່ວມກັນກັບກົງສຸນແລະຊອກຫາຈາກມັນບ່ອນທີ່, ຢູ່ໃນຈຸດໃດ, ທີ່ຢູ່ IP ທີ່ບໍລິການສະເພາະໃດຫນຶ່ງແມ່ນຕັ້ງຢູ່ທີ່ກົງກັບຊື່ໂດເມນໂດຍສະເພາະ. ການບໍລິການໃນກົງສຸນແມ່ນມາຈາກ Nomad ເອງ. ເນື່ອງຈາກວ່າເຫຼົ່ານີ້ແມ່ນຜະລິດຕະພັນຈາກບໍລິສັດດຽວກັນ, ພວກມັນຂ້ອນຂ້າງກ່ຽວຂ້ອງກັບກັນແລະກັນ. ພວກເຮົາສາມາດເວົ້າໄດ້ວ່າ Nomad ອອກຈາກກ່ອງສາມາດລົງທະບຽນບໍລິການທັງຫມົດທີ່ເປີດຕົວຢູ່ໃນ Consul.

ເມື່ອຕົວດຸ່ນດ່ຽງການໂຫຼດທາງຫນ້າຂອງທ່ານຮູ້ວ່າບໍລິການໃດທີ່ຈະສົ່ງການຈະລາຈອນໄປຫາ, ມັນສົ່ງຕໍ່ໄປຫາຖັງທີ່ເຫມາະສົມຫຼືຫຼາຍບັນຈຸທີ່ກົງກັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານ. ຕາມທໍາມະຊາດ, ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະຄິດກ່ຽວກັບຄວາມປອດໄພ. ເຖິງແມ່ນວ່າການບໍລິການທັງຫມົດດໍາເນີນການຢູ່ໃນເຄື່ອງ virtual ດຽວກັນໃນບັນຈຸ, ນີ້ປົກກະຕິແລ້ວຮຽກຮ້ອງໃຫ້ມີການປ້ອງກັນການເຂົ້າເຖິງຟຣີຈາກການບໍລິການອື່ນໆ. ພວກເຮົາບັນລຸໄດ້ນີ້ໂດຍຜ່ານການແບ່ງສ່ວນ. ແຕ່ລະບໍລິການຖືກເປີດຕົວໃນເຄືອຂ່າຍສະເໝືອນຂອງຕົນເອງ, ເຊິ່ງກຳນົດເສັ້ນທາງ ແລະກົດລະບຽບການອະນຸຍາດ/ປະຕິເສດການເຂົ້າເຖິງລະບົບ ແລະການບໍລິການອື່ນໆ. ພວກມັນສາມາດຕັ້ງຢູ່ທັງພາຍໃນກຸ່ມນີ້ ແລະນອກມັນ. ຕົວຢ່າງ: ຖ້າທ່ານຕ້ອງການປ້ອງກັນບໍ່ໃຫ້ການບໍລິການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນສະເພາະ, ນີ້ສາມາດເຮັດໄດ້ໂດຍຜ່ານການແບ່ງສ່ວນລະດັບເຄືອຂ່າຍ. ນັ້ນແມ່ນ, ເຖິງແມ່ນວ່າໂດຍຄວາມຜິດພາດ, ທ່ານບໍ່ສາມາດເຊື່ອມຕໍ່ໂດຍບັງເອີນຈາກສະພາບແວດລ້ອມການທົດສອບກັບຖານຂໍ້ມູນການຜະລິດຂອງທ່ານ.

ການຫັນປ່ຽນເຮັດໃຫ້ພວກເຮົາມີຄ່າໃຊ້ຈ່າຍຫຼາຍປານໃດໃນດ້ານຊັບພະຍາກອນມະນຸດ?

ການຫັນປ່ຽນຂອງບໍລິສັດທັງຫມົດໄປຫາ Nomad ໃຊ້ເວລາປະມານ 5-6 ເດືອນ. ພວກ​ເຮົາ​ໄດ້​ເຄື່ອນ​ຍ້າຍ​ບົນ​ພື້ນ​ຖານ​ການ​ບໍ​ລິ​ການ​ໂດຍ​ການ​ບໍ​ລິ​ການ, ແຕ່​ໃນ​ຈັງ​ຫວະ​ໄວ​ພໍ​ສົມ​ຄວນ. ແຕ່ລະທີມຕ້ອງໄດ້ສ້າງຕູ້ບັນຈຸຂອງຕົນເອງເພື່ອການບໍລິການ.

ພວກເຮົາໄດ້ຮັບຮອງເອົາວິທີການດັ່ງກ່າວທີ່ແຕ່ລະທີມງານຮັບຜິດຊອບສໍາລັບຮູບພາບ docker ຂອງລະບົບຂອງເຂົາເຈົ້າເປັນເອກະລາດ. DevOps ສະຫນອງໂຄງສ້າງພື້ນຖານທົ່ວໄປທີ່ຈໍາເປັນສໍາລັບການນໍາໃຊ້, ນັ້ນແມ່ນ, ການສະຫນັບສະຫນູນສໍາລັບກຸ່ມຕົວມັນເອງ, ການສະຫນັບສະຫນູນລະບົບ CI, ແລະອື່ນໆ. ແລະໃນເວລານັ້ນ, ພວກເຮົາມີຫຼາຍກວ່າ 60 ລະບົບໄດ້ຍ້າຍໄປ Nomad, ເຊິ່ງມີປະມານ 2 ພັນຕູ້ຄອນເທນເນີ.

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

ເຫດຜົນສໍາລັບການປະຖິ້ມ Nomad

ພວກເຮົາໄດ້ຮັບຂໍ້ດີຫຍັງຈາກການປ່ຽນໄປໃຊ້ໃນການນໍາໃຊ້ Nomad ແລະ docker, ແລະອື່ນໆ?

1. ພວກ​ເຮົາ ສະ​ຫນອງ​ເງື່ອນ​ໄຂ​ສະ​ເຫມີ​ພາບ​ ສໍາລັບສະພາບແວດລ້ອມທັງຫມົດ. ໃນການພັດທະນາ, ສະພາບແວດລ້ອມ QA, ທາງສ່ວນຫນ້າຂອງການຜະລິດ, ການຜະລິດ, ຮູບພາບບັນຈຸດຽວກັນຖືກນໍາໃຊ້, ມີການຂຶ້ນກັບດຽວກັນ. ຕາມນັ້ນແລ້ວ, ທ່ານເກືອບບໍ່ມີໂອກາດທີ່ສິ່ງທີ່ຈະສິ້ນສຸດໃນການຜະລິດບໍ່ແມ່ນສິ່ງທີ່ທ່ານເຄີຍທົດສອບຢູ່ໃນທ້ອງຖິ່ນຫຼືໃນສະພາບແວດລ້ອມການທົດສອບຂອງທ່ານ.
2. ພວກເຮົາຍັງພົບວ່າມັນພຽງພໍ ງ່າຍທີ່ຈະເພີ່ມການບໍລິການໃຫມ່. ຈາກທັດສະນະຂອງການນໍາໃຊ້, ລະບົບໃຫມ່ໃດກໍ່ຖືກເປີດຕົວຢ່າງງ່າຍດາຍ. ພຽງແຕ່ໄປທີ່ repository ທີ່ເກັບຮັກສາ config, ເພີ່ມ config ອື່ນສໍາລັບລະບົບຂອງທ່ານຢູ່ທີ່ນັ້ນ, ແລະທ່ານພ້ອມແລ້ວ. ທ່ານສາມາດ ນຳ ໃຊ້ລະບົບຂອງທ່ານໄປສູ່ການຜະລິດໄດ້ໂດຍບໍ່ຕ້ອງພະຍາຍາມເພີ່ມເຕີມຈາກ devops.
3. ທັງຫມົດ ໄຟລ​໌​ການ​ຕັ້ງ​ຄ່າ​ ໃນ​ຫນຶ່ງ repository ທົ່ວ​ໄປ​ ໄດ້​ກາຍ​ເປັນ​ຢູ່​ພາຍ​ໃຕ້​ການ​ທົບ​ທວນ​ຄືນ​. ໃນເວລາທີ່ພວກເຮົານໍາໃຊ້ລະບົບຂອງພວກເຮົາໂດຍໃຊ້ເຄື່ອງແມ່ຂ່າຍ virtual, ພວກເຮົາໄດ້ໃຊ້ Ansible, ເຊິ່ງ configs ຢູ່ໃນບ່ອນເກັບມ້ຽນດຽວກັນ. ຢ່າງໃດກໍຕາມ, ສໍາລັບນັກພັດທະນາສ່ວນໃຫຍ່, ນີ້ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະເຮັດວຽກຮ່ວມກັບ. ທີ່ນີ້, ປະລິມານຂອງ configs ແລະລະຫັດທີ່ທ່ານຈໍາເປັນຕ້ອງໄດ້ເພີ່ມເພື່ອນໍາໃຊ້ການບໍລິການໄດ້ກາຍເປັນຂະຫນາດນ້ອຍຫຼາຍ. ນອກຈາກນັ້ນ, ມັນງ່າຍຫຼາຍສໍາລັບ devops ເພື່ອແກ້ໄຂຫຼືປ່ຽນມັນ. ໃນກໍລະນີຂອງການຫັນປ່ຽນ, ສໍາລັບການຍົກຕົວຢ່າງ, ໄປຫາສະບັບໃຫມ່ຂອງ Nomad, ພວກເຂົາສາມາດເອົາແລະປັບປຸງໄຟລ໌ປະຕິບັດງານທັງຫມົດທີ່ຢູ່ໃນສະຖານທີ່ດຽວກັນ.

ແຕ່ພວກເຮົາຍັງພົບຂໍ້ເສຍຫຼາຍຢ່າງ:

ມັນໄດ້ຫັນອອກວ່າພວກເຮົາ ບໍ່​ສາ​ມາດ​ບັນ​ລຸ​ການ​ປະ​ຕິ​ບັດ​ຢ່າງ​ບໍ່​ຢຸດ​ຢັ້ງ ໃນກໍລະນີຂອງ Nomad. ໃນເວລາທີ່ມ້ວນຕູ້ຄອນເທນເນີພາຍໃຕ້ເງື່ອນໄຂທີ່ແຕກຕ່າງກັນ, ມັນສາມາດກາຍເປັນການແລ່ນ, ແລະ Nomad ເຂົ້າໃຈວ່າມັນເປັນຕູ້ຄອນເທນເນີທີ່ພ້ອມທີ່ຈະຮັບການຈະລາຈອນ. ນີ້ເກີດຂຶ້ນກ່ອນທີ່ແອັບພລິເຄຊັນພາຍໃນມັນມີໂອກາດທີ່ຈະເປີດຕົວ. ສໍາລັບເຫດຜົນນີ້, ລະບົບໄດ້ເລີ່ມຕົ້ນທີ່ຈະຜະລິດ 500 ຂໍ້ຜິດພາດໃນໄລຍະເວລາສັ້ນໆ, ເນື່ອງຈາກວ່າການຈະລາຈອນເລີ່ມຕົ້ນໄປສູ່ຕູ້ຄອນເທນເນີທີ່ຍັງບໍ່ທັນພ້ອມທີ່ຈະຍອມຮັບ.

ພວກເຮົາພົບບາງ ໂດຍ bogs ໄດ້. ຂໍ້ບົກພ່ອງທີ່ ສຳ ຄັນທີ່ສຸດແມ່ນວ່າ Nomad ບໍ່ໄດ້ຈັດການກຸ່ມໃຫຍ່ໄດ້ດີຖ້າທ່ານມີລະບົບແລະບັນຈຸຫຼາຍ. ເມື່ອທ່ານຕ້ອງການເອົາຫນຶ່ງໃນເຄື່ອງແມ່ຂ່າຍທີ່ລວມຢູ່ໃນກຸ່ມ Nomad ສໍາລັບການບໍາລຸງຮັກສາ, ມີຄວາມເປັນໄປໄດ້ສູງພໍສົມຄວນທີ່ cluster ຈະບໍ່ມີຄວາມຮູ້ສຶກດີຫຼາຍແລະຈະແຕກແຍກ. ຕົວຢ່າງ, ບາງຕູ້ຄອນເທນເນີອາດຈະຫຼຸດລົງແລະບໍ່ລຸກຂຶ້ນ - ນີ້ຈະເຮັດໃຫ້ເຈົ້າເສຍຄ່າໃຊ້ຈ່າຍຫຼາຍຕໍ່ມາຖ້າລະບົບການຜະລິດທັງຫມົດຂອງເຈົ້າຢູ່ໃນກຸ່ມທີ່ຄຸ້ມຄອງໂດຍ Nomad.

ດັ່ງ​ນັ້ນ​ພວກ​ເຮົາ​ໄດ້​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ຄິດ​ວ່າ​ບ່ອນ​ທີ່​ພວກ​ເຮົາ​ຄວນ​ຈະ​ໄປ​ຕໍ່​ໄປ. ​ໃນ​ຈຸດ​ເວລາ​ນັ້ນ, ​ເຮົາ​ຮູ້​ຫຼາຍ​ຂຶ້ນ​ກ່ຽວ​ກັບ​ສິ່ງ​ທີ່​ເຮົາ​ຢາກ​ບັນລຸ. ຄື: ພວກເຮົາຕ້ອງການຄວາມຫນ້າເຊື່ອຖື, ຫນ້າທີ່ຫຼາຍກ່ວາທີ່ Nomad ສະຫນອງ, ແລະລະບົບທີ່ໃຫຍ່ກວ່າ, ມີຄວາມຫມັ້ນຄົງຫຼາຍ.

ໃນເລື່ອງນີ້, ທາງເລືອກຂອງພວກເຮົາຕົກຢູ່ໃນ Kubernetes ເປັນເວທີທີ່ນິຍົມທີ່ສຸດສໍາລັບການເປີດຕົວກຸ່ມ. ໂດຍ​ສະ​ເພາະ​ແມ່ນ​ວ່າ​ຂະ​ຫນາດ​ແລະ​ຈໍາ​ນວນ​ຂອງ​ພາ​ຊະ​ນະ​ຂອງ​ພວກ​ເຮົາ​ມີ​ຂະ​ຫນາດ​ໃຫຍ່​ພຽງ​ພໍ. ສໍາລັບຈຸດປະສົງດັ່ງກ່າວ, Kubernetes ເບິ່ງຄືວ່າເປັນລະບົບທີ່ເຫມາະສົມທີ່ສຸດທີ່ພວກເຮົາສາມາດເບິ່ງໄດ້.

ການຫັນປ່ຽນໄປສູ່ Kubernetes

ຂ້ອຍຈະບອກເຈົ້າເລັກນ້ອຍກ່ຽວກັບແນວຄວາມຄິດພື້ນຖານຂອງ Kubernetes ແລະວິທີທີ່ພວກມັນແຕກຕ່າງຈາກ Nomad.

ກ່ອນອື່ນ ໝົດ, ແນວຄວາມຄິດພື້ນຖານທີ່ສຸດໃນ Kubernetes ແມ່ນແນວຄວາມຄິດຂອງຝັກ. Pod ແມ່ນກຸ່ມໜຶ່ງ ຫຼືຫຼາຍກວ່າໜຶ່ງຖັງທີ່ແລ່ນນໍາກັນສະເໝີ. ແລະພວກເຂົາສະເຫມີເຮັດວຽກຄືກັບວ່າຢ່າງເຂັ້ມງວດໃນເຄື່ອງ virtual ຫນຶ່ງ. ພວກມັນສາມາດເຂົ້າເຖິງກັນແລະກັນຜ່ານ IP 127.0.0.1 ໃນພອດຕ່າງໆ.

ໃຫ້ສົມມຸດວ່າທ່ານມີຄໍາຮ້ອງສະຫມັກ PHP ທີ່ປະກອບດ້ວຍ nginx ແລະ php-fpm - ແບບຄລາສສິກ. ສ່ວນຫຼາຍອາດຈະ, ທ່ານຈະຕ້ອງການທີ່ຈະຮັກສາທັງ nginx ແລະ php-fpm containers ຮ່ວມກັນຕະຫຼອດເວລາ. Kubernetes ອະນຸຍາດໃຫ້ທ່ານບັນລຸສິ່ງນີ້ໂດຍການອະທິບາຍພວກມັນເປັນຝັກທົ່ວໄປອັນດຽວ. ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາບໍ່ສາມາດໄດ້ຮັບກັບ Nomad.

ແນວຄວາມຄິດທີສອງແມ່ນ deployment. ຄວາມ​ຈິງ​ແລ້ວ​ແມ່ນ​ວ່າ​ຝັກ​ຕົວ​ມັນ​ເອງ​ເປັນ​ສິ່ງ​ທີ່​ບໍ່​ຫລົງ​ທາງ; ມັນ​ເລີ່ມ​ຕົ້ນ​ແລະ​ຫາຍ​ໄປ. ທ່ານ​ຕ້ອງ​ການ​ຂ້າ​ຕູ້​ເກັບ​ຮັກ​ສາ​ທັງ​ຫມົດ​ທີ່​ຜ່ານ​ມາ​ຂອງ​ທ່ານ​ກ່ອນ​, ແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ເປີດ​ການ​ສະ​ບັບ​ໃຫມ່​ໃນ​ເວ​ລາ​ດຽວ​, ຫຼື​ທ່ານ​ຕ້ອງ​ການ​ທີ່​ຈະ​ມ້ວນ​ອອກ​ເທື່ອ​ລະ​ກ້າວ​? ມັນອະທິບາຍວິທີທີ່ທ່ານໃຊ້ຝັກຂອງທ່ານ, ໃນປະລິມານໃດ ແລະວິທີການອັບເດດພວກມັນ.

ແນວຄວາມຄິດທີສາມແມ່ນ ການບໍລິການ. ການບໍລິການຂອງທ່ານແມ່ນຕົວຈິງແລ້ວລະບົບຂອງທ່ານ, ເຊິ່ງໄດ້ຮັບການຈະລາຈອນບາງຢ່າງແລະຫຼັງຈາກນັ້ນສົ່ງຕໍ່ໄປຫາຫນຶ່ງຫຼືຫຼາຍຝັກທີ່ສອດຄ້ອງກັບການບໍລິການຂອງທ່ານ. ນັ້ນແມ່ນ, ມັນອະນຸຍາດໃຫ້ທ່ານເວົ້າວ່າການຈະລາຈອນຂາເຂົ້າທັງຫມົດໄປຫາບໍລິການດັ່ງກ່າວແລະຊື່ດັ່ງກ່າວຕ້ອງຖືກສົ່ງໄປຫາ pods ສະເພາະເຫຼົ່ານີ້. ແລະໃນເວລາດຽວກັນມັນສະຫນອງການດຸ່ນດ່ຽງການຈະລາຈອນ. ນັ້ນແມ່ນ, ທ່ານສາມາດເປີດສອງຝັກຂອງຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ແລະການຈະລາຈອນຂາເຂົ້າທັງຫມົດຈະມີຄວາມສົມດູນເທົ່າທຽມກັນລະຫວ່າງຝັກທີ່ກ່ຽວຂ້ອງກັບການບໍລິການນີ້.

ແລະແນວຄວາມຄິດພື້ນຖານທີ່ສີ່ແມ່ນ Ingress. ນີ້ແມ່ນການບໍລິການທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມ Kubernetes. ມັນເຮັດຫນ້າທີ່ເປັນຕົວດຸ່ນດ່ຽງການໂຫຼດພາຍນອກທີ່ໃຊ້ເວລາຫຼາຍກວ່າການຮ້ອງຂໍທັງຫມົດ. ການນໍາໃຊ້ API Kubernetes, Ingress ສາມາດກໍານົດບ່ອນທີ່ຄໍາຮ້ອງຂໍເຫຼົ່ານີ້ຄວນຈະຖືກສົ່ງ. ຍິ່ງໄປກວ່ານັ້ນ, ລາວເຮັດສິ່ງນີ້ຢ່າງຍືດຫຍຸ່ນ. ທ່ານສາມາດເວົ້າໄດ້ວ່າທຸກຄໍາຮ້ອງຂໍກັບເຈົ້າພາບນີ້ແລະ URL ດັ່ງກ່າວຖືກສົ່ງກັບບໍລິການນີ້. ແລະການຮ້ອງຂໍເຫຼົ່ານີ້ມາຮອດເຈົ້າພາບນີ້ແລະ URL ອື່ນຖືກສົ່ງໄປຫາບໍລິການອື່ນ.

ສິ່ງທີ່ coolest ຈາກທັດສະນະຂອງຜູ້ທີ່ພັດທະນາຄໍາຮ້ອງສະຫມັກແມ່ນທ່ານສາມາດຈັດການມັນທັງຫມົດດ້ວຍຕົນເອງ. ໂດຍການຕັ້ງຄ່າ Ingress config, ທ່ານສາມາດສົ່ງການຈະລາຈອນທັງຫມົດທີ່ມາຮອດດັ່ງກ່າວແລະ API ດັ່ງກ່າວເພື່ອແຍກບັນຈຸທີ່ຂຽນ, ຕົວຢ່າງ, ໃນ Go. ແຕ່ການຈະລາຈອນນີ້, ມາຮອດໂດເມນດຽວກັນ, ແຕ່ໄປຫາ URL ທີ່ແຕກຕ່າງກັນ, ຄວນຈະຖືກສົ່ງໄປຫາຖັງທີ່ຂຽນໃນ PHP, ບ່ອນທີ່ມີເຫດຜົນຫຼາຍ, ແຕ່ພວກມັນບໍ່ໄວຫຼາຍ.

ຖ້າ​ຫາກ​ວ່າ​ພວກ​ເຮົາ​ສົມ​ທຽບ​ແນວ​ຄວາມ​ຄິດ​ທັງ​ຫມົດ​ເຫຼົ່າ​ນີ້​ກັບ Nomad, ພວກ​ເຮົາ​ສາ​ມາດ​ເວົ້າ​ໄດ້​ວ່າ​ສາມ​ແນວ​ຄວາມ​ຄິດ​ທໍາ​ອິດ​ທັງ​ຫມົດ​ຮ່ວມ​ກັນ​ການ​ບໍ​ລິ​ການ. ແລະແນວຄວາມຄິດສຸດທ້າຍແມ່ນບໍ່ມີຢູ່ໃນ Nomad ຕົວຂອງມັນເອງ. ພວກເຮົາໃຊ້ຕົວດຸ່ນດ່ຽງພາຍນອກຍ້ອນວ່າມັນ: ມັນສາມາດເປັນ haproxy, nginx, nginx+, ແລະອື່ນໆ. ໃນກໍລະນີຂອງ cube, ທ່ານບໍ່ຈໍາເປັນຕ້ອງແນະນໍາແນວຄວາມຄິດເພີ່ມເຕີມນີ້ແຍກຕ່າງຫາກ. ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານເບິ່ງ Ingress ພາຍໃນ, ມັນແມ່ນ nginx, haproxy, ຫຼື traefik, ແຕ່ການຈັດລຽງຂອງການກໍ່ສ້າງໃນ Kubernetes.

ແນວຄວາມຄິດທັງຫມົດທີ່ຂ້າພະເຈົ້າໄດ້ອະທິບາຍແມ່ນ, ໃນຄວາມເປັນຈິງ, ຊັບພະຍາກອນທີ່ມີຢູ່ໃນກຸ່ມ Kubernetes. ເພື່ອອະທິບາຍພວກມັນຢູ່ໃນ cube, ຮູບແບບ yaml ຖືກນໍາໃຊ້, ເຊິ່ງສາມາດອ່ານໄດ້ແລະຄຸ້ນເຄີຍກວ່າໄຟລ໌ HCL ໃນກໍລະນີຂອງ Nomad. ແຕ່ໂຄງສ້າງພວກເຂົາອະທິບາຍສິ່ງດຽວກັນໃນກໍລະນີຂອງ, ສໍາລັບການຍົກຕົວຢ່າງ, ຝັກ. ພວກເຂົາເຈົ້າເວົ້າວ່າ - ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະນໍາໃຊ້ຝັກດັ່ງກ່າວແລະດັ່ງກ່າວຢູ່ທີ່ນັ້ນ, ມີຮູບພາບດັ່ງກ່າວແລະດັ່ງກ່າວ, ໃນປະລິມານດັ່ງກ່າວແລະດັ່ງກ່າວ.

ນອກຈາກນັ້ນ, ພວກເຮົາຮັບຮູ້ວ່າພວກເຮົາບໍ່ຕ້ອງການສ້າງຊັບພະຍາກອນແຕ່ລະຄົນດ້ວຍມື: ການຈັດວາງ, ການບໍລິການ, Ingress, ແລະອື່ນໆ. ແທນທີ່ຈະ, ພວກເຮົາຕ້ອງການອະທິບາຍແຕ່ລະລະບົບຂອງພວກເຮົາໃນແງ່ຂອງ Kubernetes ໃນລະຫວ່າງການນຳໃຊ້, ເພື່ອວ່າພວກເຮົາຈະບໍ່ຈຳເປັນຕ້ອງສ້າງຊັບພະຍາກອນທີ່ຈຳເປັນທັງໝົດດ້ວຍຕົນເອງຕາມລຳດັບທີ່ຖືກຕ້ອງ. Helm ຖືກເລືອກເປັນລະບົບທີ່ອະນຸຍາດໃຫ້ພວກເຮົາເຮັດສິ່ງນີ້.

ແນວຄວາມຄິດພື້ນຖານໃນ Helm

Helm ແມ່ນ ຜູ້ຈັດການຊຸດ ສໍາລັບ Kubernetes. ມັນຄ້າຍຄືກັນຫຼາຍກັບວິທີການຜູ້ຈັດການຊຸດໃນພາສາການຂຽນໂປຼແກຼມເຮັດວຽກ. ພວກເຂົາອະນຸຍາດໃຫ້ທ່ານເກັບຮັກສາການບໍລິການທີ່ປະກອບດ້ວຍ, ສໍາລັບການຍົກຕົວຢ່າງ, ການຕິດຕັ້ງ nginx, ການຕິດຕັ້ງ php-fpm, config ສໍາລັບ Ingress, configmaps (ນີ້ແມ່ນຫນ່ວຍງານທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍານົດ env ແລະຕົວກໍານົດການອື່ນໆສໍາລັບລະບົບຂອງທ່ານ) ໃນຮູບແບບຂອງ so- ເອີ້ນວ່າຕາຕະລາງ. ໃນເວລາດຽວກັນ Helm ແລ່ນຢູ່ເທິງ Kubernetes. ນັ້ນແມ່ນ, ນີ້ບໍ່ແມ່ນບາງລະບົບທີ່ຢືນຢູ່ຂ້າງໆ, ແຕ່ເປັນພຽງແຕ່ການບໍລິການອື່ນທີ່ເປີດຕົວພາຍໃນ cube. ທ່ານພົວພັນກັບມັນຜ່ານ API ຂອງມັນໂດຍຜ່ານຄໍາສັ່ງ console. ຄວາມສະດວກສະບາຍ ແລະຄວາມງາມຂອງມັນແມ່ນວ່າ ເຖິງແມ່ນວ່າໝວກກັນກະທົບແຕກ ຫຼື ເຈົ້າເອົາມັນອອກຈາກກຸ່ມ, ການບໍລິການຂອງເຈົ້າຈະບໍ່ຫາຍໄປ, ເພາະວ່າ ໝວກກັນກະທົບພຽງແຕ່ເຮັດໜ້າທີ່ເລີ່ມຕົ້ນລະບົບເທົ່ານັ້ນ. Kubernetes ຕົວຂອງມັນເອງແມ່ນຮັບຜິດຊອບຕໍ່ການປະຕິບັດແລະສະຖານະຂອງການບໍລິການ.

ພວກເຮົາຍັງໄດ້ຮັບຮູ້ວ່າ ແມ່ແບບ, ເຊິ່ງໃນເມື່ອກ່ອນພວກເຮົາຖືກບັງຄັບໃຫ້ເຮັດດ້ວຍຕົນເອງໂດຍການນໍາ jinja ເຂົ້າໄປໃນ configs ຂອງພວກເຮົາ, ແມ່ນຫນຶ່ງໃນລັກສະນະຕົ້ນຕໍຂອງ helm. ການຕັ້ງຄ່າທັງຫມົດທີ່ທ່ານສ້າງສໍາລັບລະບົບຂອງທ່ານຖືກເກັບໄວ້ໃນ helm ໃນຮູບແບບຂອງແມ່ແບບ, ເລັກນ້ອຍຄ້າຍຄືກັນກັບ jinja, ແຕ່, ໃນຄວາມເປັນຈິງ, ການນໍາໃຊ້ຮູບແບບຂອງພາສາ Go, ໃນ helm ແມ່ນລາຍລັກອັກສອນເຊັ່ນ Kubernetes.

Helm ເພີ່ມແນວຄວາມຄິດອີກສອງສາມຢ່າງສຳລັບພວກເຮົາ.

ຕາຕະລາງ - ນີ້ແມ່ນລາຍລະອຽດຂອງການບໍລິການຂອງທ່ານ. ໃນຜູ້ຈັດການຊຸດອື່ນໆ, ມັນຈະຖືກເອີ້ນວ່າຊຸດ, ມັດຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ. ນີ້ເອີ້ນວ່າຕາຕະລາງ.

ມູນຄ່າ ແມ່ນຕົວແປທີ່ທ່ານຕ້ອງການໃຊ້ເພື່ອສ້າງ configs ຂອງທ່ານຈາກແມ່ແບບ.

ການປ່ອຍ. ແຕ່ລະຄັ້ງທີ່ບໍລິການທີ່ຖືກນຳໃຊ້ໂດຍໃຊ້ໝວກກັນກະທົບຈະໄດ້ຮັບລຸ້ນທີ່ເພີ່ມຂຶ້ນຂອງການປ່ອຍ. Helm ຈື່ຈໍາສິ່ງທີ່ config ການບໍລິການແມ່ນໃນລະຫວ່າງການເປີດຕົວທີ່ຜ່ານມາ, ການປ່ອຍກ່ອນຫນ້ານັ້ນ, ແລະອື່ນໆ. ດັ່ງນັ້ນ, ຖ້າທ່ານຕ້ອງການ rollback, ພຽງແຕ່ດໍາເນີນການຄໍາສັ່ງ callback helm, ຊີ້ມັນກັບສະບັບທີ່ຜ່ານມາ. ເຖິງແມ່ນວ່າການຕັ້ງຄ່າທີ່ສອດຄ້ອງກັນຢູ່ໃນບ່ອນເກັບມ້ຽນຂອງທ່ານບໍ່ສາມາດໃຊ້ໄດ້ໃນເວລາ rollback, helm ຈະຍັງຈື່ວ່າມັນແມ່ນຫຍັງແລະຈະ rollback ລະບົບຂອງທ່ານກັບສະຖານະທີ່ມັນຢູ່ໃນສະບັບທີ່ຜ່ານມາ.

ໃນ​ກໍ​ລະ​ນີ​ທີ່​ພວກ​ເຮົາ​ນໍາ​ໃຊ້ helm​, ການ​ຕັ້ງ​ຄ່າ​ປົກ​ກະ​ຕິ​ສໍາ​ລັບ Kubernetes ຍັງ​ປ່ຽນ​ເປັນ​ແມ່​ແບບ​ທີ່​ມັນ​ເປັນ​ໄປ​ໄດ້​ທີ່​ຈະ​ນໍາ​ໃຊ້​ຕົວ​ປ່ຽນ​ແປງ​, ຫນ້າ​ທີ່​, ແລະ​ນໍາ​ໃຊ້​ຄໍາ​ບັນ​ຍາຍ​ເງື່ອນ​ໄຂ​. ວິທີນີ້ທ່ານສາມາດເກັບກໍາການຕັ້ງຄ່າການບໍລິການຂອງທ່ານຂຶ້ນກັບສະພາບແວດລ້ອມ.

ໃນທາງປະຕິບັດ, ພວກເຮົາໄດ້ຕັດສິນໃຈເຮັດສິ່ງທີ່ແຕກຕ່າງເລັກນ້ອຍກວ່າທີ່ພວກເຮົາໄດ້ເຮັດກັບ Nomad. ຖ້າໃນ Nomad ທັງສອງ configs ການຕິດຕັ້ງແລະ n-variables ທີ່ຈໍາເປັນເພື່ອປະຕິບັດການບໍລິການຂອງພວກເຮົາຖືກເກັບໄວ້ໃນ repository ດຽວ, ໃນທີ່ນີ້ພວກເຮົາໄດ້ຕັດສິນໃຈແບ່ງອອກເປັນສອງ repositories ແຍກຕ່າງຫາກ. ພື້ນທີ່ເກັບຂໍ້ມູນ "deploy" ເກັບຮັກສາພຽງແຕ່ n-variables ທີ່ຈໍາເປັນສໍາລັບການນໍາໃຊ້, ແລະ "helm" repository ເກັບ configs ຫຼືຕາຕະລາງ.

ອັນນີ້ໃຫ້ຫຍັງແກ່ເຮົາ?

ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າພວກເຮົາບໍ່ໄດ້ເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນແທ້ໆໃນໄຟລ໌ການຕັ້ງຄ່າດ້ວຍຕົນເອງ. ຕົວຢ່າງ, ລະຫັດຜ່ານກັບຖານຂໍ້ມູນ. ພວກມັນຖືກເກັບໄວ້ເປັນຄວາມລັບໃນ Kubernetes, ແຕ່ຢ່າງໃດກໍ່ຕາມ, ຍັງມີບາງສິ່ງທີ່ພວກເຮົາບໍ່ຕ້ອງການໃຫ້ທຸກຄົນເຂົ້າເຖິງ. ດັ່ງນັ້ນ, ການເຂົ້າເຖິງບ່ອນເກັບມ້ຽນ "deploy" ແມ່ນຈໍາກັດຫຼາຍ, ແລະ "helm" repository ພຽງແຕ່ມີຄໍາອະທິບາຍກ່ຽວກັບການບໍລິການ. ສໍາລັບເຫດຜົນນີ້, ມັນສາມາດເຂົ້າເຖິງໄດ້ຢ່າງປອດໄພໂດຍປະຊາຊົນຢ່າງກວ້າງຂວາງ.

ເນື່ອງຈາກພວກເຮົາບໍ່ພຽງແຕ່ມີການຜະລິດ, ແຕ່ຍັງສະພາບແວດລ້ອມອື່ນໆ, ຍ້ອນການແຍກນີ້, ພວກເຮົາສາມາດນໍາໃຊ້ຕາຕະລາງຫມວກກັນກະທົບຂອງພວກເຮົາຄືນໃຫມ່ເພື່ອນໍາໃຊ້ການບໍລິການບໍ່ພຽງແຕ່ການຜະລິດ, ແຕ່ຍັງ, ສໍາລັບຕົວຢ່າງ, ສະພາບແວດລ້ອມ QA. ເຖິງແມ່ນວ່າຈະໃຊ້ພວກມັນຢູ່ໃນທ້ອງຖິ່ນ ມິນິຄິບ - ນີ້ແມ່ນສິ່ງສໍາລັບແລ່ນ Kubernetes ໃນທ້ອງຖິ່ນ.

ພາຍໃນແຕ່ລະ repository, ພວກເຮົາໄດ້ປະໄວ້ພະແນກເປັນ directory ແຍກຕ່າງຫາກສໍາລັບແຕ່ລະບໍລິການ. ນັ້ນແມ່ນ, ພາຍໃນແຕ່ລະໄດເລກະທໍລີມີແມ່ແບບທີ່ກ່ຽວຂ້ອງກັບຕາຕະລາງທີ່ສອດຄ້ອງກັນແລະອະທິບາຍຊັບພະຍາກອນທີ່ຈໍາເປັນເພື່ອປະຕິບັດລະບົບຂອງພວກເຮົາ. ພວກເຮົາປະໄວ້ພຽງແຕ່ envs ໃນ "deploy" repository. ໃນກໍລະນີນີ້, ພວກເຮົາບໍ່ໄດ້ໃຊ້ templating ໂດຍໃຊ້ jinja, ເພາະວ່າ helm ຕົວຂອງມັນເອງສະຫນອງ templating ອອກຈາກກ່ອງ - ນີ້ແມ່ນຫນຶ່ງໃນຫນ້າທີ່ຕົ້ນຕໍຂອງມັນ.

ພວກເຮົາໄດ້ປະໄວ້ສະຄຣິບການນຳໃຊ້ - deploy.sh, ເຊິ່ງເຮັດໃຫ້ງ່າຍ ແລະເປັນມາດຕະຖານການເປີດຕົວເພື່ອນຳໃຊ້ກັບໝວກ. ດັ່ງນັ້ນ, ສໍາລັບຜູ້ທີ່ຕ້ອງການນໍາໄປໃຊ້, ການໂຕ້ຕອບການນໍາໄປໃຊ້ເບິ່ງຄືວ່າຄືກັນກັບທີ່ມັນເຮັດໃນເວລາທີ່ deploy ຜ່ານ Nomad. deploy.sh ດຽວກັນ, ຊື່ການບໍລິການຂອງເຈົ້າ, ແລະບ່ອນທີ່ທ່ານຕ້ອງການນຳໃຊ້ມັນ. ນີ້ເຮັດໃຫ້ helm ເລີ່ມຕົ້ນພາຍໃນ. ໃນທາງກັບກັນ, ມັນລວບລວມ configs ຈາກແມ່ແບບ, ໃສ່ໄຟລ໌ທີ່ມີຄ່າທີ່ຈໍາເປັນເຂົ້າໄປໃນພວກມັນ, ຈາກນັ້ນນໍາໄປໃຊ້ພວກມັນ, ເປີດຕົວເຂົ້າໄປໃນ Kubernetes.

ການຄົ້ນພົບ

ການບໍລິການ Kubernetes ເບິ່ງຄືວ່າມີຄວາມຊັບຊ້ອນຫຼາຍກວ່າ Nomad.

ທີ່ນີ້ການຈະລາຈອນຂາອອກມາຮອດ Ingress. ນີ້ແມ່ນພຽງແຕ່ຕົວຄວບຄຸມດ້ານຫນ້າ, ເຊິ່ງໃຊ້ເວລາຫຼາຍກວ່າການຮ້ອງຂໍທັງຫມົດແລະຕໍ່ມາສົ່ງພວກເຂົາໄປຫາບໍລິການທີ່ສອດຄ້ອງກັບຂໍ້ມູນການຮ້ອງຂໍ. ມັນກໍານົດພວກມັນໂດຍອີງໃສ່ configs ທີ່ເປັນສ່ວນຫນຶ່ງຂອງຄໍາອະທິບາຍຄໍາຮ້ອງສະຫມັກຂອງທ່ານໃນ helm ແລະທີ່ນັກພັດທະນາກໍານົດດ້ວຍຕົນເອງ. ການບໍລິການສົ່ງຄໍາຮ້ອງຂໍໄປຍັງຝັກຂອງມັນ, ນັ້ນແມ່ນ, ບັນຈຸສະເພາະ, ດຸ່ນດ່ຽງການຈະລາຈອນຂາເຂົ້າລະຫວ່າງຕູ້ຄອນເທນເນີທັງຫມົດທີ່ຂຶ້ນກັບການບໍລິການນີ້. ແລະ, ແນ່ນອນ, ພວກເຮົາບໍ່ຄວນລືມວ່າພວກເຮົາບໍ່ຄວນໄປທຸກບ່ອນຈາກຄວາມປອດໄພໃນລະດັບເຄືອຂ່າຍ. ດັ່ງນັ້ນ, ການແບ່ງສ່ວນເຮັດວຽກຢູ່ໃນກຸ່ມ Kubernetes, ເຊິ່ງອີງໃສ່ການແທັກ. ການບໍລິການທັງໝົດມີແທັກສະເພາະທີ່ສິດການເຂົ້າເຖິງຂອງການບໍລິການຕໍ່ກັບຊັບພະຍາກອນພາຍນອກ/ພາຍໃນສະເພາະພາຍໃນ ຫຼືພາຍນອກກຸ່ມທີ່ກ່ຽວຂ້ອງ.

ໃນຂະນະທີ່ພວກເຮົາເຮັດການປ່ຽນແປງ, ພວກເຮົາເຫັນວ່າ Kubernetes ມີຄວາມສາມາດທັງຫມົດຂອງ Nomad, ທີ່ພວກເຮົາເຄີຍໃຊ້ໃນເມື່ອກ່ອນ, ແລະຍັງໄດ້ເພີ່ມສິ່ງໃຫມ່ໆຢ່າງຫຼວງຫຼາຍ. ມັນສາມາດຂະຫຍາຍໄດ້ໂດຍຜ່ານ plugins, ແລະໃນຄວາມເປັນຈິງໂດຍຜ່ານປະເພດຊັບພະຍາກອນທີ່ກໍາຫນົດເອງ. ນັ້ນແມ່ນ, ທ່ານມີໂອກາດບໍ່ພຽງແຕ່ນໍາໃຊ້ບາງສິ່ງບາງຢ່າງທີ່ມາພ້ອມກັບ Kubernetes ອອກຈາກກ່ອງ, ແຕ່ເພື່ອສ້າງຊັບພະຍາກອນແລະການບໍລິການຂອງທ່ານເອງທີ່ຈະອ່ານຊັບພະຍາກອນຂອງທ່ານ. ນີ້ເຮັດໃຫ້ທ່ານມີທາງເລືອກເພີ່ມເຕີມເພື່ອຂະຫຍາຍລະບົບຂອງທ່ານໂດຍບໍ່ຈໍາເປັນຕ້ອງຕິດຕັ້ງ Kubernetes ຄືນໃໝ່ ແລະບໍ່ຈຳເປັນຕ້ອງມີການດັດແກ້.

ຕົວຢ່າງຂອງການນໍາໃຊ້ດັ່ງກ່າວແມ່ນ Prometheus, ເຊິ່ງດໍາເນີນການພາຍໃນກຸ່ມ Kubernetes ຂອງພວກເຮົາ. ເພື່ອໃຫ້ມັນເລີ່ມເກັບກໍາຂໍ້ມູນ metrics ຈາກການບໍລິການສະເພາະໃດຫນຶ່ງ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ເພີ່ມປະເພດຂອງຊັບພະຍາກອນເພີ່ມເຕີມ, ທີ່ເອີ້ນວ່າການບໍລິການຕິດຕາມກວດກາ, ລາຍລະອຽດການບໍລິການ. Prometheus, ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າມັນສາມາດອ່ານປະເພດຊັບພະຍາກອນທີ່ກໍາຫນົດເອງເມື່ອເປີດຕົວໃນ Kubernetes, ອັດຕະໂນມັດຈະເລີ່ມຕົ້ນການລວບລວມ metrics ຈາກລະບົບໃຫມ່. ມັນຂ້ອນຂ້າງສະດວກ.

ການນຳໃຊ້ທຳອິດທີ່ພວກເຮົາໄດ້ເຮັດກັບ Kubernetes ແມ່ນໃນເດືອນມີນາ 2018. ແລະໃນໄລຍະນີ້ພວກເຮົາບໍ່ເຄີຍປະສົບບັນຫາໃດໆກັບມັນ. ມັນເຮັດວຽກຂ້ອນຂ້າງຫມັ້ນຄົງໂດຍບໍ່ມີຂໍ້ບົກພ່ອງທີ່ສໍາຄັນ. ນອກຈາກນັ້ນ, ພວກເຮົາສາມາດຂະຫຍາຍມັນຕື່ມອີກ. ມື້ນີ້ພວກເຮົາມີຄວາມສາມາດພຽງພໍທີ່ມັນມີ, ແລະພວກເຮົາກໍ່ມັກຈັງຫວະການພັດທະນາຂອງ Kubernetes. ໃນປັດຈຸບັນ, ຫຼາຍກວ່າ 3000 ຕູ້ຄອນເທນເນີຢູ່ໃນ Kubernetes. ກຸ່ມດັ່ງກ່າວຄອບຄອງຫຼາຍ Nodes. ໃນເວລາດຽວກັນ, ມັນເປັນການບໍລິການ, ມີຄວາມຫມັ້ນຄົງແລະສາມາດຄວບຄຸມໄດ້ຫຼາຍ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com