GitOps: buzzword ອື່ນຫຼືຄວາມກ້າວຫນ້າໃນອັດຕະໂນມັດບໍ?

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

ໂດຍວິທີທາງການ, ກ່ຽວກັບ novelty ຂອງໄລຍະ GitOps ການສໍາຫຼວດທີ່ຜ່ານມາຂອງພວກເຮົາຍັງເວົ້າວ່າ: ຫຼາຍກວ່າເຄິ່ງຫນຶ່ງຂອງຜູ້ທີ່ຖືກສໍາຫຼວດຍັງບໍ່ທັນໄດ້ເລີ່ມເຮັດວຽກກັບຫຼັກການຂອງມັນ.

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

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

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

GitOps

IaC

ລະຫັດທັງຫມົດຖືກເກັບໄວ້ໃນ git repository

ການສ້າງລະຫັດແມ່ນທາງເລືອກ

ລາຍລະອຽດລະຫັດປະກາດ / Ideempotency

ທັງການປະກາດ ແລະຄຳອະທິບາຍທີ່ຈຳເປັນແມ່ນຍອມຮັບໄດ້

ການ​ປ່ຽນ​ແປງ​ມີ​ຜົນ​ໂດຍ​ນໍາ​ໃຊ້​ກົນ​ໄກ​ການ​ຮ້ອງ​ຂໍ​ການ​ລວມ​ເຂົ້າ / ດຶງ​ການ​ຮ້ອງ​ຂໍ​

ຂໍ້ຕົກລົງ, ການອະນຸມັດ ແລະການຮ່ວມມືແມ່ນເປັນທາງເລືອກ

ຂະບວນການເປີດຕົວອັບເດດແມ່ນອັດຕະໂນມັດ

ຂະບວນການອັບເດດບໍ່ໄດ້ມາດຕະຖານ (ອັດຕະໂນມັດ, ຄູ່ມື, ການຄັດລອກໄຟລ໌, ການນໍາໃຊ້ເສັ້ນຄໍາສັ່ງ, ແລະອື່ນໆ).

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

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

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

ໃນບໍລິສັດ GitLab ພວກເຮົາໄດ້ພັດທະນາສອງຄໍານິຍາມຂອງຄໍາສັບໃຫມ່ນີ້: ທິດສະດີແລະການປະຕິບັດ. ໃຫ້ເລີ່ມຕົ້ນດ້ວຍທິດສະດີ:

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

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

ຈາກທັດສະນະປະຕິບັດ, ພວກເຮົາອະທິບາຍ GitOps ດັ່ງຕໍ່ໄປນີ້:

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

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

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

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

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

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

• ປະຕິບັດຫຼັກການພື້ນຖານຂອງ GitOps

• ສ້າງ​ແລະ​ເຮັດ​ໃຫ້​ການ​ປ່ຽນ​ແປງ​ໂຄງ​ລ່າງ​ພື້ນ​ຖານ​ຂອງ​ຟັງ (ໂດຍ​ນໍາ​ໃຊ້​ຕົວ​ຢ່າງ​ຂອງ Yandex Cloud​)

• ການກວດຫາອັດຕະໂນມັດຂອງລະບົບ drift ຈາກລັດທີ່ຕ້ອງການໂດຍໃຊ້ການຕິດຕາມການເຄື່ອນໄຫວ

https://bit.ly/34tRpwZ

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