GitOps: ການປຽບທຽບວິທີການດຶງແລະ Push

ຫມາຍ​ເຫດ​. ແປ.: ໃນຊຸມຊົນ Kubernetes, ແນວໂນ້ມທີ່ເອີ້ນວ່າ GitOps ກໍາລັງໄດ້ຮັບຄວາມນິຍົມຢ່າງຈະແຈ້ງ, ດັ່ງທີ່ພວກເຮົາໄດ້ເຫັນສ່ວນຕົວ, ການ​ຢ້ຽມ​ຢາມ KubeCon Europe 2019. ໄລຍະນີ້ແມ່ນຂ້ອນຂ້າງບໍ່ດົນມານີ້ ປະດິດ ໂດຍຫົວຫນ້າ Weaveworks - Alexis Richardson - ແລະຫມາຍຄວາມວ່າການນໍາໃຊ້ເຄື່ອງມືທີ່ຄຸ້ນເຄີຍກັບນັກພັດທະນາ (ຕົ້ນຕໍແມ່ນ Git, ດັ່ງນັ້ນຊື່) ເພື່ອແກ້ໄຂບັນຫາການດໍາເນີນງານ. ໂດຍສະເພາະ, ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບການດໍາເນີນງານຂອງ Kubernetes ໂດຍການເກັບຮັກສາການຕັ້ງຄ່າຂອງມັນຢູ່ໃນ Git ແລະເປີດຕົວການປ່ຽນແປງຂອງກຸ່ມໂດຍອັດຕະໂນມັດ. Matthias Jg ເວົ້າກ່ຽວກັບສອງວິທີການສໍາລັບການເປີດຕົວນີ້ໃນບົດຄວາມນີ້.

ໃນປີທີ່ຜ່ານມາ (ໃນ​ຄວາມ​ເປັນ​ຈິງ, ນີ້​ໄດ້​ເກີດ​ຂຶ້ນ​ຢ່າງ​ເປັນ​ທາງ​ການ​ໃນ​ເດືອນ​ສິງ​ຫາ 2017 - ປະ​ມານ​ແປ.) ມີວິທີການໃຫມ່ໃນການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກໃນ Kubernetes. ມັນຖືກເອີ້ນວ່າ GitOps, ແລະມັນອີງໃສ່ແນວຄວາມຄິດພື້ນຖານທີ່ສະບັບຂອງການນໍາໃຊ້ຖືກຕິດຕາມຢູ່ໃນສະພາບແວດລ້ອມທີ່ປອດໄພຂອງບ່ອນເກັບມ້ຽນ Git.

ຂໍ້ໄດ້ປຽບຕົ້ນຕໍຂອງວິທີການນີ້ແມ່ນມີດັ່ງນີ້::

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

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

ວິທີການນຳໃຊ້

ໃນຊຸມປີມໍ່ໆມານີ້, ວິທີການແລະເຄື່ອງມືຕ່າງໆສໍາລັບການນໍາໃຊ້ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນໃນ Kubernetes:

1. ອີງໃສ່ແມ່ແບບ Kubernetes/ປັບແຕ່ງເອງ. ນີ້ແມ່ນວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະນຳໃຊ້ແອັບພລິເຄຊັນເທິງ Kubernetes. ນັກພັດທະນາສ້າງໄຟລ໌ YAML ພື້ນຖານແລະນໍາໃຊ້ພວກມັນ. ເພື່ອກໍາຈັດການຂຽນແບບເດີມໃຫມ່ຢ່າງຕໍ່ເນື່ອງ, Kustomize ໄດ້ຖືກພັດທະນາ (ມັນປ່ຽນແມ່ແບບ Kubernetes ເປັນໂມດູນ). ຫມາຍ​ເຫດ​. ແປ.: Kustomize ໄດ້ຖືກປະສົມປະສານເຂົ້າໃນ kubectl ກັບ ການປ່ອຍ Kubernetes 1.14.
2. ຕາຕະລາງ Helm. ຕາຕະລາງ Helm ຊ່ວຍໃຫ້ທ່ານສ້າງຊຸດຂອງແມ່ແບບ, ຖັງບັນຈຸ init, sidecars, ແລະອື່ນໆ, ເຊິ່ງຖືກນໍາໃຊ້ເພື່ອນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ມີທາງເລືອກການປັບແຕ່ງທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍກ່ວາໃນວິທີການທີ່ອີງໃສ່ແມ່ແບບ. ວິທີການນີ້ແມ່ນອີງໃສ່ໄຟລ໌ YAML ທີ່ເປັນແມ່ແບບ. Helm ຕື່ມຂໍ້ມູນໃສ່ພວກມັນດ້ວຍພາລາມິເຕີຕ່າງໆ ແລະຫຼັງຈາກນັ້ນສົ່ງພວກມັນໄປຫາ Tiller, ອົງປະກອບຂອງກຸ່ມທີ່ນຳໃຊ້ພວກມັນໃຫ້ກັບກຸ່ມ ແລະອະນຸຍາດໃຫ້ມີການອັບເດດ ແລະ rollbacks. ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າ Helm ເປັນສິ່ງຈໍາເປັນພຽງແຕ່ໃສ່ຄ່າທີ່ຕ້ອງການເຂົ້າໄປໃນແມ່ແບບແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ພວກມັນໃນແບບດຽວກັນກັບມັນເຮັດໃນວິທີການແບບດັ້ງເດີມ. (ອ່ານເພີ່ມເຕີມກ່ຽວກັບວິທີການເຮັດວຽກທັງຫມົດແລະວິທີທີ່ທ່ານສາມາດນໍາໃຊ້ມັນຢູ່ໃນຂອງພວກເຮົາ ບົດຄວາມໂດຍ Helm — ປະ​ມານ​. ແປ.). ມີແຜນວາດ Helm ທີ່ກຽມພ້ອມແລ້ວຫຼາກຫຼາຍຊະນິດທີ່ກວມເອົາໜ້າວຽກທີ່ຫຼາກຫຼາຍ.
3. ເຄື່ອງມືທາງເລືອກ. ມີເຄື່ອງມືທາງເລືອກຫຼາຍ. ສິ່ງທີ່ພວກເຂົາທັງຫມົດມີຄືກັນແມ່ນວ່າພວກເຂົາປ່ຽນບາງໄຟລ໌ແມ່ແບບເຂົ້າໄປໃນໄຟລ໌ YAML ທີ່ສາມາດອ່ານ Kubernetes ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ພວກມັນ.

ໃນການເຮັດວຽກຂອງພວກເຮົາ, ພວກເຮົາໃຊ້ຕາຕະລາງ Helm ຢ່າງຕໍ່ເນື່ອງສໍາລັບເຄື່ອງມືທີ່ສໍາຄັນ (ຍ້ອນວ່າພວກເຂົາມີຫຼາຍຢ່າງພ້ອມແລ້ວ, ເຊິ່ງເຮັດໃຫ້ຊີວິດງ່າຍຂຶ້ນຫຼາຍ) ແລະໄຟລ໌ Kubernetes YAML "ບໍລິສຸດ" ສໍາລັບການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາເອງ.

ດຶງ & ຍູ້

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

NB! ຜົນປະໂຫຍດທັງຫມົດຂອງການນໍາໃຊ້ GitOps ຍັງຄົງຄືກັນສໍາລັບທັງສອງວິທີການ.

ດຶງເອົາວິທີການໂດຍອີງໃສ່

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

Pros:

1. ບໍ່ມີລູກຄ້າພາຍນອກມີສິດທີ່ຈະປ່ຽນແປງກຸ່ມໄດ້; ການປັບປຸງທັງໝົດຈະຖືກເຜີຍແຜ່ຈາກພາຍໃນ.
2. ບາງເຄື່ອງມືຍັງອະນຸຍາດໃຫ້ທ່ານສາມາດ synchronize ການປັບປຸງຕາຕະລາງ Helm ແລະເຊື່ອມຕໍ່ໃຫ້ເຂົາເຈົ້າກັບກຸ່ມ.
3. Docker Registry ສາມາດສະແກນຫາເວີຊັນໃໝ່ໄດ້. ຖ້າມີຮູບພາບໃຫມ່, ພື້ນທີ່ເກັບຂໍ້ມູນ Git ແລະການນໍາໃຊ້ຈະຖືກປັບປຸງເປັນເວີຊັນໃຫມ່.
4. ເຄື່ອງມືດຶງສາມາດໄດ້ຮັບການແຈກຢາຍໃນທົ່ວ namespaces ທີ່ແຕກຕ່າງກັນທີ່ມີບ່ອນເກັບ Git ແລະການອະນຸຍາດທີ່ແຕກຕ່າງກັນ. ຂໍຂອບໃຈກັບນີ້, ຮູບແບບ multitenant ສາມາດຖືກນໍາໃຊ້. ຕົວຢ່າງ, ທີມງານ A ອາດຈະໃຊ້ namespace A, ທີມງານ B ອາດຈະໃຊ້ namespace B, ແລະທີມງານໂຄງສ້າງພື້ນຖານອາດຈະໃຊ້ພື້ນທີ່ທົ່ວໂລກ.
5. ຕາມກົດລະບຽບ, ເຄື່ອງມືແມ່ນມີນ້ໍາຫນັກເບົາຫຼາຍ.
6. ປະສົມປະສານກັບເຄື່ອງມືເຊັ່ນ: ຜູ້ປະກອບການ Bitnami ປິດລັບ, ຄວາມລັບສາມາດຖືກເກັບໄວ້ໃນລະຫັດລັບໃນ Git repository ແລະດຶງຂໍ້ມູນພາຍໃນກຸ່ມ.
7. ບໍ່ມີການເຊື່ອມຕໍ່ກັບທໍ່ CD ນັບຕັ້ງແຕ່ການນໍາໄປໃຊ້ເກີດຂຶ້ນພາຍໃນກຸ່ມ.

Минусы:

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

ວິທີການຊຸກຍູ້ໂດຍອີງໃສ່

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

ຄວາມຄິດເຫັນ:

1. ຄວາມປອດໄພຖືກກໍານົດໂດຍ Git repository ແລະການກໍ່ສ້າງທໍ່.
2. ການນຳໃຊ້ຕາຕະລາງ Helm ແມ່ນງ່າຍຂຶ້ນ ແລະຮອງຮັບ Helm plugins.
3. ຄວາມລັບແມ່ນງ່າຍຕໍ່ການຄຸ້ມຄອງເພາະວ່າຄວາມລັບສາມາດຖືກນໍາໃຊ້ໃນທໍ່ແລະຍັງສາມາດຖືກເກັບໄວ້ໃນລະຫັດລັບໃນ Git (ຂຶ້ນກັບຄວາມມັກຂອງຜູ້ໃຊ້).
4. ບໍ່ມີການເຊື່ອມຕໍ່ກັບເຄື່ອງມືສະເພາະໃດຫນຶ່ງ, ເນື່ອງຈາກວ່າປະເພດໃດກໍ່ສາມາດນໍາໃຊ້ໄດ້.
5. ການປັບປຸງສະບັບຕູ້ຄອນເທນເນີສາມາດເລີ່ມຕົ້ນໄດ້ໂດຍທໍ່ກໍ່ສ້າງ.

Минусы:

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

ຜົນໄດ້ຮັບ: ຍູ້ຫຼືດຶງ?

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

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

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

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

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

PS ຫມາຍເຫດຈາກນັກແປ

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

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

ພວກເຮົາໄດ້ພະຍາຍາມທັງສອງແບບແລະໄດ້ສະຫຼຸບດຽວກັນກັບຜູ້ຂຽນຂອງບົດຄວາມ:

1. ຮູບແບບການດຶງແມ່ນເຫມາະສົມສໍາລັບພວກເຮົາໃນການຈັດຕັ້ງການປັບປຸງອົງປະກອບຂອງລະບົບໃນກຸ່ມຈໍານວນຫລາຍ (ເບິ່ງ. ບົດຄວາມກ່ຽວກັບ addon-operator).
2. ຮູບແບບການຊຸກຍູ້ໂດຍອີງໃສ່ GitLab CI ແມ່ນເຫມາະສົມດີສໍາລັບການເປີດຕົວຄໍາຮ້ອງສະຫມັກໂດຍໃຊ້ຕາຕະລາງ Helm. ໃນເວລາດຽວກັນ, ການເປີດຕົວຂອງການນໍາໃຊ້ພາຍໃນທໍ່ແມ່ນຕິດຕາມກວດກາໂດຍໃຊ້ເຄື່ອງມື werf. ໂດຍວິທີທາງການ, ໃນສະພາບການຂອງໂຄງການນີ້ຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຍິນ "GitOps" ຄົງທີ່ໃນເວລາທີ່ພວກເຮົາສົນທະນາບັນຫາທີ່ຮີບດ່ວນຂອງວິສະວະກອນ DevOps ຢູ່ທີ່ຈຸດຢືນຂອງພວກເຮົາຢູ່ KubeCon Europe'19.

PPS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ເຄັດລັບ ແລະເຄັດລັບ Kubernetes: ການໂອນຊັບພະຍາກອນທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມໄປຫາການຈັດການ Helm 2"
• «ຂໍແນະນຳ kubedog, ຫ້ອງສະໝຸດສຳລັບການຕິດຕາມຊັບພະຍາກອນ Kubernetes"
• «ການ​ຂະ​ຫຍາຍ​ແລະ​ເສີມ Kubernetes (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)"
• «ຄໍາແນະນໍາສໍາລັບການສ້າງຂະບວນການເຮັດວຽກທີ່ກໍາຫນົດເອງໃນ GitLab CI".

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ເຈົ້າໃຊ້ GitOps ບໍ?

• ແມ່ນແລ້ວ, ດຶງວິທີການ

• ແມ່ນແລ້ວ, ຍູ້

• ແມ່ນແລ້ວ, ດຶງ + ຍູ້

• ແມ່ນແລ້ວ, ບາງສິ່ງບາງຢ່າງອື່ນ

• ບໍ່​ມີ

30 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 10 ຜູ້ໃຊ້ງົດ.

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