ຄວາມປອດໄພ Helm

ໂດຍເນື້ອແທ້ແລ້ວຂອງເລື່ອງກ່ຽວກັບຜູ້ຈັດການຊຸດທີ່ນິຍົມທີ່ສຸດສໍາລັບ Kubernetes ສາມາດຖືກບັນຍາຍໂດຍໃຊ້ emoji:

• ກ່ອງແມ່ນ Helm (ເຊິ່ງເປັນສິ່ງທີ່ໃກ້ຊິດກັບການປ່ອຍ Emoji ຫຼ້າສຸດ);
• lock - ຄວາມປອດໄພ;
• ຜູ້ຊາຍພຽງເລັກນ້ອຍແມ່ນການແກ້ໄຂບັນຫາ.

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

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

ທຸກຢ່າງໃນບົດຄວາມນີ້ໃຊ້ໄດ້ກັບ Helm 2. ລຸ້ນນີ້ກຳລັງຢູ່ໃນການຜະລິດ ແລະອາດຈະເປັນລຸ້ນທີ່ທ່ານກຳລັງໃຊ້ຢູ່, ແລະມັນເປັນລຸ້ນທີ່ມີຄວາມສ່ຽງດ້ານຄວາມປອດໄພ.

ກ່ຽວ​ກັບ​ຜູ້​ເວົ້າ​: Alexander Khayorov (ອາເລັກເອັກ) ໄດ້ພັດທະນາເປັນເວລາ 10 ປີ, ຊ່ວຍໃຫ້ການປັບປຸງເນື້ອຫາ Moscow Python Conf++ ແລະ​ເຂົ້າ​ຮ່ວມ​ຄະ​ນະ​ກໍາ​ມະ​ການ​ ກອງປະຊຸມສຸດຍອດ Helm. ໃນປັດຈຸບັນລາວເຮັດວຽກຢູ່ Chainstack ເປັນຜູ້ນໍາພາການພັດທະນາ - ນີ້ແມ່ນການປະສົມລະຫວ່າງຜູ້ຈັດການພັດທະນາແລະຜູ້ທີ່ຮັບຜິດຊອບໃນການສະຫນອງການປ່ອຍຕົວສຸດທ້າຍ. ນັ້ນແມ່ນ, ມັນຕັ້ງຢູ່ໃນສະຫນາມຮົບ, ບ່ອນທີ່ທຸກສິ່ງທຸກຢ່າງເກີດຂື້ນຈາກການສ້າງຜະລິດຕະພັນໄປສູ່ການດໍາເນີນງານຂອງມັນ.

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

Helm

ນີ້ແມ່ນຊຸດ (ຕາຕະລາງ) ຜູ້ຈັດການສໍາລັບ Kubernetes. ວິທີທີ່ສະຫຼາດທີ່ສຸດ ແລະເປັນທົ່ວໆໄປໃນການນຳເອົາແອັບພລິເຄຊັນມາສູ່ກຸ່ມ Kubernetes.

ພວກເຮົາ, ແນ່ນອນ, ເວົ້າກ່ຽວກັບໂຄງສ້າງແລະວິທີການອຸດສາຫະກໍາຫຼາຍກ່ວາການສ້າງ YAML ຂອງທ່ານເອງ manifests ແລະຂຽນສິ່ງອໍານວຍຄວາມສະດວກຂະຫນາດນ້ອຍ.

Helm ແມ່ນດີທີ່ສຸດທີ່ມີຢູ່ໃນປະຈຸບັນແລະເປັນທີ່ນິຍົມ.

ເປັນຫຍັງ Helm? ຕົ້ນຕໍເນື່ອງຈາກວ່າມັນໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍ CNCF. Cloud Native ເປັນອົງກອນຂະຫນາດໃຫຍ່ ແລະເປັນບໍລິສັດແມ່ສໍາລັບໂຄງການ Kubernetes, etcd, Fluentd ແລະອື່ນໆ.

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

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

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

Helm ແກ້ໄຂບັນຫາຮາກຫຼາຍຢ່າງຂອງການຈັດການແອັບພລິເຄຊັນໃນ Kubernetes.

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

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

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

ແອັບພລິເຄຊັນການຄຸ້ມຄອງວົງຈອນຊີວິດ - ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ນີ້ແມ່ນຄໍາຖາມທີ່ຫນ້າສົນໃຈທີ່ສຸດແລະບໍ່ໄດ້ຮັບການແກ້ໄຂ. ນີ້ແມ່ນເຫດຜົນທີ່ຂ້ອຍມາ Helm ໃນມື້ນັ້ນ. ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕິດຕາມຊີວິດຂອງຄໍາຮ້ອງສະຫມັກແລະຕ້ອງການຍ້າຍ CI / CD ແລະວົງຈອນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໄປສູ່ຄໍາຂວັນນີ້.

Helm ອະນຸຍາດໃຫ້ທ່ານ:

• ການ​ຄຸ້ມ​ຄອງ​ການ​ນໍາ​ໃຊ້​, ແນະ​ນໍາ​ແນວ​ຄວາມ​ຄິດ​ຂອງ​ການ​ຕັ້ງ​ຄ່າ​ແລະ​ການ​ປັບ​ປຸງ​;
• ສໍາເລັດການປະຕິບັດ rollback;
• ໃຊ້ hooks ສໍາລັບເຫດການທີ່ແຕກຕ່າງກັນ;
• ເພີ່ມການກວດສອບຄໍາຮ້ອງສະຫມັກເພີ່ມເຕີມແລະຕອບສະຫນອງຜົນໄດ້ຮັບຂອງພວກເຂົາ.

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

Helm ແມ່ນອີງໃສ່ສາມແນວຄວາມຄິດຕົ້ນຕໍ:

• ຕາຕະລາງ Repo — ລາຍ​ລະ​ອຽດ​ແລະ array ຂອງ​ຕົວ​ກໍາ​ນົດ​ການ​ທີ່​ເປັນ​ໄປ​ໄດ້​ສໍາ​ລັບ​ການ manifest ຂອງ​ທ່ານ​. 
• config — ນັ້ນ​ແມ່ນ​, ຄ່າ​ທີ່​ຈະ​ນໍາ​ໃຊ້ (ຂໍ້​ຄວາມ​, ຄ່າ​ຕົວ​ເລກ​, ແລະ​ອື່ນໆ​)​.
• ການປ່ອຍ ເກັບກໍາທັງສອງອົງປະກອບເທິງ, ແລະຮ່ວມກັນເຂົາເຈົ້າກາຍເປັນການປ່ອຍ. ການປ່ອຍອອກມາສາມາດໄດ້ຮັບການສະບັບ, ດັ່ງນັ້ນການບັນລຸວົງຈອນຊີວິດທີ່ມີການຈັດຕັ້ງ: ຂະຫນາດນ້ອຍໃນເວລາທີ່ການຕິດຕັ້ງແລະຂະຫນາດໃຫຍ່ໃນເວລາທີ່ການຍົກລະດັບ, downgrade ຫຼື rollback.

ສະຖາປັດຕະຍະກໍາຫມວກກັນກະທົບ

ແຜນວາດສະແດງແນວຄວາມຄິດກ່ຽວກັບສະຖາປັດຕະຍະກຳລະດັບສູງຂອງ Helm.

ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າ Helm ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ກ່ຽວຂ້ອງກັບ Kubernetes. ດັ່ງນັ້ນ, ພວກເຮົາບໍ່ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີກຸ່ມ Kubernetes (ສີ່ຫລ່ຽມ). ອົງປະກອບ kube-apiserver ອາໄສຢູ່ກັບແມ່ບົດ. ຖ້າບໍ່ມີ Helm ພວກເຮົາມີ Kubeconfig. Helm ເອົາສອງຄູ່ຂະຫນາດນ້ອຍ, ຖ້າທ່ານສາມາດເອີ້ນມັນວ່າ, Helm CLI utility, ເຊິ່ງຕິດຕັ້ງຢູ່ໃນຄອມພິວເຕີ, ຄອມພິວເຕີ, ເມນເຟຣມ - ຢູ່ໃນສິ່ງໃດ.

ແຕ່ນີ້ບໍ່ພຽງພໍ. Helm ມີອົງປະກອບເຊີຟເວີທີ່ເອີ້ນວ່າ Tiller. ມັນສະແດງເຖິງຜົນປະໂຫຍດຂອງ Helm ພາຍໃນກຸ່ມ; ມັນເປັນແອັບພລິເຄຊັນພາຍໃນກຸ່ມ Kubernetes, ຄືກັນກັບສິ່ງອື່ນໆ.

ອົງປະກອບຕໍ່ໄປຂອງ Chart Repo ແມ່ນບ່ອນເກັບມ້ຽນທີ່ມີຕາຕະລາງ. ມີ repository ຢ່າງເປັນທາງການ, ແລະອາດຈະມີ repository ເອກະຊົນຂອງບໍລິສັດຫຼືໂຄງການ.

ການພົວພັນຮ່ວມກັນ

ຂໍໃຫ້ເບິ່ງວ່າອົງປະກອບສະຖາປັດຕະຍະກໍາມີປະຕິກິລິຍາແນວໃດເມື່ອພວກເຮົາຕ້ອງການຕິດຕັ້ງແອັບພລິເຄຊັນໂດຍໃຊ້ Helm.

• ພວກເຮົາ ກຳ ລັງລົມກັນຢູ່ Helm install, ເຂົ້າເຖິງບ່ອນເກັບມ້ຽນ (Chart Repo) ແລະໄດ້ຮັບຕາຕະລາງ Helm.

• Helm utility (Helm CLI) ໂຕ້ຕອບກັບ Kubeconfig ເພື່ອຄິດອອກວ່າຈະຕິດຕໍ່ກັບກຸ່ມໃດ. 
• ໄດ້ຮັບຂໍ້ມູນນີ້, ຜົນປະໂຫຍດຫມາຍເຖິງ Tiller, ເຊິ່ງຕັ້ງຢູ່ໃນກຸ່ມຂອງພວກເຮົາ, ເປັນຄໍາຮ້ອງສະຫມັກ. 
• Tiller ໂທຫາ Kube-apiserver ເພື່ອປະຕິບັດການປະຕິບັດໃນ Kubernetes, ສ້າງວັດຖຸບາງຢ່າງ (ການບໍລິການ, ຝັກ, replicas, ຄວາມລັບ, ແລະອື່ນໆ).

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

ການໂຈມຕີ vector

ຈຸດອ່ອນທີ່ເປັນໄປໄດ້ທໍາອິດແມ່ນ API ສິດທິພິເສດ-ຜູ້ໃຊ້. ເປັນສ່ວນຫນຶ່ງຂອງໂຄງການ, ນີ້ແມ່ນແຮກເກີທີ່ໄດ້ຮັບການເຂົ້າເຖິງ admin ກັບ Helm CLI.

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

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

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

ຂໍໃຫ້ພະຍາຍາມປ້ອງກັນການໂຈມຕີຈາກທັງຫມົດສີ່ດ້ານນີ້ແລະຊອກຫາບ່ອນທີ່ມີບັນຫາໃນສະຖາປັດຕະຍະກໍາ Helm, ແລະບ່ອນໃດ, ບາງທີ, ບໍ່ມີບ່ອນໃດ.

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

Helm CLI ຕິດຕໍ່ສື່ສານກັບ Chart Repo, ພົວພັນກັບ Kubeconfig, ແລະວຽກງານຖືກໂອນໄປຫາກຸ່ມໄປຫາອົງປະກອບ Tiller.

Tiller ແມ່ນສະແດງໂດຍສອງວັດຖຸ:

• Tiller-deploy svc, ເຊິ່ງເປີດເຜີຍການບໍລິການທີ່ແນ່ນອນ;
• Tiller-deploy pod (ໃນແຜນວາດໃນສໍາເນົາດຽວໃນຫນຶ່ງ replica), ເຊິ່ງການໂຫຼດທັງຫມົດແລ່ນ, ເຊິ່ງເຂົ້າເຖິງ cluster.

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

• ກົນໄກທີ່ Helm CLI ເຂົ້າເຖິງ repo ຕາຕະລາງ: ໂປໂຕຄອນໃດ, ມີການກວດສອບຄວາມຖືກຕ້ອງແລະສິ່ງທີ່ສາມາດເຮັດໄດ້ກັບມັນ.
• ອະນຸສັນຍາທີ່ Helm CLI, ໂດຍໃຊ້ kubectl, ສື່ສານກັບ Tiller. ນີ້ແມ່ນເຊີບເວີ RPC ທີ່ຕິດຕັ້ງພາຍໃນກຸ່ມ.
• Tiller ຕົວຂອງມັນເອງແມ່ນສາມາດເຂົ້າເຖິງ microservices ທີ່ອາໄສຢູ່ໃນ cluster ແລະພົວພັນກັບ Kube-apiserver.

ໃຫ້​ເຮົາ​ປຶກ​ສາ​ຫາ​ລື​ຂົງ​ເຂດ​ທັງ​ຫມົດ​ເຫຼົ່າ​ນີ້​ໃນ​ຄໍາ​ສັ່ງ​.

RBAC

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

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

https://rbac.dev/ — ທະ​ນາຍ​ຄວາມ​ເວັບ​ໄຊ​ທ​໌​ສໍາ​ລັບ RBAC​. ມັນມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງວັດສະດຸທີ່ຫນ້າສົນໃຈທີ່ຈະຊ່ວຍໃຫ້ທ່ານຕັ້ງຄ່າ RBAC, ສະແດງໃຫ້ເຫັນວ່າເປັນຫຍັງມັນດີແລະວິທີການດໍາລົງຊີວິດໂດຍພື້ນຖານແລ້ວກັບມັນໃນການຜະລິດ.

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

ເມື່ອທ່ານເລີ່ມຕົ້ນ Helm ແລະຕິດຕັ້ງມັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຄັ້ງທໍາອິດ, ທ່ານສາມາດກໍານົດບັນຊີການບໍລິການໂດຍໃຊ້ --service-account. ນີ້ຈະຊ່ວຍໃຫ້ທ່ານໃຊ້ຜູ້ໃຊ້ທີ່ມີຊຸດສິດທິຂັ້ນຕ່ໍາທີ່ຕ້ອງການ. ແທ້ຈິງແລ້ວ, ທ່ານຈະຕ້ອງສ້າງ "garland" ດັ່ງກ່າວ: ພາລະບົດບາດແລະພາລະບົດບາດຜູກມັດ.

ແຕ່ຫນ້າເສຍດາຍ, Helm ຈະບໍ່ເຮັດສິ່ງນີ້ສໍາລັບທ່ານ. ທ່ານ ຫຼື ຜູ້ບໍລິຫານກຸ່ມ Kubernetes ຂອງທ່ານຕ້ອງການກະກຽມຊຸດບົດບາດ ແລະ RoleBindings ສໍາລັບບັນຊີການບໍລິການລ່ວງໜ້າເພື່ອຜ່ານ Helm.

ຄໍາຖາມທີ່ເກີດຂື້ນ - ແມ່ນຫຍັງຄືຄວາມແຕກຕ່າງລະຫວ່າງບົດບາດແລະ ClusterRole? ຄວາມແຕກຕ່າງແມ່ນວ່າ ClusterRole ເຮັດວຽກສໍາລັບ namespaces ທັງຫມົດ, ບໍ່ເຫມືອນກັບ Roles ປົກກະຕິແລະ RoleBindings, ເຊິ່ງພຽງແຕ່ເຮັດວຽກສໍາລັບ namespace ພິເສດ. ທ່ານສາມາດກຳນົດຄ່ານະໂຍບາຍສຳລັບກຸ່ມທັງໝົດ ແລະທຸກ namespaces, ຫຼືປັບແຕ່ງສະເພາະແຕ່ລະ namespace ແຕ່ລະຄົນ.

ມັນເປັນມູນຄ່າທີ່ບອກວ່າ RBAC ແກ້ໄຂບັນຫາໃຫຍ່ອີກອັນຫນຶ່ງ. ຫຼາຍຄົນຈົ່ມວ່າ Helm, ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ແມ່ນ multitenancy (ບໍ່ສະຫນັບສະຫນູນ multitenancy). ຖ້າຫຼາຍໆທີມບໍລິໂພກກຸ່ມແລະໃຊ້ Helm, ມັນເປັນໄປບໍ່ໄດ້ໂດຍພື້ນຖານແລ້ວທີ່ຈະຕັ້ງນະໂຍບາຍແລະຈໍາກັດການເຂົ້າເຖິງຂອງພວກເຂົາພາຍໃນກຸ່ມນີ້, ເພາະວ່າມີບັນຊີການບໍລິການທີ່ແນ່ນອນທີ່ Helm ດໍາເນີນການ, ແລະມັນສ້າງຊັບພະຍາກອນທັງຫມົດໃນກຸ່ມຈາກພາຍໃຕ້ມັນ. , ເຊິ່ງບາງຄັ້ງກໍ່ບໍ່ສະດວກຫຼາຍ. ນີ້ແມ່ນຄວາມຈິງ - ຄືກັບໄຟລ໌ສອງຕົວຂອງມັນເອງ, ຄືກັບຂະບວນການ, Helm Tiller ບໍ່ມີແນວຄວາມຄິດຂອງ multitenancy.

ຢ່າງໃດກໍ່ຕາມ, ມີວິທີທີ່ດີທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດດໍາເນີນການ Tiller ຫຼາຍຄັ້ງໃນກຸ່ມ. ບໍ່ມີບັນຫາກັບເລື່ອງນີ້, Tiller ສາມາດຖືກເປີດຕົວໃນທຸກໆ namespace. ດັ່ງນັ້ນ, ທ່ານສາມາດນໍາໃຊ້ RBAC, Kubeconfig ເປັນສະພາບການ, ແລະຈໍາກັດການເຂົ້າເຖິງ Helm ພິເສດ.

ມັນຈະມີລັກສະນະນີ້.

ຕົວຢ່າງ, ມີສອງ Kubeconfigs ທີ່ມີບໍລິບົດສໍາລັບທີມທີ່ແຕກຕ່າງກັນ (ສອງ namespaces): ທີມ X ສໍາລັບທີມພັດທະນາແລະກຸ່ມ admin. ກຸ່ມຜູ້ເບິ່ງແຍງລະບົບມີ Tiller ກວ້າງຂອງຕົນເອງ, ເຊິ່ງຕັ້ງຢູ່ໃນພື້ນທີ່ຊື່ລະບົບ Kube, ເຊິ່ງເປັນບັນຊີການບໍລິການຂັ້ນສູງທີ່ສອດຄ້ອງກັນ. ແລະ namespace ແຍກຕ່າງຫາກສໍາລັບທີມງານພັດທະນາ, ພວກເຂົາເຈົ້າຈະສາມາດປະຕິບັດການບໍລິການຂອງເຂົາເຈົ້າກັບ namespace ພິເສດ.

ນີ້​ແມ່ນ​ວິ​ທີ​ການ​ທີ່​ສາ​ມາດ​ເຮັດ​ໄດ້​, Tiller ບໍ່​ແມ່ນ​ພະ​ລັງ​ງານ​ຫິວ​ທີ່​ຈະ​ມີ​ຜົນ​ກະ​ທົບ​ຢ່າງ​ຫຼວງ​ຫຼາຍ​ກັບ​ງົບ​ປະ​ມານ​ຂອງ​ທ່ານ​. ນີ້​ແມ່ນ​ຫນຶ່ງ​ໃນ​ການ​ແກ້​ໄຂ​ໄວ​.

ຮູ້ສຶກວ່າບໍ່ເສຍຄ່າເພື່ອກໍານົດ Tiller ແຍກຕ່າງຫາກແລະໃຫ້ Kubeconfig ກັບສະພາບການສໍາລັບທີມງານ, ສໍາລັບນັກພັດທະນາສະເພາະຫຼືສໍາລັບສະພາບແວດລ້ອມ: Dev, Staging, Production (ມັນສົງໃສວ່າທຸກສິ່ງທຸກຢ່າງຈະຢູ່ໃນກຸ່ມດຽວກັນ, ແນວໃດກໍ່ຕາມ, ນີ້ສາມາດເຮັດໄດ້).

ສືບຕໍ່ເລື່ອງຂອງພວກເຮົາ, ໃຫ້ປ່ຽນຈາກ RBAC ແລະສົນທະນາກ່ຽວກັບ ConfigMaps.

ConfigMaps

Helm ໃຊ້ ConfigMaps ເປັນບ່ອນເກັບຂໍ້ມູນຂອງມັນ. ເມື່ອພວກເຮົາເວົ້າກ່ຽວກັບສະຖາປັດຕະຍະກໍາ, ບໍ່ມີຖານຂໍ້ມູນໃດໆທີ່ຈະເກັບຂໍ້ມູນກ່ຽວກັບການປ່ອຍ, ການຕັ້ງຄ່າ, rollbacks, ແລະອື່ນໆ ConfigMaps ຖືກນໍາໃຊ້ສໍາລັບການນີ້.

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

ນີ້ແມ່ນເຮັດຫຼາຍງ່າຍດາຍ. ລົບລ້າງການຕັ້ງຄ່າ Tiller ແລະລະບຸວ່າການເກັບຮັກສາຈະເປັນຄວາມລັບ. ຫຼັງຈາກນັ້ນ, ສໍາລັບການປະຕິບັດແຕ່ລະຄົນ, ທ່ານຈະໄດ້ຮັບບໍ່ແມ່ນ ConfigMap, ແຕ່ເປັນຄວາມລັບ.

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

ມັນເປັນການດີກວ່າທີ່ຈະໂອນ Storage Helm ໄປຫາຄວາມລັບ, ແລະພວກມັນ, ໃນທາງກັບກັນ, ໄດ້ຮັບການຮັບປະກັນຈາກສູນກາງ.

ແນ່ນອນມັນຈະຍັງຄົງຢູ່ ຈໍາກັດການເກັບຮັກສາຂໍ້ມູນ 1 MB. Helm ຢູ່ທີ່ນີ້ໃຊ້ etcd ເປັນການເກັບຮັກສາທີ່ແຈກຢາຍສໍາລັບ ConfigMaps. ແລະຢູ່ທີ່ນັ້ນພວກເຂົາພິຈາລະນາວ່ານີ້ແມ່ນຂໍ້ມູນທີ່ເຫມາະສົມສໍາລັບການຈໍາລອງ, ແລະອື່ນໆ. ມີການສົນທະນາທີ່ຫນ້າສົນໃຈກ່ຽວກັບເລື່ອງນີ້ໃນ Reddit, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ຊອກຫາການອ່ານຕະຫລົກນີ້ສໍາລັບທ້າຍອາທິດຫຼືອ່ານສານສະກັດຈາກ ທີ່ນີ້.

ຕາຕະລາງ Repos

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

ທ່ານແນ່ນອນຈໍາເປັນຕ້ອງເປີດເຜີຍ Helm Repo ຜ່ານ HTTPS - ນີ້ແມ່ນທາງເລືອກທີ່ດີທີ່ສຸດແລະລາຄາບໍ່ແພງ.

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

ຍິ່ງ​ໄປ​ກວ່າ​ນັ້ນ​, ລູກຄ້າ Helm ສະຫນັບສະຫນູນ TLS (ບໍ່ແມ່ນໃນຄວາມຮູ້ສຶກ HTTP ຂ້າງເຊີບເວີ, ແຕ່ TLS ເຊິ່ງກັນແລະກັນ). ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ລະ​ຫັດ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ແລະ​ລູກ​ຄ້າ​ໃນ​ຄໍາ​ສັ່ງ​ທີ່​ຈະ​ຕິດ​ຕໍ່​ພົວ​ພັນ​. ດ້ວຍຄວາມຊື່ສັດ, ຂ້ອຍບໍ່ໃຊ້ກົນໄກດັ່ງກ່າວເພາະວ່າຂ້ອຍບໍ່ມັກໃບຢັ້ງຢືນເຊິ່ງກັນແລະກັນ. ໂດຍພື້ນຖານແລ້ວ, ຫໍພິພິທະພັນຕາຕະລາງ - ເຄື່ອງມືຕົ້ນຕໍໃນການຕັ້ງຄ່າ Helm Repo ສໍາລັບ Helm 2 - ຍັງສະຫນັບສະຫນູນການກວດສອບພື້ນຖານ. ທ່ານສາມາດນໍາໃຊ້ການກວດສອບພື້ນຖານໄດ້ຖ້າມັນສະດວກກວ່າແລະງຽບກວ່າ.

ນອກຈາກນີ້ຍັງມີ plugin helm-gcs, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດເປັນເຈົ້າພາບ Chart Repos ໃນ Google Cloud Storage. ນີ້ແມ່ນຂ້ອນຂ້າງສະດວກ, ເຮັດວຽກໄດ້ດີແລະຂ້ອນຂ້າງປອດໄພ, ເພາະວ່າກົນໄກທີ່ອະທິບາຍທັງຫມົດໄດ້ຖືກນໍາມາໃຊ້ໃຫມ່.

ຖ້າທ່ານເປີດໃຊ້ HTTPS ຫຼື TLS, ໃຊ້ mTLS, ແລະເປີດໃຊ້ການກວດສອບພື້ນຖານເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຕື່ມອີກ, ທ່ານຈະໄດ້ຮັບຊ່ອງທາງການສື່ສານທີ່ປອດໄພກັບ Helm CLI ແລະ Chart Repo.

gRPC API

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

ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວ, Tiller ແມ່ນການບໍລິການທີ່ເປີດເຜີຍ gRPC, ລູກຄ້າ Helm ມາຫາມັນຜ່ານ gRPC. ໂດຍຄ່າເລີ່ມຕົ້ນ, ແນ່ນອນ, TLS ຖືກປິດໃຊ້ງານ. ເປັນຫຍັງນີ້ຈຶ່ງເປັນຄໍາຖາມທີ່ໂຕ້ແຍ້ງໄດ້, ມັນເບິ່ງຄືວ່າຂ້ອຍຈະເຮັດໃຫ້ການຕິດຕັ້ງງ່າຍໃນຕອນເລີ່ມຕົ້ນ.

ສໍາລັບການຜະລິດແລະແມ້ກະທັ້ງຂັ້ນຕອນ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ເປີດໃຊ້ TLS ໃນ gRPC.

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

ວິທີນີ້ທ່ານຈະປົກປ້ອງຕົວທ່ານເອງຈາກການຮ້ອງຂໍທັງຫມົດໄປຫາ Tiller ຈາກພາຍນອກກຸ່ມ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບປະກັນຊ່ອງທາງການເຊື່ອມຕໍ່ກັບ Tiller, ພວກເຮົາໄດ້ສົນທະນາແລ້ວ RBAC ແລະດັດແປງສິດທິຂອງ Kubernetes apiserver, ຫຼຸດຜ່ອນໂດເມນທີ່ມັນສາມາດໂຕ້ຕອບໄດ້.

ໝວກກັນກະທົບ

ໃຫ້ເບິ່ງຢູ່ໃນແຜນວາດສຸດທ້າຍ. ມັນເປັນສະຖາປັດຕະຍະກໍາດຽວກັນກັບລູກສອນດຽວກັນ.

ດຽວນີ້ການເຊື່ອມຕໍ່ທັງໝົດສາມາດແຕ້ມເປັນສີຂຽວໄດ້ຢ່າງປອດໄພ:

• ສໍາລັບ Chart Repo ພວກເຮົາໃຊ້ TLS ຫຼື mTLS ແລະການກວດສອບພື້ນຖານ;
• mTLS ສໍາລັບ Tiller, ແລະມັນຖືກເປີດເຜີຍເປັນການບໍລິການ gRPC ກັບ TLS, ພວກເຮົາໃຊ້ໃບຢັ້ງຢືນ;
• ກຸ່ມໃຊ້ບັນຊີການບໍລິການພິເສດທີ່ມີພາລະບົດບາດ ແລະ RoleBinding. 

ພວກ​ເຮົາ​ໄດ້​ຮັບ​ປະ​ກັນ​ກຸ່ມ​ຢ່າງ​ຫຼວງ​ຫຼາຍ, ແຕ່​ບາງ​ຄົນ​ທີ່​ສະ​ຫຼາດ​ເວົ້າ​ວ່າ:

"ມີວິທີດຽວທີ່ປອດໄພແທ້ໆ - ຄອມພິວເຕີປິດ, ເຊິ່ງຕັ້ງຢູ່ໃນປ່ອງສີມັງແລະຖືກປົກປ້ອງໂດຍທະຫານ."

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

ໂບນັດ

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

ໃນ repository github.com/helm/charts ໃນປັດຈຸບັນມີປະມານ 300 ຕາຕະລາງແລະສອງສາຍນ້ໍາ: ຄວາມຫມັ້ນຄົງແລະ incubator. ໃຜກໍ່ຕາມທີ່ປະກອບສ່ວນຮູ້ຢ່າງສົມບູນວ່າມັນມີຄວາມຫຍຸ້ງຍາກແນວໃດທີ່ຈະໄດ້ຈາກ incubator ໄປສູ່ຄວາມຫມັ້ນຄົງ, ແລະວິທີການບິນອອກຈາກຄວາມຫມັ້ນຄົງແມ່ນງ່າຍດາຍ. ຢ່າງໃດກໍ່ຕາມ, ນີ້ບໍ່ແມ່ນເຄື່ອງມືທີ່ດີທີ່ສຸດທີ່ຈະຄົ້ນຫາຕາຕະລາງສໍາລັບ Prometheus ແລະສິ່ງໃດກໍ່ຕາມທີ່ທ່ານຕ້ອງການ, ສໍາລັບເຫດຜົນງ່າຍໆຫນຶ່ງ - ມັນບໍ່ແມ່ນປະຕູທີ່ທ່ານສາມາດຄົ້ນຫາແພັກເກັດໄດ້ຢ່າງສະດວກ.

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

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

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

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

ຄົນອື່ນ, ເຊັ່ນພວກເຮົາຢູ່ Chainstack, ໃຊ້ຖານຂໍ້ມູນທີ່ມີການຄຸ້ມຄອງເຊັ່ນ MySQL ຫຼື PostgreSQL ສໍາລັບເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາ. ນັ້ນແມ່ນເຫດຜົນທີ່ຖານຂໍ້ມູນຂອງພວກເຮົາຕັ້ງຢູ່ບ່ອນໃດຫນຶ່ງໃນເມຄ.

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

ມັນງ່າຍດາຍຫຼາຍ. ທ່ານສາມາດສອບຖາມ, ສໍາລັບການຍົກຕົວຢ່າງ, Managed MySQL ໃນ Azure ທີ່ມີລະດັບພື້ນຖານ (ອັນນີ້ສາມາດຕັ້ງຄ່າໄດ້). ການນໍາໃຊ້ Azure API, ຖານຂໍ້ມູນຈະຖືກສ້າງຂື້ນແລະກຽມພ້ອມສໍາລັບການນໍາໃຊ້. ທ່ານບໍ່ຈໍາເປັນຕ້ອງແຊກແຊງນີ້, plugin ຮັບຜິດຊອບສໍາລັບການນີ້. ຕົວຢ່າງ, OSBA (Azure plugin) ຈະສົ່ງຄືນຂໍ້ມູນປະຈໍາຕົວໃຫ້ກັບບໍລິການແລະສົ່ງຕໍ່ໃຫ້ Helm. ທ່ານຈະສາມາດໃຊ້ WordPress ກັບ MySQL ຟັງ, ບໍ່ຈັດການກັບຖານຂໍ້ມູນທີ່ຖືກຄຸ້ມຄອງທັງຫມົດແລະບໍ່ກັງວົນກ່ຽວກັບການບໍລິການຂອງລັດພາຍໃນ.

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

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

ອີກອັນຫນຶ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງແລ້ວແມ່ນ helm-gcs plugin, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານໃຊ້ Google-buckets (ການເກັບຮັກສາວັດຖຸ) ເພື່ອເກັບຮັກສາຕາຕະລາງ Helm.

ທ່ານຕ້ອງການພຽງແຕ່ສີ່ຄໍາສັ່ງເພື່ອເລີ່ມຕົ້ນການນໍາໃຊ້ມັນ:

1. ຕິດຕັ້ງ plugin;
2. ລິເລີ່ມມັນ;
3. ກໍານົດເສັ້ນທາງໄປຫາຖັງ, ເຊິ່ງຕັ້ງຢູ່ໃນ gcp;
4. ເຜີຍແຜ່ຕາຕະລາງໃນແບບມາດຕະຖານ.

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

ທາງເລືອກ

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

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

ສຸດທ້າຍມີການແກ້ໄຂ ກອບການດໍາເນີນການ, ຄວາມນິຍົມຂອງມັນແມ່ນການຂະຫຍາຍຕົວ.

Operator Framework ເປັນທາງເລືອກ Helm ອັນດັບຕົ້ນໆທີ່ຈະພິຈາລະນາ.

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

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

ນີ້ແມ່ນຕາຕະລາງສາຍຕາຂອງບ່ອນທີ່ທຸກສິ່ງທຸກຢ່າງຢູ່.

ໃນແກນ x ແມ່ນລະດັບຂອງການຄວບຄຸມສ່ວນຕົວຂອງທ່ານຕໍ່ກັບສິ່ງທີ່ເກີດຂຶ້ນ, ໃນແກນ y ແມ່ນລະດັບຄວາມເປັນກໍາເນີດຂອງ Kubernetes. Helm ລຸ້ນ 2 ຕົກຢູ່ບ່ອນໃດບ່ອນໜຶ່ງຢູ່ກາງ. ໃນ​ສະ​ບັບ 3​, ບໍ່​ໄດ້​ຢ່າງ​ຫຼວງ​ຫຼາຍ​, ແຕ່​ວ່າ​ທັງ​ສອງ​ການ​ຄວບ​ຄຸມ​ແລະ​ລະ​ດັບ​ຂອງ​ພື້ນ​ເມືອງ​ໄດ້​ຮັບ​ການ​ປັບ​ປຸງ​. ການແກ້ໄຂໃນລະດັບ Ksonnet ແມ່ນຍັງ inferior ເຖິງແມ່ນວ່າ Helm 2. ຢ່າງໃດກໍຕາມ, ພວກເຂົາເຈົ້າແມ່ນມີມູນຄ່າເບິ່ງເພື່ອຮູ້ວ່າສິ່ງອື່ນໃດໃນໂລກນີ້. ແນ່ນອນ, ຜູ້ຈັດການການຕັ້ງຄ່າຂອງທ່ານຈະຢູ່ພາຍໃຕ້ການຄວບຄຸມຂອງທ່ານ, ແຕ່ມັນບໍ່ແມ່ນແຫຼ່ງກໍາເນີດຂອງ Kubernetes ຢ່າງແທ້ຈິງ.

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

Extenders ພຽງແຕ່ປັບປຸງການຄວບຄຸມເລັກນ້ອຍ, ເສີມການເຮັດວຽກ, ຫຼືຕັດມຸມໃນທໍ່ CI / CD.

ອະນາຄົດຂອງ Helm

ຂ່າວດີແມ່ນວ່າ Helm 3 ກໍາລັງຈະມາເຖິງ, ຮຸ່ນ alpha ຂອງ Helm 3.0.0-alpha.2 ໄດ້ອອກແລ້ວ, ທ່ານສາມາດລອງມັນ. ມັນຂ້ອນຂ້າງຄົງທີ່, ແຕ່ການເຮັດວຽກຍັງຈໍາກັດ.

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

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

ຈະປາກົດຂຶ້ນ ສະຫນັບສະຫນູນສໍາລັບ repositories OCI ພື້ນເມືອງ (Open Container Initiative). ນີ້ແມ່ນການລິເລີ່ມອັນໃຫຍ່ຫຼວງ, ແລະ Helm ມີຄວາມສົນໃຈຕົ້ນຕໍເພື່ອປະກາດຕາຕະລາງຂອງຕົນ. ມັນມາຮອດຈຸດທີ່, ສໍາລັບການຍົກຕົວຢ່າງ, Docker Hub ສະຫນັບສະຫນູນມາດຕະຖານ OCI ຫຼາຍ. ຂ້ອຍບໍ່ເດົາ, ແຕ່ບາງທີຜູ້ໃຫ້ບໍລິການບ່ອນເກັບມ້ຽນ Docker ຄລາສສິກຈະເລີ່ມໃຫ້ໂອກາດເຈົ້າໃນການເປັນເຈົ້າພາບຕາຕະລາງ Helm ຂອງເຈົ້າ.

ເລື່ອງທີ່ຂັດແຍ້ງສໍາລັບຂ້ອຍແມ່ນ ສະຫນັບສະຫນູນ Lua, ເປັນເຄື່ອງຈັກແມ່ແບບສໍາລັບການຂຽນສະຄິບ. ຂ້ອຍບໍ່ແມ່ນແຟນໃຫຍ່ຂອງ Lua, ແຕ່ນີ້ຈະເປັນລັກສະນະທາງເລືອກຢ່າງສົມບູນ. ຂ້າພະເຈົ້າໄດ້ກວດເບິ່ງນີ້ 3 ເທື່ອ - ການນໍາໃຊ້ Lua ຈະບໍ່ຈໍາເປັນ. ດັ່ງນັ້ນ, ຜູ້ທີ່ຕ້ອງການທີ່ຈະສາມາດນໍາໃຊ້ Lua, ຜູ້ທີ່ມັກ Go, ເຂົ້າຮ່ວມ camp huge ຂອງພວກເຮົາແລະໃຊ້ go-tmpl ສໍາລັບການນີ້.

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

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

Helm 3 ຈະງ່າຍກວ່າ, ປອດໄພກວ່າ, ແລະມ່ວນກວ່າ, ບໍ່ແມ່ນຍ້ອນວ່າພວກເຮົາບໍ່ມັກ Helm 2, ແຕ່ເນື່ອງຈາກວ່າ Kubernetes ກາຍເປັນແບບພິເສດກວ່າ. ດັ່ງນັ້ນ, Helm ສາມາດນໍາໃຊ້ການພັດທະນາຂອງ Kubernetes ແລະສ້າງຜູ້ຈັດການທີ່ດີເລີດສໍາລັບ Kubernetes ໃນມັນ.

ຂ່າວດີອີກອັນຫນຶ່ງແມ່ນວ່າ DevOpsConf Alexander Khayorov ຈະບອກທ່ານວ່າ, ຕູ້ຄອນເທນເນີຈະປອດໄພບໍ? ໃຫ້ພວກເຮົາເຕືອນທ່ານວ່າກອງປະຊຸມກ່ຽວກັບການເຊື່ອມໂຍງການພັດທະນາ, ການທົດສອບແລະຂະບວນການປະຕິບັດງານຈະຈັດຂຶ້ນໃນ Moscow ວັນທີ 30 ກັນຍາ ແລະ ວັນທີ 1 ຕຸລາ. ເຈົ້າຍັງສາມາດເຮັດໄດ້ຈົນຮອດວັນທີ 20 ສິງຫາ ສົ່ງບົດລາຍງານ ແລະບອກພວກເຮົາກ່ຽວກັບປະສົບການຂອງທ່ານກັບການແກ້ໄຂ ຫນຶ່ງໃນຈໍານວນຫຼາຍ ວຽກງານຂອງວິທີການ DevOps.

ຕິດຕາມຈຸດກວດກາກອງປະຊຸມແລະຂ່າວໄດ້ທີ່ ບັນຊີລາຍຊື່ທາງໄປສະນີ и ຊ່ອງທາງໂທລະເລກ.

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