5 ຫຼັກຄວາມຮູ້ສຶກທົ່ວໄປສຳລັບການສ້າງແອັບ Cloud-Native

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

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

ຫຼັກການອອກແບບຊອບແວ

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

• KISS (ໃຫ້ມັນງ່າຍດາຍ, stupid) – ບໍ່ complicate ມັນ;
• ແຫ້ງ (Don't repeat yourself) — don’t repeat yourself ;
• YAGNI (ເຈົ້າບໍ່ຕ້ອງການມັນ) - ຢ່າສ້າງສິ່ງທີ່ບໍ່ຕ້ອງການທັນທີ;
• SoC ການ​ແບ່ງ​ແຍກ​ຄວາມ​ກັງ​ວົນ – ແບ່ງ​ປັນ​ຄວາມ​ຮັບ​ຜິດ​ຊອບ.

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

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

ຕູ້ຄອນເທນເນີຂອງເມຄ: ວິທີການຂອງ Red Hat

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

ຫຼັກການຄວາມກັງວົນດຽວ (SCP)

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

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

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

ຖ້າບາງ container microservice ຕ້ອງແກ້ໄຂບັນຫາຫຼາຍໆຢ່າງໃນເວລາດຽວກັນ, ມັນກໍ່ສາມາດແບ່ງອອກເປັນພາຊະນະດຽວແລະລວມກັນພາຍໃນຫນຶ່ງຝັກ (ຫນ່ວຍງານຂອງການຕິດຕັ້ງແພລະຕະຟອມຕູ້ຄອນເທນເນີ) ໂດຍໃຊ້ sidecar ແລະ init container templates. ນອກຈາກນັ້ນ, SCP ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການປ່ຽນກ່ອງບັນຈຸເກົ່າ (ເຊັ່ນ: ເຄື່ອງແມ່ຂ່າຍເວັບຫຼືນາຍຫນ້າຂໍ້ຄວາມ) ກັບອັນໃຫມ່ທີ່ແກ້ໄຂບັນຫາດຽວກັນແຕ່ໄດ້ຂະຫຍາຍການເຮັດວຽກຫຼືຂະຫນາດທີ່ດີກວ່າ.

ຫຼັກການສັງເກດການສູງ (HOP)

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

ໃນທາງປະຕິບັດ, ຄໍາຮ້ອງສະຫມັກບັນຈຸບັນຈຸຄວນ, ຢ່າງຫນ້ອຍ, ມີ API ສໍາລັບປະເພດຕ່າງໆຂອງການກວດສຸຂະພາບ: ການທົດສອບຊີວິດແລະການທົດສອບຄວາມພ້ອມ. ຖ້າແອັບພລິເຄຊັນອ້າງວ່າເຮັດຫຼາຍກວ່ານັ້ນ, ມັນຕ້ອງໃຫ້ວິທີການອື່ນໃນການຕິດຕາມສະຖານະຂອງມັນ. ຕົວຢ່າງ, ການບັນທຶກເຫດການທີ່ສໍາຄັນຜ່ານ STDERR ແລະ STDOUT ສໍາລັບການລວບລວມບັນທຶກໂດຍໃຊ້ Fluentd, Logstash ແລະເຄື່ອງມືທີ່ຄ້າຍຄືກັນອື່ນໆ. ເຊັ່ນດຽວກັນກັບການເຊື່ອມໂຍງກັບຫ້ອງສະຫມຸດການເກັບກໍາການຕິດຕາມແລະການວັດແທກ, ເຊັ່ນ OpenTracing, Prometheus, ແລະອື່ນໆ.

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

ຫຼັກການຄວາມສອດຄ່ອງຂອງວົງຈອນຊີວິດ (LCP)

LCP ແມ່ນ antithesis ຂອງ HOP. ໃນຂະນະທີ່ HOP ບອກວ່າຕູ້ຄອນເທນເນີຕ້ອງເປີດເຜີຍ APIs ອ່ານຕໍ່ເວທີ, LCP ຮຽກຮ້ອງໃຫ້ແອັບພລິເຄຊັນສາມາດຍອມຮັບຂໍ້ມູນຈາກເວທີ. ຍິ່ງໄປກວ່ານັ້ນ, ຕູ້ຄອນເທນເນີຕ້ອງບໍ່ພຽງແຕ່ໄດ້ຮັບເຫດການ, ແຕ່ຍັງປັບຕົວ, ໃນຄໍາສັບຕ່າງໆອື່ນໆ, react ກັບພວກເຂົາ. ເພາະສະນັ້ນຊື່ຂອງຫຼັກການ, ເຊິ່ງສາມາດໄດ້ຮັບການພິຈາລະນາເປັນຂໍ້ກໍານົດທີ່ຈະສະຫນອງເວທີທີ່ມີການຂຽນ APIs.

ເວທີມີເຫດການປະເພດຕ່າງໆເພື່ອຊ່ວຍຈັດການວົງຈອນຊີວິດຂອງຖັງ. ແຕ່ມັນຂຶ້ນກັບແອັບພລິເຄຊັນຕົວມັນເອງທີ່ຈະຕັດສິນໃຈວ່າຈະຮັບຮູ້ອັນໃດ ແລະຈະຕອບສະໜອງແນວໃດ.

ມັນເປັນທີ່ຊັດເຈນວ່າບາງເຫດການມີຄວາມສໍາຄັນກວ່າເຫດການອື່ນໆ. ຕົວຢ່າງ, ຖ້າແອັບພລິເຄຊັນບໍ່ທົນທານຕໍ່ການເກີດອຸປະຕິເຫດໄດ້ດີ, ມັນຕ້ອງຍອມຮັບສັນຍານ: ຢຸດ (SIGTERM) ຂໍ້ຄວາມແລະເລີ່ມຕົ້ນການຢຸດເຊົາການປົກກະຕິໄວເທົ່າທີ່ຈະໄວໄດ້ເພື່ອຈັບສັນຍານ: ຂ້າ (SIGKILL) ທີ່ມາຫຼັງຈາກ SIGTERM.

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

ຫຼັກການບໍ່ປ່ຽນແປງຮູບພາບ (IIP)

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

ເປົ້າຫມາຍຂອງ IIP ແມ່ນເພື່ອປ້ອງກັນການສ້າງຮູບພາບບັນຈຸແຍກຕ່າງຫາກສໍາລັບສະພາບແວດລ້ອມ runtime ທີ່ແຕກຕ່າງກັນແລະນໍາໃຊ້ຮູບພາບດຽວກັນຢູ່ທົ່ວທຸກແຫ່ງພ້ອມກັບການຕັ້ງຄ່າສະພາບແວດລ້ອມທີ່ເຫມາະສົມ. ການປະຕິບັດຕາມຫຼັກການນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດການປະຕິບັດທີ່ສໍາຄັນດັ່ງກ່າວຈາກທັດສະນະຂອງອັດຕະໂນມັດຂອງລະບົບຟັງເປັນ roll-back ແລະ roll-forward ຂອງການປັບປຸງຄໍາຮ້ອງສະຫມັກ.

ຫຼັກການ Disposability ຂະບວນການ (PDP)

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

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

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

ຫຼັກການຄວບຄຸມຕົນເອງ (S-CP)

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

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

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

Runtime Confinement Principle (RCP)

ຫຼັກການ S-CP ກໍານົດວິທີການສ້າງຕູ້ຄອນເທນເນີແລະສິ່ງທີ່ສອງຮູບພາບຄວນມີ. ແຕ່ຕູ້ຄອນເທນເນີບໍ່ພຽງແຕ່ເປັນ "ກ່ອງດໍາ" ທີ່ມີລັກສະນະດຽວເທົ່ານັ້ນ - ຂະຫນາດໄຟລ໌. ໃນ​ລະ​ຫວ່າງ​ການ​ປະ​ຕິ​ບັດ​, container ຈະ​ໃຊ້​ເວ​ລາ​ຂະ​ຫນາດ​ອື່ນໆ​: ຈໍາ​ນວນ​ຂອງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ທີ່​ໃຊ້​, ທີ່​ໃຊ້​ເວ​ລາ CPU​, ແລະ​ຊັບ​ພະ​ຍາ​ກອນ​ລະ​ບົບ​ອື່ນໆ​.

ແລະໃນທີ່ນີ້ຫຼັກການ RCP ມາເປັນປະໂຫຍດ, ອີງຕາມການບັນຈຸຕ້ອງ decapitate ຄວາມຕ້ອງການຂອງຕົນສໍາລັບຊັບພະຍາກອນລະບົບແລະໂອນໃຫ້ເຂົາເຈົ້າກັບເວທີ. ດ້ວຍໂປຣໄຟລ໌ຊັບພະຍາກອນຂອງແຕ່ລະ container (ຕ້ອງການ CPU, ໜ່ວຍຄວາມຈຳ, ເຄືອຂ່າຍ ແລະແຜ່ນດິດຫຼາຍປານໃດ), ແພລດຟອມສາມາດປະຕິບັດການກຳນົດເວລາ ແລະ autoscaling ໄດ້ດີທີ່ສຸດ, ຈັດການຄວາມອາດສາມາດຂອງ IT, ແລະຮັກສາລະດັບ SLA ສໍາລັບ containers.

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

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

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

• ພະຍາຍາມຫຼຸດຜ່ອນຂະຫນາດຂອງຮູບພາບ: ລຶບໄຟລ໌ຊົ່ວຄາວແລະບໍ່ຕິດຕັ້ງແພັກເກັດທີ່ບໍ່ຈໍາເປັນ - ຂະຫນາດບັນຈຸຂະຫນາດນ້ອຍກວ່າ, ມັນໄວກວ່າມັນຈະຖືກລວບລວມແລະຄັດລອກໄປຫາເຈົ້າພາບເປົ້າຫມາຍຜ່ານເຄືອຂ່າຍ.
• ເນັ້ນໃສ່ User-IDs ທີ່ບໍ່ມັກ: ຢ່າໃຊ້ຄໍາສັ່ງ sudo ຫຼື userid ພິເສດໃດໆເພື່ອເປີດກ່ອງບັນຈຸຂອງທ່ານ.
• ຫມາຍໃສ່ພອດທີ່ສໍາຄັນ: ທ່ານສາມາດກໍານົດຕົວເລກພອດໃນເວລາແລ່ນ, ແຕ່ມັນກໍ່ດີກວ່າທີ່ຈະລະບຸພວກມັນໂດຍໃຊ້ຄໍາສັ່ງ EXPOSE - ມັນຈະເຮັດໃຫ້ຄົນອື່ນແລະໂປຼແກຼມໃຊ້ຮູບພາບຂອງເຈົ້າງ່າຍຂຶ້ນ.
• ເກັບຮັກສາຂໍ້ມູນທີ່ຄົງຄ້າງຢູ່ໃນປະລິມານ: ຂໍ້ມູນທີ່ຄວນຈະຍັງຄົງຢູ່ຫຼັງຈາກຖັງຖືກທໍາລາຍຄວນຈະຖືກຂຽນເປັນປະລິມານ.
• ຂຽນ metadata ຂອງຮູບພາບ: tags, ປ້າຍຊື່ແລະຄໍາບັນຍາຍເຮັດໃຫ້ຮູບພາບງ່າຍຕໍ່ການນໍາໃຊ້ - ຜູ້ພັດທະນາອື່ນໆຈະຂໍຂອບໃຈທ່ານ.
• synchronize host ແລະຮູບພາບ: ບາງແອັບພລິເຄຊັນທີ່ມີ containerized ຕ້ອງການ container ເພື່ອ sync ກັບ host ໃນຄຸນລັກສະນະບາງຢ່າງເຊັ່ນ: ເວລາຫຼື machine ID.
• ສະຫຼຸບແລ້ວ, ພວກເຮົາແບ່ງປັນແມ່ແບບ ແລະວິທີປະຕິບັດທີ່ດີທີ່ສຸດທີ່ຈະຊ່ວຍໃຫ້ທ່ານປະຕິບັດໄດ້ປະສິດທິຜົນຫຼາຍຂຶ້ນຕາມຫຼັກການທີ່ລະບຸໄວ້ຂ້າງເທິງ:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

Webinar ໃນເວີຊັ່ນໃໝ່ຂອງ OpenShift Container Platform – 4
ວັນທີ 11 ມິຖຸນາ ເວລາ 11.00:XNUMX

ສິ່ງ​ທີ່​ທ່ານ​ຈະ​ໄດ້​ຮຽນ​ຮູ້​:

• ບໍ່ສາມາດປ່ຽນແປງໄດ້ Red Hat Enterprise Linux CoreOS
• ຕາໜ່າງບໍລິການ OpenShift
• ກອບການດໍາເນີນການ
• ໂຄງຮ່າງການປະດິດ

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