ການແນະນໍາກ່ຽວກັບ GitOps ສໍາລັບ OpenShift

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

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

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

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

• ລາຍລະອຽດການປະກາດຂອງລະບົບຖືກເກັບໄວ້ໃນ Git repository (configs, ການຕິດຕາມ, ແລະອື່ນໆ).
• ການປ່ຽນແປງຂອງລັດແມ່ນເຮັດໂດຍຜ່ານການຮ້ອງຂໍດຶງ.
• ສະຖານະຂອງລະບົບການແລ່ນແມ່ນໄດ້ນໍາເອົາເຂົ້າໄປໃນສອດຄ່ອງກັບຂໍ້ມູນໃນ repository ໂດຍໃຊ້ Git push requests.

ຫຼັກການ GitOps

• ຄໍານິຍາມຂອງລະບົບຖືກອະທິບາຍເປັນລະຫັດແຫຼ່ງ

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

• ລັດທີ່ຕ້ອງການແລະການຕັ້ງຄ່າຂອງລະບົບຖືກຕັ້ງແລະສະບັບຢູ່ໃນ Git

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

• ການປ່ຽນແປງການຕັ້ງຄ່າສາມາດຖືກນໍາໃຊ້ໂດຍອັດຕະໂນມັດຜ່ານຄໍາຮ້ອງຂໍດຶງ

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

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

• ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ຂອງ drift uncontrolled ຂອງ​ການ​ຕັ້ງ​ຄ່າ​

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

ຮູບແບບ GitOps ສໍາລັບ OpenShift

On-Cluster Resource Reconciler

ອີງຕາມຮູບແບບນີ້, ກຸ່ມມີຕົວຄວບຄຸມທີ່ຮັບຜິດຊອບໃນການປຽບທຽບຊັບພະຍາກອນ Kubernetes (ໄຟລ໌ YAML) ໃນບ່ອນເກັບຂໍ້ມູນ Git ກັບຊັບພະຍາກອນທີ່ແທ້ຈິງຂອງກຸ່ມ. ຖ້າ​ຫາກ​ວ່າ​ຄວາມ​ແຕກ​ຕ່າງ​ຖືກ​ກວດ​ພົບ​, ຜູ້​ຄວບ​ຄຸມ​ຈະ​ສົ່ງ​ແຈ້ງ​ການ​ແລະ​ອາດ​ຈະ​ດໍາ​ເນີນ​ການ​ແກ້​ໄຂ​ຄວາມ​ແຕກ​ຕ່າງ​ໄດ້​. ຮູບແບບ GitOps ນີ້ຖືກນໍາໃຊ້ໃນ Anthos Config Management ແລະ Weaveworks Flux.

Reconciler ຊັບພະຍາກອນພາຍນອກ (Push)

ຮູບແບບນີ້ສາມາດຖືກພິຈາລະນາເປັນການປ່ຽນແປງທີ່ຜ່ານມາ, ເມື່ອພວກເຮົາມີຫນຶ່ງຫຼືຫຼາຍຕົວຄວບຄຸມທີ່ຮັບຜິດຊອບສໍາລັບການ synchronizing ຊັບພະຍາກອນໃນຄູ່ "Git repository - Kubernetes cluster". ຄວາມແຕກຕ່າງທີ່ນີ້ແມ່ນວ່າແຕ່ລະກຸ່ມທີ່ຖືກຄຸ້ມຄອງບໍ່ຈໍາເປັນຕ້ອງມີຕົວຄວບຄຸມແຍກຕ່າງຫາກຂອງຕົນເອງ. Git - k8s cluster pairs ມັກຈະຖືກກໍານົດເປັນ CRDs (ການກໍານົດຊັບພະຍາກອນທີ່ກໍາຫນົດເອງ), ເຊິ່ງສາມາດອະທິບາຍວິທີການທີ່ຕົວຄວບຄຸມຄວນປະຕິບັດການ synchronization. ພາຍໃນຕົວແບບນີ້, ຜູ້ຄວບຄຸມປຽບທຽບ Git repository ທີ່ລະບຸໄວ້ໃນ CRD ກັບຊັບພະຍາກອນຂອງກຸ່ມ Kubernetes, ເຊິ່ງຍັງລະບຸໄວ້ໃນ CRD, ແລະດໍາເນີນການທີ່ເຫມາະສົມໂດຍອີງໃສ່ຜົນຂອງການປຽບທຽບ. ໂດຍສະເພາະ, ຮູບແບບ GitOps ນີ້ຖືກນໍາໃຊ້ໃນ ArgoCD.

GitOps ໃນເວທີ OpenShift

ການບໍລິຫານໂຄງສ້າງພື້ນຖານຫຼາຍກຸ່ມ Kubernetes

ດ້ວຍການແຜ່ກະຈາຍຂອງ Kubernetes ແລະຄວາມນິຍົມເພີ່ມຂຶ້ນຂອງຍຸດທະສາດຫຼາຍຄລາວແລະຄອມພິວເຕີ້ຂອບ, ຈໍານວນກຸ່ມ OpenShift ສະເລ່ຍຕໍ່ລູກຄ້າກໍ່ເພີ່ມຂຶ້ນ.

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

ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ບັນ​ຫາ​ຈໍາ​ນວນ​ຫຼາຍ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ແກ້​ໄຂ​, ໂດຍ​ສະ​ເພາະ​ແມ່ນ​:

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

ການຕັ້ງຄ່າແອັບພລິເຄຊັນ

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

ໃນກໍລະນີດັ່ງກ່າວນີ້, ວຽກງານດັ່ງຕໍ່ໄປນີ້ຕ້ອງໄດ້ຮັບການແກ້ໄຂ:

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

OpenShift GitOps ໃຊ້ກໍລະນີ

1. ນຳໃຊ້ການປ່ຽນແປງຈາກບ່ອນເກັບຂໍ້ມູນ Git

ຜູ້ເບິ່ງແຍງກຸ່ມສາມາດເກັບຮັກສາ OpenShift cluster configurations ໃນ Git repository ແລະນໍາໃຊ້ພວກມັນໂດຍອັດຕະໂນມັດເພື່ອສ້າງ clusters ໃຫມ່ຢ່າງງ່າຍດາຍແລະນໍາພວກມັນເຂົ້າໄປໃນສະຖານະທີ່ຄ້າຍຄືກັບລັດທີ່ຮູ້ຈັກທີ່ເກັບໄວ້ໃນ Git repository.

2. synchronization ກັບຜູ້ຈັດການລັບ

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

3. ການຄວບຄຸມການຕັ້ງຄ່າ drift

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

4. ການແຈ້ງເຕືອນກ່ຽວກັບການຕັ້ງຄ່າ drift

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

5. synchronization ຄູ່ມືຂອງການຕັ້ງຄ່າໃນເວລາທີ່ drifting

ອະນຸຍາດໃຫ້ຜູ້ເບິ່ງແຍງລະບົບ synchronize ກຸ່ມ OpenShift ກັບ Git repository ໃນກໍລະນີຂອງການຕັ້ງຄ່າ drift, ເພື່ອກັບຄືນ cluster ຢ່າງໄວວາກັບສະຖານະທີ່ຮູ້ຈັກກ່ອນຫນ້ານີ້.

6.Auto-synchronization ຂອງການຕັ້ງຄ່າໃນເວລາທີ່ drifting

ຜູ້ເບິ່ງແຍງລະບົບຍັງສາມາດກຳນົດຄ່າ OpenShift cluster ເພື່ອ synchronize ອັດຕະໂນມັດກັບ repository ເມື່ອກວດພົບ drift, ດັ່ງນັ້ນການຕັ້ງຄ່າ cluster ກົງກັບ configs ໃນ Git.

7. ຫຼາຍກຸ່ມ - ຫນຶ່ງ repository

ຜູ້ບໍລິຫານສາມາດເກັບຮັກສາການຕັ້ງຄ່າຂອງກຸ່ມ OpenShift ທີ່ແຕກຕ່າງກັນຫຼາຍອັນຢູ່ໃນບ່ອນເກັບຂໍ້ມູນ Git ແລະເລືອກໃຊ້ພວກມັນຕາມຄວາມຕ້ອງການ.

8. ລຳດັບຂອງການຕັ້ງຄ່າກຸ່ມ (ການສືບທອດ)

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

ຕົວຢ່າງ, ຖ້າຜູ້ບໍລິຫານຕັ້ງລໍາດັບຊັ້ນ “ກຸ່ມການຜະລິດ (ຜະລິດຕະພັນ) → ລະບົບ X clusters → ກຸ່ມການຜະລິດຂອງລະບົບ X” ໃນບ່ອນເກັບຂໍ້ມູນ Git, ຫຼັງຈາກນັ້ນການລວມກັນຂອງ configs ຕໍ່ໄປນີ້ຖືກນໍາໃຊ້ກັບກຸ່ມການຜະລິດຂອງລະບົບ X:

• ກຳນົດຄ່າທົ່ວໄປກັບທຸກກຸ່ມການຜະລິດ.
• ກຳນົດຄ່າສຳລັບລະບົບ X cluster.
• ການຕັ້ງຄ່າສຳລັບກຸ່ມການຜະລິດລະບົບ X.

9. ແມ່ແບບແລະການຕັ້ງຄ່າ overrides

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

10. Selective include and exclude for configurations, ການຕັ້ງຄ່າຄໍາຮ້ອງສະຫມັກ

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

11. ສະຫນັບສະຫນູນແມ່ແບບ

ນັກພັດທະນາຈະໄດ້ຮັບຜົນປະໂຫຍດຈາກຄວາມສາມາດໃນການເລືອກວິທີການກໍານົດຊັບພະຍາກອນຂອງແອັບພລິເຄຊັນ (Helm Chart, pure Kubernetes yaml, ແລະອື່ນໆ) ເພື່ອນໍາໃຊ້ຮູບແບບທີ່ເຫມາະສົມທີ່ສຸດສໍາລັບແຕ່ລະຄໍາຮ້ອງສະຫມັກສະເພາະ.

ເຄື່ອງມື GitOps ໃນເວທີ OpenShift

ArgoCD

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

ເວັບ​ໄຊ​ທ​໌​ທີ່​ເປັນ​ທາງ​ການ

ໄຫຼ

Flux ປະຕິບັດຮູບແບບ On-Cluster Resource Reconcile ແລະ, ດັ່ງນັ້ນ, ບໍ່ມີການຈັດການສູນກາງຂອງ repository ຄໍານິຍາມ, ເຊິ່ງເປັນຈຸດອ່ອນ. ໃນທາງກົງກັນຂ້າມ, ແນ່ນອນ, ເນື່ອງຈາກການຂາດການສູນກາງ, ຄວາມສາມາດໃນການຈັດການຄໍາຮ້ອງສະຫມັກຍັງຄົງຢູ່ເຖິງແມ່ນວ່າກຸ່ມຫນຶ່ງຈະລົ້ມເຫລວ.

ເວັບ​ໄຊ​ທ​໌​ທີ່​ເປັນ​ທາງ​ການ

ການຕິດຕັ້ງ ArgoCD ໃນ OpenShift

ArgoCD ສະຫນອງການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງທີ່ດີເລີດແລະ web console, ດັ່ງນັ້ນພວກເຮົາຈະບໍ່ກວມເອົາ Flux ແລະທາງເລືອກອື່ນໆຢູ່ທີ່ນີ້.

ເພື່ອນຳໃຊ້ ArgoCD ເທິງເວທີ OpenShift 4, ປະຕິບັດຕາມຂັ້ນຕອນເຫຼົ່ານີ້ໃນຖານະຜູ້ບໍລິຫານກຸ່ມ:

ການນຳໃຊ້ອົງປະກອບ ArgoCD ໃນເວທີ OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

ການປັບປຸງ ArgoCD Server ເພື່ອໃຫ້ມັນສາມາດເຫັນໄດ້ໂດຍ OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

ນຳໃຊ້ເຄື່ອງມື ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

ການປ່ຽນລະຫັດຜ່ານຂອງ ArgoCD Server admin

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

ຫຼັງຈາກສໍາເລັດຂັ້ນຕອນເຫຼົ່ານີ້, ທ່ານສາມາດເຮັດວຽກກັບ ArgoCD Server ຜ່ານ ArgoCD WebUI web console ຫຼືເຄື່ອງມືແຖວຄໍາສັ່ງ ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - ມັນບໍ່ເຄີຍຊ້າເກີນໄປ

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

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

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

ດັ່ງນັ້ນພວກເຮົາມີຄໍາຮ້ອງສະຫມັກ handcrafted. ໃນປັດຈຸບັນມັນຈໍາເປັນຕ້ອງໄດ້ໂອນພາຍໃຕ້ການຄຸ້ມຄອງ GitOps ໂດຍບໍ່ມີການສູນເສຍຄວາມພ້ອມ. ໃນສັ້ນ, ມັນເຮັດສິ່ງນີ້:

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

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

ໃນຕົວຢ່າງຂອງພວກເຮົາ, ພວກເຮົາຈະສ້າງ repository ສາທາລະນະໃຫມ່ໃນ GitHub. ທ່ານສາມາດໂທຫາມັນໃດກໍ່ຕາມທີ່ທ່ານຕ້ອງການ, ພວກເຮົາໃຊ້ຊື່ blogpost.

ຖ້າໄຟລ໌ວັດຖຸ YAML ບໍ່ໄດ້ຖືກເກັບໄວ້ໃນເຄື່ອງຫຼືຢູ່ໃນ Git, ຫຼັງຈາກນັ້ນທ່ານຈະຕ້ອງໃຊ້ oc ຫຼື kubectl binaries. ໃນພາບຫນ້າຈໍຂ້າງລຸ່ມນີ້ພວກເຮົາກໍາລັງຮ້ອງຂໍ YAML ສໍາລັບ namespace, ການປະຕິບັດ, ການບໍລິການແລະເສັ້ນທາງຂອງພວກເຮົາ. ກ່ອນນີ້, ພວກເຮົາ cloned repository ສ້າງໃຫມ່ແລະ cd ເຂົ້າໄປໃນມັນ.

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

ຕອນນີ້ໃຫ້ເຮົາແກ້ໄຂໄຟລ໌ deployment.yaml ເພື່ອເອົາຊ່ອງຂໍ້ມູນທີ່ Argo CD ບໍ່ສາມາດຊິ້ງໄດ້.

sed -i '/sgeneration: .*/d' deployment.yaml

ນອກຈາກນັ້ນ, ເສັ້ນທາງຕ້ອງໄດ້ຮັບການປ່ຽນແປງ. ທໍາອິດພວກເຮົາຈະກໍານົດຕົວແປຫຼາຍແຖວແລະຫຼັງຈາກນັ້ນແທນ ingress: null ກັບເນື້ອໃນຂອງຕົວແປນັ້ນ.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s/  ingress: null/$ROUTE/g" route.yaml

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

git commit -am ‘initial commit of objects’
git push origin master

ນອກຈາກນັ້ນ, ພວກເຮົາດໍາເນີນການຈາກຄວາມຈິງທີ່ວ່າທ່ານໄດ້ນໍາໃຊ້ ArgoCD ແລ້ວ (ວິທີການເຮັດສິ່ງນີ້ - ເບິ່ງກ່ອນຫນ້ານີ້ ໂພດ). ດັ່ງນັ້ນ, ພວກເຮົາຈະເພີ່ມໃສ່ Argo CD ທີ່ເກັບຮັກສາທີ່ພວກເຮົາສ້າງ, ບັນຈຸລະຫັດຄໍາຮ້ອງສະຫມັກຈາກຕົວຢ່າງຂອງພວກເຮົາ. ພຽງແຕ່ໃຫ້ແນ່ໃຈວ່າທ່ານລະບຸ repository ທີ່ແນ່ນອນທີ່ທ່ານສ້າງຂຶ້ນກ່ອນຫນ້ານີ້.

argocd repo add https://github.com/cooktheryan/blogpost

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

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

ເມື່ອແອັບພລິເຄຊັນຖືກລະບຸໄວ້ໃນ Argo CD, ຊຸດເຄື່ອງມືຈະເລີ່ມກວດສອບວັດຖຸທີ່ໃຊ້ແລ້ວຕໍ່ກັບຄໍານິຍາມໃນບ່ອນເກັບມ້ຽນ. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ການຊິງຄ໌ອັດຕະໂນມັດແລະການເຮັດຄວາມສະອາດຖືກປິດໃຊ້ງານ, ດັ່ງນັ້ນອົງປະກອບບໍ່ປ່ຽນແປງເທື່ອ. ກະລຸນາຮັບຊາບວ່າໃນການໂຕ້ຕອບ Argo CD ແອັບພລິເຄຊັນຂອງພວກເຮົາຈະມີສະຖານະ "Out of Sync" ເພາະວ່າບໍ່ມີປ້າຍຊື່ທີ່ ArgoCD ໃຫ້.
ນີ້​ແມ່ນ​ວ່າ​ເປັນ​ຫຍັງ​ເມື່ອ​ພວກ​ເຮົາ​ເລີ່ມ​ຕົ້ນ synchronization ເລັກ​ນ້ອຍ​ຕໍ່​ມາ​, ວັດ​ຖຸ​ຈະ​ບໍ່​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້​ຄືນ​ໃຫມ່​.

ຕອນນີ້ໃຫ້ພວກເຮົາດໍາເນີນການທົດສອບເພື່ອໃຫ້ແນ່ໃຈວ່າບໍ່ມີຂໍ້ຜິດພາດໃນໄຟລ໌ຂອງພວກເຮົາ.

argocd app sync simple-app --dry-run

ຖ້າບໍ່ມີຂໍ້ຜິດພາດ, ທ່ານສາມາດດໍາເນີນການ synchronization ໄດ້.

argocd app sync simple-app

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

argocd app get simple-app
Name:               simple-app
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

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

argocd app set simple-app --sync-policy automated --auto-prune

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

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