GitOps ແມ່ນຫຍັງ?

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

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

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

ພວກ​ເຮົາ​ຮູ້​ບໍ່​ດົນ​ວ່າ​ຕ້ອງ​ມີ​ລາຍ​ລະ​ອຽດ​ໃຫມ່​, ສະ​ເຫນີ​ໃຫ້​:

1. ຈໍານວນຂະຫນາດໃຫຍ່ຂອງຕົວຢ່າງແລະເລື່ອງ;
2. ຄໍານິຍາມສະເພາະຂອງ GitOps;
3. ການປຽບທຽບກັບການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງແບບດັ້ງເດີມ.

ໃນບົດຄວາມນີ້ພວກເຮົາໄດ້ພະຍາຍາມກວມເອົາຫົວຂໍ້ທັງຫມົດເຫຼົ່ານີ້. ມັນສະຫນອງການແນະນໍາທີ່ປັບປຸງໃຫ້ທັນກັບ GitOps ແລະການພັດທະນາແລະທັດສະນະຂອງ CI/CD. ພວກເຮົາເນັ້ນໃສ່ Kubernetes ຕົ້ນຕໍ, ເຖິງແມ່ນວ່າຕົວແບບສາມາດເປັນແບບທົ່ວໄປໄດ້.

ພົບກັບ GitOps

ຈິນຕະນາການ Alice. ນາງດໍາເນີນການປະກັນໄພຄອບຄົວ, ເຊິ່ງສະຫນອງການປະກັນໄພສຸຂະພາບ, ລົດໃຫຍ່, ເຮືອນ, ແລະການເດີນທາງກັບປະຊາຊົນຜູ້ທີ່ຫຍຸ້ງເກີນໄປທີ່ຈະຄິດອອກ ins ແລະ outs ຂອງສັນຍາດ້ວຍຕົນເອງ. ທຸລະກິດຂອງນາງໄດ້ເລີ່ມຕົ້ນເປັນໂຄງການຂ້າງຄຽງໃນເວລາທີ່ Alice ກໍາລັງເຮັດວຽກຢູ່ທະນາຄານເປັນນັກວິທະຍາສາດຂໍ້ມູນ. ມື້ຫນຶ່ງນາງຮູ້ວ່ານາງສາມາດນໍາໃຊ້ລະບົບຄອມພິວເຕີຂັ້ນສູງເພື່ອວິເຄາະຂໍ້ມູນແລະສ້າງຊຸດປະກັນໄພຢ່າງມີປະສິດທິພາບ. ນັກລົງທຶນໄດ້ໃຫ້ທຶນແກ່ໂຄງການ, ແລະໃນປັດຈຸບັນບໍລິສັດຂອງນາງນໍາເງິນຫຼາຍກວ່າ 20 ລ້ານໂດລາຕໍ່ປີແລະກໍາລັງເຕີບໂຕຢ່າງໄວວາ. ປະຈຸບັນ, ມີພະນັກງານ 180 ຄົນໃນຫຼາຍຕຳແໜ່ງ. ນີ້ປະກອບມີທີມງານເຕັກໂນໂລຢີທີ່ພັດທະນາ, ຮັກສາເວັບໄຊທ໌, ຖານຂໍ້ມູນແລະການວິເຄາະຖານລູກຄ້າ. ທີມງານຂອງ 60 ຄົນແມ່ນນໍາພາໂດຍ Bob, ຜູ້ອໍານວຍການດ້ານວິຊາການຂອງບໍລິສັດ.

ທີມງານຂອງ Bob ນໍາໃຊ້ລະບົບການຜະລິດຢູ່ໃນຄລາວ. ແອັບພລິເຄຊັນຫຼັກຂອງພວກເຂົາແລ່ນຢູ່ໃນ GKE, ໃຊ້ປະໂຫຍດຈາກ Kubernetes ໃນ Google Cloud. ນອກຈາກນັ້ນ, ພວກເຂົາໃຊ້ຂໍ້ມູນຕ່າງໆແລະເຄື່ອງມືການວິເຄາະໃນການເຮັດວຽກຂອງພວກເຂົາ.

ການປະກັນໄພຄອບຄົວບໍ່ໄດ້ກໍານົດໃຫ້ໃຊ້ຕູ້ຄອນເທນເນີ, ແຕ່ຖືກຕິດຢູ່ໃນຄວາມກະຕືລືລົ້ນຂອງ Docker. ບໍລິສັດໄດ້ຄົ້ນພົບໃນໄວໆນີ້ວ່າ GKE ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການນໍາໃຊ້ກຸ່ມເພື່ອທົດສອບຄຸນສົມບັດໃຫມ່. Jenkins ສໍາລັບ CI ແລະ Quay ໄດ້ຖືກເພີ່ມເຂົ້າໃນການຈັດຕັ້ງການລົງທະບຽນບັນຈຸ, scripts ໄດ້ຖືກຂຽນສໍາລັບ Jenkins ທີ່ pushed ບັນຈຸໃຫມ່ແລະການຕັ້ງຄ່າ GKE.

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

ຫຼັງຈາກນັ້ນ, ພວກເຂົາເຈົ້າໄດ້ຮຽນຮູ້ກ່ຽວກັບ GitOps. ການຕັດສິນໃຈນີ້ໄດ້ກາຍເປັນສິ່ງທີ່ພວກເຂົາຕ້ອງການເພື່ອກ້າວໄປຂ້າງຫນ້າຢ່າງໝັ້ນໃຈ.

Alice ແລະ Bob ໄດ້ຍິນກ່ຽວກັບ Git, DevOps, ແລະໂຄງສ້າງພື້ນຖານເປັນລະຫັດການເຮັດວຽກສໍາລັບປີ. ສິ່ງທີ່ເປັນເອກະລັກກ່ຽວກັບ GitOps ແມ່ນວ່າມັນນໍາເອົາຊຸດການປະຕິບັດທີ່ດີທີ່ສຸດ - ທັງແນ່ນອນແລະມາດຕະຖານ - ສໍາລັບການປະຕິບັດແນວຄວາມຄິດເຫຼົ່ານີ້ໃນສະພາບການຂອງ Kubernetes. ຫົວຂໍ້ນີ້ ເພີ່ມຂຶ້ນເລື້ອຍໆ, ລວມທັງໃນ ບລັອກ Weaveworks.

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

• ພົບວ່າຜົນຜະລິດຂອງທີມງານເພີ່ມຂຶ້ນສອງເທົ່າໂດຍບໍ່ມີໃຜບ້າ;
• ຢຸດໃຫ້ບໍລິການສະຄຣິບ. ແທນທີ່ຈະ, ເຂົາເຈົ້າໃນປັດຈຸບັນສາມາດສຸມໃສ່ລັກສະນະໃຫມ່ແລະປັບປຸງວິທີການວິສະວະກໍາ - ສໍາລັບການຍົກຕົວຢ່າງ, ແນະນໍາ canary rollouts ແລະປັບປຸງການທົດສອບ;
• ພວກເຮົາໄດ້ປັບປຸງຂະບວນການນຳໃຊ້ເພື່ອໃຫ້ມັນບໍ່ຄ່ອຍແຕກ;
• ໄດ້ຮັບໂອກາດໃນການຟື້ນຟູການນໍາໄປໃຊ້ຫຼັງຈາກຄວາມລົ້ມເຫລວບາງສ່ວນໂດຍບໍ່ມີການແຊກແຊງຄູ່ມື;
• ຊື້​ນໍາ​ໃຊ້​оຄວາມຫມັ້ນໃຈຫຼາຍກວ່າເກົ່າໃນລະບົບການຈັດສົ່ງ. Alice ແລະ Bob ຄົ້ນພົບວ່າພວກເຂົາສາມາດແຍກທີມງານອອກເປັນທີມ microservice ທີ່ເຮັດວຽກຂະຫນານ;
• ສາມາດເຮັດໃຫ້ມີການປ່ຽນແປງ 30-50 ໂຄງການທຸກໆມື້ໂດຍຜ່ານຄວາມພະຍາຍາມຂອງແຕ່ລະກຸ່ມແລະພະຍາຍາມເຕັກນິກໃຫມ່;
• ມັນງ່າຍທີ່ຈະດຶງດູດຜູ້ພັດທະນາໃຫມ່ໃຫ້ກັບໂຄງການ, ຜູ້ທີ່ມີໂອກາດທີ່ຈະອອກການປັບປຸງການຜະລິດໂດຍໃຊ້ຄໍາຮ້ອງຂໍດຶງພາຍໃນສອງສາມຊົ່ວໂມງ;
• ຜ່ານການກວດສອບໄດ້ຢ່າງງ່າຍດາຍໃນຂອບຂອງ SOC2 (ສໍາລັບການປະຕິບັດຕາມຂອງຜູ້ໃຫ້ບໍລິການທີ່ມີຄວາມຕ້ອງການການຄຸ້ມຄອງຂໍ້ມູນທີ່ປອດໄພ; ອ່ານເພີ່ມເຕີມ, ສໍາລັບການຍົກຕົວຢ່າງ, ທີ່ນີ້ — ປະ​ມານ​. ແປ.).

ເກີດ​ຫຍັງ​ຂຶ້ນ?

GitOps ແມ່ນສອງຢ່າງ:

1. ຮູບແບບການດໍາເນີນງານສໍາລັບ Kubernetes ແລະ cloud native. ມັນສະຫນອງຊຸດຂອງການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການນໍາໄປໃຊ້, ການຄຸ້ມຄອງ, ແລະການຕິດຕາມກຸ່ມບັນຈຸແລະຄໍາຮ້ອງສະຫມັກ. ຄໍານິຍາມທີ່ສະຫງ່າງາມໃນຮູບແບບ ຫນຶ່ງ slide ຈາກ Luis Faceira:
2. ເສັ້ນທາງໄປສູ່ການສ້າງສະພາບແວດລ້ອມການຈັດການແອັບພລິເຄຊັນທີ່ເນັ້ນໃສ່ນັກພັດທະນາ. ພວກເຮົານໍາໃຊ້ຂັ້ນຕອນການເຮັດວຽກ Git ກັບທັງການດໍາເນີນງານແລະການພັດທະນາ. ກະລຸນາຮັບຊາບວ່ານີ້ບໍ່ແມ່ນພຽງແຕ່ກ່ຽວກັບ Git push, ແຕ່ກ່ຽວກັບການຈັດຊຸດເຄື່ອງມື CI/CD ແລະ UI/UX ທັງໝົດ.

ສອງສາມຄໍາກ່ຽວກັບ Git

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

Kubernetes ເຮັດວຽກແນວໃດ

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

Kubernetes ໃຫ້ຜູ້ໃຊ້ຫຍັງ?

ນີ້ແມ່ນບາງລັກສະນະຕົ້ນຕໍ:

1. ໃນຮູບແບບ Kubernetes, ທຸກສິ່ງທຸກຢ່າງສາມາດຖືກອະທິບາຍໃນຮູບແບບການປະກາດ.
2. ເຊີບເວີ Kubernetes API ຮັບເອົາການປະກາດນີ້ເປັນການປ້ອນຂໍ້ມູນ ແລະຫຼັງຈາກນັ້ນພະຍາຍາມຢ່າງຕໍ່ເນື່ອງເພື່ອນໍາເອົາກຸ່ມເຂົ້າໄປໃນສະຖານະທີ່ອະທິບາຍໄວ້ໃນການປະກາດ.
3. ຖະແຫຼງການແມ່ນພຽງພໍເພື່ອອະທິບາຍ ແລະຈັດການວຽກທີ່ຫຼາກຫຼາຍ—“ແອັບພລິເຄຊັນ.”
4. ດັ່ງນັ້ນ, ການປ່ຽນແປງຂອງແອັບພລິເຄຊັນ ແລະກຸ່ມເກີດຂຶ້ນເນື່ອງຈາກ:
   • ການປ່ຽນແປງໃນຮູບພາບບັນຈຸ;
   • ການປ່ຽນແປງສະເພາະການປະກາດ;
   • ຄວາມຜິດພາດໃນສະພາບແວດລ້ອມ - ຕົວຢ່າງ, ຕູ້ຄອນເທນເນີ crashes.

ຄວາມສາມາດບົ່ມຊ້ອນທີ່ຍິ່ງໃຫຍ່ຂອງ Kubernetes

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

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

GitOps ເຮັດວຽກແນວໃດ

ພວກເຮົາໄດ້ຮຽນຮູ້ພຽງພໍກ່ຽວກັບ Kubernetes ເພື່ອອະທິບາຍວິທີການເຮັດວຽກຂອງ GitOps.

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

ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າພວກເຮົາເຫັນວ່າການປັບປຸງແຕ່ລະຄັ້ງສິ້ນສຸດລົງດ້ວຍການປ່ຽນແປງໄຟລ໌ການຕັ້ງຄ່າແລະ Git repositories. ການປ່ຽນແປງເຫຼົ່ານີ້ຕໍ່ Git ເຮັດໃຫ້ "ຕົວປະຕິບັດການ GitOps" ປັບປຸງກຸ່ມ:

1. ຂະ​ບວນ​ການ​ເຮັດ​ວຽກ​: ".Jenkins ສ້າງ - ສາຂາຕົ້ນສະບັບ".
ລາຍການໜ້າວຽກ:

• Jenkins pushes tagged ຮູບພາບໄປ Quay;
• Jenkins pushes config and Helm charts to the master bucket;
• ຟັງຊັນຄລາວຄັດລອກການຕັ້ງຄ່າແລະຕາຕະລາງຈາກຖັງເກັບມ້ຽນຫຼັກໄປຫາບ່ອນເກັບມ້ຽນ Git ແມ່ບົດ;
• ຜູ້ປະກອບການ GitOps ປັບປຸງກຸ່ມ.

2. Jenkins ສ້າງ - ປ່ອຍຫຼືສາຂາການແກ້ໄຂດ່ວນ:

• Jenkins ຍູ້ຮູບ untagged ໄປ Quay;
• Jenkins pushes config and Helm charts to the staging storage bucket;
• ຟັງຊັນຄລາວຄັດລອກການຕັ້ງຄ່າແລະຕາຕະລາງຈາກ bucket ການເກັບຮັກສາຂັ້ນຕອນໄປຫາບ່ອນເກັບມ້ຽນ Git;
• ຜູ້ປະກອບການ GitOps ປັບປຸງກຸ່ມ.

3. Jenkins ສ້າງ - ພັດທະນາຫຼືສາຂາຄຸນນະສົມບັດ:

• Jenkins ຍູ້ຮູບ untagged ໄປ Quay;
• Jenkins pushes config ແລະ Helm charts ເຂົ້າໄປໃນ bucket ພັດທະນາ;
• ຟັງຊັນຄລາວຄັດລອກການຕັ້ງຄ່າແລະຕາຕະລາງຈາກ bucket ພັດທະນາໄປຫາບ່ອນເກັບມ້ຽນ Git ພັດທະນາ;
• ຜູ້ປະກອບການ GitOps ປັບປຸງກຸ່ມ.

4. ກຳລັງເພີ່ມລູກຄ້າໃໝ່:

• ຜູ້ຈັດການ ຫຼືຜູ້ບໍລິຫານ (LCM/ops) ໂທຫາ Gradle ເພື່ອນຳໃຊ້ ແລະ ຕັ້ງຄ່າຕົວດຸ່ນດ່ຽງການໂຫຼດເຄືອຂ່າຍ (NLBs);
• LCM/ops ຫມັ້ນສັນຍາການຕັ້ງຄ່າໃຫມ່ເພື່ອກະກຽມການນໍາໃຊ້ສໍາລັບການອັບເດດ;
• ຜູ້ປະກອບການ GitOps ປັບປຸງກຸ່ມ.

ລາຍລະອຽດສັ້ນໆຂອງ GitOps

1. ອະທິບາຍສະຖານະທີ່ຕ້ອງການຂອງລະບົບທັງຫມົດໂດຍໃຊ້ການປະກາດສະເພາະສໍາລັບແຕ່ລະສະພາບແວດລ້ອມ (ໃນເລື່ອງຂອງພວກເຮົາ, ທີມງານຂອງ Bob ກໍານົດການຕັ້ງຄ່າລະບົບທັງຫມົດໃນ Git).
   • Git repository ແມ່ນແຫຼ່ງດຽວຂອງຄວາມຈິງກ່ຽວກັບສະຖານະທີ່ຕ້ອງການຂອງລະບົບທັງຫມົດ.
   • ການປ່ຽນແປງທັງຫມົດຕໍ່ກັບລັດທີ່ຕ້ອງການແມ່ນເຮັດຜ່ານຄໍາຫມັ້ນສັນຍາໃນ Git.
   • ຕົວກໍານົດການຂອງກຸ່ມທີ່ຕ້ອງການທັງໝົດແມ່ນສາມາດສັງເກດໄດ້ໃນກຸ່ມຕົວມັນເອງ. ດ້ວຍ​ວິທີ​ນີ້​ເຮົາ​ສາມາດ​ກຳນົດ​ໄດ້​ວ່າ​ມັນ​ເຂົ້າກັນ​ໄດ້​ຫຼື​ບໍ່ (converge, ປ່ຽນໃຈເຫລື້ອມໃສ) ຫຼື​ແຕກ​ຕ່າງ (diverge​, ແຍກ) ລັດທີ່ຕ້ອງການແລະສັງເກດເຫັນ.
2. ຖ້າລັດທີ່ຕ້ອງການແລະສັງເກດເຫັນແຕກຕ່າງກັນ, ຫຼັງຈາກນັ້ນ:
   • ມີກົນໄກ convergence ທີ່ທັນທີຫຼືຫຼັງຈາກນັ້ນອັດຕະໂນມັດ synchronizes ເປົ້າຫມາຍແລະລັດທີ່ສັງເກດເຫັນ. ພາຍໃນກຸ່ມ, Kubernetes ເຮັດສິ່ງນີ້.
   • ຂະບວນການເລີ່ມຕົ້ນທັນທີດ້ວຍການເຕືອນ "ການປ່ຽນແປງທີ່ຫມັ້ນສັນຍາ".
   • ຫຼັງຈາກໄລຍະເວລາທີ່ສາມາດກໍານົດໄດ້, ການແຈ້ງເຕືອນ "ຄວາມແຕກຕ່າງ" ສາມາດຖືກສົ່ງໄປຖ້າລັດແຕກຕ່າງກັນ.
3. ດ້ວຍວິທີນີ້, ທຸກໆຄໍາຫມັ້ນສັນຍາໃນ Git ເຮັດໃຫ້ເກີດການອັບເດດທີ່ສາມາດຢືນຢັນໄດ້ແລະບໍ່ມີທ່າແຮງຕໍ່ກັບກຸ່ມ.
   • Rollback ແມ່ນ convergence ກັບລັດທີ່ຕ້ອງການກ່ອນຫນ້ານີ້.
4. ການ​ເຂົ້າ​ຮ່ວມ​ແມ່ນ​ສຸດ​ທ້າຍ. ການປະກົດຕົວຂອງມັນໄດ້ຖືກຊີ້ບອກໂດຍ:
   • ບໍ່ມີການແຈ້ງເຕືອນທີ່ແຕກຕ່າງກັນສໍາລັບໄລຍະເວລາທີ່ແນ່ນອນ.
   • ການແຈ້ງເຕືອນ "converged" (ເຊັ່ນ: webhook, Git writeback event).

ຄວາມແຕກຕ່າງແມ່ນຫຍັງ?

ໃຫ້ເຮັດຊ້ໍາອີກຄັ້ງ: ຄຸນສົມບັດຂອງກຸ່ມທີ່ຕ້ອງການທັງໝົດຈະຕ້ອງສາມາດສັງເກດໄດ້ຢູ່ໃນກຸ່ມຕົວມັນເອງ.

ບາງຕົວຢ່າງຂອງຄວາມແຕກຕ່າງ:

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

ກົນໄກການໂຮມກັນແມ່ນຫຍັງ?

ສອງສາມຕົວຢ່າງ:

• ສໍາລັບຕູ້ຄອນເທນເນີ ແລະກຸ່ມ, ກົນໄກການໂຮມແມ່ນສະໜອງໃຫ້ໂດຍ Kubernetes.
• ກົນໄກດຽວກັນສາມາດຖືກນໍາໃຊ້ເພື່ອຈັດການຄໍາຮ້ອງສະຫມັກແລະການອອກແບບທີ່ອີງໃສ່ Kubernetes (ເຊັ່ນ: Istio ແລະ Kubeflow).
• ກົນໄກການຈັດການປະຕິສໍາພັນການດໍາເນີນງານລະຫວ່າງ Kubernetes, ພື້ນທີ່ເກັບຮູບພາບແລະ Git ສະຫນອງ ຜູ້ປະກອບການ GitOps Weave Flux, ຊຶ່ງເປັນສ່ວນຫນຶ່ງ Weave Cloud.
• ສໍາລັບເຄື່ອງຈັກພື້ນຖານ, ກົນໄກການ convergence ຕ້ອງເປັນການປະກາດແລະເປັນເອກະລາດ. ຈາກປະສົບການຂອງພວກເຮົາເອງພວກເຮົາສາມາດເວົ້າໄດ້ວ່າ Terraform ໃກ້ທີ່ສຸດກັບຄໍານິຍາມນີ້, ແຕ່ຍັງຕ້ອງການການຄວບຄຸມຂອງມະນຸດ. ໃນຄວາມຫມາຍນີ້, GitOps ຂະຫຍາຍປະເພນີຂອງໂຄງສ້າງພື້ນຖານເປັນລະຫັດ.

GitOps ປະສົມປະສານ Git ກັບເຄື່ອງຈັກ convergence ທີ່ດີເລີດຂອງ Kubernetes ເພື່ອສະຫນອງຮູບແບບການຂູດຮີດ.

GitOps ອະນຸຍາດໃຫ້ພວກເຮົາເວົ້າວ່າ: ພຽງແຕ່ລະບົບເຫຼົ່ານັ້ນທີ່ສາມາດອະທິບາຍແລະສັງເກດເຫັນສາມາດອັດຕະໂນມັດແລະຄວບຄຸມ.

GitOps ແມ່ນມີຈຸດປະສົງສໍາລັບ stack native cloud ທັງຫມົດ (ຕົວຢ່າງ, Terraform, ແລະອື່ນໆ)

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

ສັງເກດເຫັນວ່າ Terraform ມີຄວາມສໍາຄັນແນວໃດຕໍ່ກັບບັນຫາ bootstrapping ໃນກໍລະນີນີ້. Kubernetes ຕ້ອງຖືກນຳໃຊ້ຢູ່ບ່ອນໃດບ່ອນໜຶ່ງ, ແລະການໃຊ້ Terraform ໝາຍຄວາມວ່າພວກເຮົາສາມາດນຳໃຊ້ຂັ້ນຕອນການເຮັດວຽກຂອງ GitOps ດຽວກັນເພື່ອສ້າງຊັ້ນຄວບຄຸມທີ່ຮອງກັບ Kubernetes ແລະແອັບພລິເຄຊັນຕ່າງໆ. ນີ້ແມ່ນການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ເປັນປະໂຫຍດ.

ມີການສຸມໃສ່ຢ່າງແຂງແຮງໃນການນໍາໃຊ້ແນວຄວາມຄິດ GitOps ກັບຊັ້ນເທິງຂອງ Kubernetes. ໃນປັດຈຸບັນ, ມີການແກ້ໄຂປະເພດ GitOps ສໍາລັບ Istio, Helm, Ksonnet, OpenFaaS ແລະ Kubeflow, ເຊັ່ນດຽວກັບ, ສໍາລັບການຍົກຕົວຢ່າງ, ສໍາລັບ Pulumi, ເຊິ່ງສ້າງຊັ້ນສໍາລັບການພັດທະນາຄໍາຮ້ອງສະຫມັກສໍາລັບ cloud native.

Kubernetes CI/CD: ການປຽບທຽບ GitOps ກັບວິທີການອື່ນໆ

ດັ່ງທີ່ໄດ້ກ່າວ, GitOps ແມ່ນສອງຢ່າງ:

1. ຮູບແບບການດໍາເນີນງານສໍາລັບ Kubernetes ແລະ cloud native ທີ່ອະທິບາຍຂ້າງເທິງ.
2. ເສັ້ນທາງໄປສູ່ສະພາບແວດລ້ອມການຈັດການແອັບພລິເຄຊັນຈາກນັກພັດທະນາເປັນສູນກາງ.

ສໍາລັບຫຼາຍໆຄົນ, GitOps ຕົ້ນຕໍແມ່ນຂະບວນການເຮັດວຽກໂດຍອີງໃສ່ Git pushes. ພວກເຮົາມັກລາວຄືກັນ. ແຕ່ນັ້ນບໍ່ແມ່ນທັງຫມົດ: ຕອນນີ້ໃຫ້ເບິ່ງທໍ່ CI / CD.

GitOps ເປີດໃຊ້ງານຢ່າງຕໍ່ເນື່ອງ (CD) ສໍາລັບ Kubernetes

GitOps ສະເຫນີກົນໄກການປະຕິບັດຢ່າງຕໍ່ເນື່ອງທີ່ກໍາຈັດຄວາມຕ້ອງການສໍາລັບ "ລະບົບການຄຸ້ມຄອງການຈັດວາງ." Kubernetes ເຮັດວຽກທັງຫມົດສໍາລັບທ່ານ.

• ການປັບປຸງຄໍາຮ້ອງສະຫມັກຮຽກຮ້ອງໃຫ້ມີການປັບປຸງໃນ Git. ນີ້ແມ່ນການປັບປຸງການເຮັດທຸລະກໍາກັບສະຖານະທີ່ຕ້ອງການ. ຫຼັງຈາກນັ້ນ, "ການປັບໃຊ້" ແມ່ນເຮັດພາຍໃນກຸ່ມໂດຍ Kubernetes ເອງໂດຍອີງໃສ່ຄໍາອະທິບາຍທີ່ປັບປຸງ.
• ເນື່ອງຈາກລັກສະນະຂອງ Kubernetes ເຮັດວຽກ, ການປັບປຸງເຫຼົ່ານີ້ແມ່ນປະສົມປະສານກັນ. ນີ້ສະຫນອງກົນໄກສໍາລັບການປະຕິບັດຢ່າງຕໍ່ເນື່ອງເຊິ່ງການປັບປຸງທັງຫມົດແມ່ນປະລໍາມະນູ.
• ຫມາຍເຫດ: Weave Cloud ສະເຫນີຕົວປະຕິບັດການ GitOps ທີ່ປະສົມປະສານ Git ແລະ Kubernetes ແລະອະນຸຍາດໃຫ້ CD ດໍາເນີນການໂດຍການ reconciling ສະພາບທີ່ຕ້ອງການແລະປະຈຸບັນຂອງກຸ່ມ.

ໂດຍບໍ່ມີ kubectl ແລະສະຄິບ

ທ່ານຄວນຫຼີກເວັ້ນການໃຊ້ Kubectl ເພື່ອປັບປຸງກຸ່ມຂອງທ່ານ, ແລະໂດຍສະເພາະແມ່ນຫຼີກເວັ້ນການໃຊ້ scripts ເພື່ອຈັດກຸ່ມຄໍາສັ່ງ kubectl. ແທນທີ່ຈະ, ດ້ວຍທໍ່ GitOps, ຜູ້ໃຊ້ສາມາດອັບເດດກຸ່ມ Kubernetes ຂອງເຂົາເຈົ້າຜ່ານ Git.

ຜົນປະໂຫຍດລວມມີ:

1. ສິດ. ກຸ່ມຂອງການປັບປຸງສາມາດຖືກນໍາໃຊ້, converged ແລະສຸດທ້າຍ validated, ເຮັດໃຫ້ພວກເຮົາໃກ້ຊິດກັບເປົ້າຫມາຍຂອງການປະຕິບັດປະລໍາມະນູ. ໃນທາງກົງກັນຂ້າມ, ການໃຊ້ສະຄິບບໍ່ໄດ້ໃຫ້ການຄໍ້າປະກັນການລວມເຂົ້າກັນໃດໆ ​​(ເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ຂ້າງລຸ່ມນີ້).
2. ຄວາມປອດໄພ. ການອ້າງອີງ Kelsey Hightower: "ຈໍາກັດການເຂົ້າເຖິງກຸ່ມ Kubernetes ຂອງທ່ານຕໍ່ກັບເຄື່ອງມືອັດຕະໂນມັດແລະຜູ້ເບິ່ງແຍງລະບົບທີ່ມີຄວາມຮັບຜິດຊອບໃນການດີບັກຫຼືການຮັກສາມັນ." ເບິ່ງນຳ ສິ່ງພິມຂອງຂ້ອຍ ກ່ຽວກັບຄວາມປອດໄພແລະການປະຕິບັດຕາມຂໍ້ກໍານົດດ້ານວິຊາການ, ເຊັ່ນດຽວກັນກັບ ບົດຄວາມກ່ຽວກັບການ hack Homebrew ໂດຍການລັກເອົາຂໍ້ມູນປະຈໍາຕົວຈາກສະຄຣິບ Jenkins ທີ່ຂຽນແບບບໍ່ສົນໃຈ.
3. ປະສົບການຂອງຜູ້ໃຊ້. Kubectl ເປີດເຜີຍກົນໄກຂອງຕົວແບບວັດຖຸ Kubernetes, ເຊິ່ງຂ້ອນຂ້າງສັບສົນ. ໂດຍຫລັກການແລ້ວ, ຜູ້ໃຊ້ຄວນພົວພັນກັບລະບົບໃນລະດັບທີ່ສູງກວ່າຂອງ abstraction. ທີ່ນີ້ຂ້ອຍຈະອ້າງເຖິງ Kelsey ອີກເທື່ອຫນຶ່ງແລະແນະນໍາໃຫ້ເບິ່ງ ຊີວະປະຫວັດຫຍໍ້ດັ່ງກ່າວ.

ຄວາມແຕກຕ່າງລະຫວ່າງ CI ແລະ CD

GitOps ປັບປຸງແບບຈໍາລອງ CI/CD ທີ່ມີຢູ່ແລ້ວ.

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

CI ຄວນຖືກໃຊ້ເພື່ອຍູ້ການອັບເດດໃສ່ລຳຕົ້ນ, ແລະກຸ່ມ Kubernetes ຄວນປ່ຽນຕົວມັນເອງໂດຍອີງໃສ່ການອັບເດດເຫຼົ່ານັ້ນເພື່ອຈັດການ CD ພາຍໃນ. ພວກເຮົາໂທຫາມັນ ດຶງຕົວແບບສໍາລັບ CD, ບໍ່ເຫມືອນກັບຮູບແບບການຊຸກຍູ້ CI. CD ເປັນ​ສ່ວນ​ຫນຶ່ງ​ runtime orchestration.

ເປັນຫຍັງເຊີບເວີ CI ບໍ່ຄວນເຮັດ CD ຜ່ານການປັບປຸງໂດຍກົງໃນ Kubernetes

ຢ່າໃຊ້ເຊີບເວີ CI ເພື່ອຈັດຕັ້ງການອັບເດດໂດຍກົງໃຫ້ກັບ Kubernetes ເປັນຊຸດຂອງວຽກ CI. ນີ້ແມ່ນຮູບແບບການຕ້ານການທີ່ພວກເຮົາເວົ້າກ່ຽວກັບ ບອກແລ້ວ ໃນ blog ຂອງທ່ານ.

ກັບຄືນໄປຫາ Alice ແລະ Bob.

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

ໃຫ້ສົມມຸດວ່າທີມງານຂອງ Bob ໄດ້ສ້າງຮູບພາບໃຫມ່ແລະຫຼັງຈາກນັ້ນ patched ຂອງພວກເຂົາເພື່ອ deploy ຮູບພາບ (ທັງຫມົດຈາກທໍ່ CI).

ຖ້າຮູບພາບກໍ່ສ້າງປົກກະຕິ, ແຕ່ທໍ່ບໍ່ສໍາເລັດ, ທີມງານຈະຕ້ອງຄິດອອກ:

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

ການສ້າງຂະບວນການເຮັດວຽກທີ່ອີງໃສ່ Git ບໍ່ໄດ້ຮັບປະກັນວ່າທີມງານຂອງ Bob ຈະບໍ່ພົບບັນຫາເຫຼົ່ານີ້. ພວກເຂົາເຈົ້າຍັງສາມາດເຮັດຜິດພາດກັບ commit push, tag, ຫຼືບາງຕົວກໍານົດການອື່ນໆ; ຢ່າງໃດກໍຕາມ, ວິທີການນີ້ແມ່ນຍັງໃກ້ຊິດກັບວິທີການທັງຫມົດຫຼືບໍ່ມີຫຍັງທີ່ຈະແຈ້ງ.

ເພື່ອສະຫຼຸບ, ນີ້ແມ່ນເຫດຜົນທີ່ເຄື່ອງແມ່ຂ່າຍ CI ບໍ່ຄວນຈັດການກັບ CD:

• ອັບເດດສະຄຣິບບໍ່ແມ່ນຕົວກໍານົດສະເໝີ; ມັນງ່າຍທີ່ຈະເຮັດຜິດພາດໃນພວກມັນ.
• ເຊີບເວີ CI ບໍ່ລວມເຂົ້າກັບຕົວແບບກຸ່ມປະກາດ.
• ມັນເປັນການຍາກທີ່ຈະຮັບປະກັນຄວາມອ່ອນແອ. ຜູ້ໃຊ້ຕ້ອງເຂົ້າໃຈຄວາມເລິກຂອງລະບົບ.
• ມັນເປັນການຍາກທີ່ຈະຟື້ນຕົວຈາກຄວາມລົ້ມເຫຼວບາງສ່ວນ.

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

GitOps ເປັນວິທີທີ່ດີທີ່ສຸດເພື່ອປະຕິບັດການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງສໍາລັບ Kubernetes

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

ຮູບແບບການດໍາເນີນງານສໍາລັບ Kubernetes

ເບິ່ງແຜນວາດຕໍ່ໄປນີ້. ມັນນໍາສະເຫນີ Git ແລະບ່ອນເກັບມ້ຽນຮູບພາບບັນຈຸເປັນຊັບພະຍາກອນທີ່ແບ່ງປັນສໍາລັບສອງວົງຈອນຊີວິດທີ່ຖືກຈັດລຽງ:

• ທໍ່ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງທີ່ອ່ານແລະຂຽນໄຟລ໌ໄປຫາ Git ແລະສາມາດປັບປຸງ repository ຂອງຮູບ container.
• ທໍ່ Runtime GitOps ທີ່ສົມທົບການນຳໄປໃຊ້ກັບການຈັດການ ແລະ ການສັງເກດການ. ມັນອ່ານແລະຂຽນໄຟລ໌ໄປຫາ Git ແລະສາມາດດາວໂຫລດຮູບພາບບັນຈຸ.

ການຄົ້ນພົບຕົ້ນຕໍແມ່ນຫຍັງ?

1. ການແຍກຄວາມກັງວົນ: ກະລຸນາຮັບຊາບວ່າທໍ່ທັງສອງສາມາດຕິດຕໍ່ສື່ສານໄດ້ໂດຍການອັບເດດ Git ຫຼືບ່ອນເກັບມ້ຽນຮູບພາບເທົ່ານັ້ນ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມີ firewall ລະຫວ່າງ CI ແລະສະພາບແວດລ້ອມ runtime. ພວກເຮົາເອີ້ນມັນວ່າ "ໄຟວໍທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້" (ໄຟວໍທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້), ນັບຕັ້ງແຕ່ການປັບປຸງ repository ທັງຫມົດສ້າງສະບັບໃຫມ່. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບຫົວຂໍ້ນີ້, ເບິ່ງສະໄລ້ 72-87 ການນໍາສະເຫນີນີ້.
2. ທ່ານສາມາດນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍ CI ແລະ Git ໃດ: GitOps ເຮັດວຽກກັບອົງປະກອບໃດໆ. ທ່ານ​ສາ​ມາດ​ສືບ​ຕໍ່​ການ​ນໍາ​ໃຊ້​ເຄື່ອງ​ແມ່​ຂ່າຍ CI ແລະ Git ທີ່​ມັກ​ຂອງ​ທ່ານ​, repositories ຮູບ​ພາບ​, ແລະ​ຊຸດ​ທົດ​ສອບ​. ເກືອບທຸກເຄື່ອງມືການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງອື່ນໆໃນຕະຫຼາດຕ້ອງການເຊີບເວີ CI/Git ຫຼືບ່ອນເກັບຮູບພາບຂອງຕົນເອງ. ອັນນີ້ອາດຈະກາຍເປັນປັດໄຈຈຳກັດໃນການພັດທະນາ cloud native. ດ້ວຍ GitOps, ທ່ານສາມາດນໍາໃຊ້ເຄື່ອງມືທີ່ຄຸ້ນເຄີຍ.
3. ເຫດການເປັນເຄື່ອງມືການເຊື່ອມໂຍງ: ທັນທີທີ່ຂໍ້ມູນໃນ Git ໄດ້ຖືກປັບປຸງ, Weave Flux (ຫຼືຜູ້ປະຕິບັດການ Weave Cloud) ແຈ້ງເຕືອນ runtime. ເມື່ອໃດກໍ່ຕາມ Kubernetes ຍອມຮັບຊຸດການປ່ຽນແປງ, Git ຈະຖືກປັບປຸງ. ນີ້ສະຫນອງຮູບແບບການເຊື່ອມໂຍງແບບງ່າຍດາຍສໍາລັບການຈັດຕັ້ງຂະບວນການເຮັດວຽກສໍາລັບ GitOps, ດັ່ງທີ່ສະແດງຂ້າງລຸ່ມນີ້.

ສະຫລຸບ

GitOps ສະຫນອງການຮັບປະກັນການປັບປຸງທີ່ເຂັ້ມແຂງທີ່ຕ້ອງການໂດຍເຄື່ອງມື CI / CD ທີ່ທັນສະໄຫມ:

• ອັດຕະໂນມັດ;
• convergence;
• ຂາດສານອາຫານ;
• ການຕັດສິນໃຈ.

ນີ້ແມ່ນສິ່ງສໍາຄັນເພາະວ່າມັນສະເຫນີຮູບແບບການດໍາເນີນງານສໍາລັບນັກພັດທະນາ cloud native.

• ເຄື່ອງມືແບບດັ້ງເດີມສໍາລັບການຄຸ້ມຄອງແລະລະບົບການຕິດຕາມແມ່ນກ່ຽວຂ້ອງກັບທີມງານປະຕິບັດງານທີ່ດໍາເນີນການພາຍໃນປື້ມບັນທຶກ (ຊຸດ​ຂອງ​ຂັ້ນ​ຕອນ​ການ​ປົກ​ກະ​ຕິ​ແລະ​ການ​ດໍາ​ເນີນ​ງານ - ປະ​ມານ​. transl​.), ຜູກ​ມັດ​ກັບ​ການ​ນໍາ​ໃຊ້​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​.
• ໃນການຈັດການພື້ນເມືອງຂອງຄລາວ, ເຄື່ອງມືການສັງເກດການເປັນວິທີທີ່ດີທີ່ສຸດໃນການວັດແທກຜົນຂອງການນຳໃຊ້ເພື່ອໃຫ້ທີມງານພັດທະນາສາມາດຕອບສະໜອງໄດ້ໄວ.

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

PS ຈາກນັກແປ

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

• «GitOps: ການປຽບທຽບວິທີການດຶງແລະ Push"
• «ຂໍແນະນຳ kubedog, ຫ້ອງສະໝຸດສຳລັບການຕິດຕາມຊັບພະຍາກອນ Kubernetes"
• «ການ​ຂະ​ຫຍາຍ​ແລະ​ເສີມ Kubernetes (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)".

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

ທ່ານຮູ້ກ່ຽວກັບ GitOps ກ່ອນທີ່ຈະມີການແປສອງສະບັບນີ້ປາກົດຢູ່ໃນHabre?

• ແມ່ນແລ້ວ, ຂ້ອຍຮູ້ທຸກຢ່າງ

• ພຽງແຕ່ superficial

• ບໍ່​ມີ

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

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