ການປະຕິບັດຂອງພວກເຮົາຕໍ່ການນໍາໃຊ້ຢ່າງຕໍ່ເນື່ອງໃນເວທີຂອງລູກຄ້າ

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

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

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະເວົ້າກ່ຽວກັບຂັ້ນຕອນທັງຫມົດຂອງຂະບວນການ Deployment (CD) ຢ່າງຕໍ່ເນື່ອງຫຼືການຈັດສົ່ງການປັບປຸງໃຫ້ກັບເວທີຂອງລູກຄ້າ:

1. ຂະບວນການນີ້ເລີ່ມຕົ້ນແນວໃດ?
2. synchronization ກັບ Git repository ຂອງລູກຄ້າ,
3. ການປະກອບຂອງ backend ແລະ frontend,
4. ການ​ນໍາ​ໃຊ້​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ອັດ​ຕະ​ໂນ​ມັດ​ໃນ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ທົດ​ສອບ​,
5. ການຕິດຕັ້ງອັດຕະໂນມັດກັບ Prod.

ພວກເຮົາຈະແບ່ງປັນລາຍລະອຽດການຕັ້ງຄ່າໄປນຳ.

1. ເລີ່ມ CD

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

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

ພວກເຮົາໄດ້ຈັດຕັ້ງການເຮັດວຽກຜ່ານບ່ອນເກັບມ້ຽນອັນໜຶ່ງດ້ວຍເຫດຜົນຫຼາຍຢ່າງ:

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

2. synchronization ກັບ Git repository ຂອງລະຫັດແຫຼ່ງຂອງລູກຄ້າ

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

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

ຫຼັງຈາກນີ້, ທ່ານຈໍາເປັນຕ້ອງເຮັດການປະກອບ. ມັນປະກອບດ້ວຍຫຼາຍຂັ້ນຕອນ: backend ແລະ frontend ປະກອບ, ການທົດສອບແລະການສົ່ງກັບການຜະລິດ.

3. ການປະກອບ backend ແລະ frontend

ການສ້າງ backend ແລະ frontend ແມ່ນສອງວຽກງານຂະຫນານທີ່ປະຕິບັດຢູ່ໃນລະບົບ GitLab Runner. ການຕັ້ງຄ່າການປະກອບຕົ້ນສະບັບຂອງມັນຢູ່ໃນບ່ອນເກັບມ້ຽນດຽວກັນ.

Tutorial ການຂຽນ YAML script ສໍາລັບການກໍ່ສ້າງໃນ GitLab.

GitLab Runner ເອົາລະຫັດຈາກ repository ທີ່ຕ້ອງການ, ປະກອບມັນດ້ວຍຄໍາສັ່ງ Java application build ແລະສົ່ງໄປທີ່ Docker registry. ໃນທີ່ນີ້ພວກເຮົາປະກອບ backend ແລະ frontend, ໄດ້ຮັບຮູບພາບ Docker, ທີ່ພວກເຮົາເອົາເຂົ້າໄປໃນ repository ຂ້າງລູກຄ້າ. ເພື່ອຈັດການຮູບພາບ Docker ພວກເຮົາໃຊ້ ປລັກອິນ Gradle.

ພວກເຮົາ synchronize ສະບັບຂອງຮູບພາບຂອງພວກເຮົາກັບສະບັບປ່ອຍທີ່ຈະຈັດພີມມາໃນ Docker. ເພື່ອ​ການ​ດໍາ​ເນີນ​ງານ​ທີ່​ກ້ຽງ​, ພວກ​ເຮົາ​ໄດ້​ປັບ​ປຸງ​ຫຼາຍ​:

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

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

ພວກເຮົາໄດ້ຮັບສະບັບຄໍາຮ້ອງສະຫມັກຈາກຜົນໄດ້ຮັບການປະຕິບັດຄໍາສັ່ງ
git describe --tags --abbrev=7.

4. ການນຳໃຊ້ອັດຕະໂນມັດຂອງການປ່ຽນແປງທັງໝົດຕໍ່ກັບສະພາບແວດລ້ອມການທົດສອບ (UAT)

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

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

ພວກເຮົາສະຫນອງການຕັ້ງຄ່າກຸ່ມ K8S ພ້ອມກັບການປະກອບ. ດັ່ງນັ້ນ, ຂັ້ນຕອນຕໍ່ໄປແມ່ນເພື່ອອັບເດດມັນ: configMaps, ການນຳໃຊ້, ບໍລິການ, ຄວາມລັບ ແລະການຕັ້ງຄ່າ K8S ອື່ນໆທີ່ພວກເຮົາໄດ້ປ່ຽນແປງ.

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

5. ການປະຕິບັດອັດຕະໂນມັດຂອງການປ່ຽນແປງທັງຫມົດຕໍ່ກັບ Prod

ເພື່ອປັບໃຊ້ການປັບປຸງສະພາບແວດລ້ອມການຜະລິດ, ທ່ານພຽງແຕ່ຕ້ອງການກົດປຸ່ມດຽວໃນ GitLab - ແລະເຄື່ອງບັນຈຸຈະຖືກສົ່ງກັບສະພາບແວດລ້ອມການຜະລິດທັນທີ.

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

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

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

ການຕັ້ງຄ່າແອັບພລິເຄຊັນໃຊ້ຕົວແປສະພາບແວດລ້ອມ. ຄ່າຂອງພວກມັນຖືກຕັ້ງໄວ້ໃນ containers ໂດຍໃຊ້ K8S configmap, ເຊິ່ງຖືກສ້າງໂດຍໃຊ້ແມ່ແບບ Go. ຕົວຢ່າງ, ການຕັ້ງຄ່າຕົວແປສະພາບແວດລ້ອມກັບຊື່ໂດເມນສາມາດເຮັດໄດ້ເຊັ່ນນີ້:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – ຕົວແປນີ້ເກັບຮັກສາຊື່ຂອງສະພາບແວດລ້ອມ (prod, ຂັ້ນຕອນ, UAT).
.values.app.properties.app_external_domain – ໃນຕົວແປນີ້ພວກເຮົາກໍານົດໂດເມນທີ່ຕ້ອງການໃນໄຟລ໌ .Values.yaml

ເມື່ອອັບເດດແອັບພລິເຄຊັນ, Helm ສ້າງໄຟລ໌ configmap.yaml ຈາກແມ່ແບບ ແລະຕື່ມຄ່າ APP_EXTERNAL_DOMAIN ດ້ວຍຄ່າທີ່ຕ້ອງການໂດຍຂຶ້ນກັບສະພາບແວດລ້ອມທີ່ການອັບເດດແອັບພລິເຄຊັນເລີ່ມຕົ້ນ. ຕົວແປນີ້ຖືກຕັ້ງໄວ້ໃນກ່ອງບັນຈຸແລ້ວ. ມັນສາມາດເຂົ້າເຖິງໄດ້ຈາກແອັບພລິເຄຊັນ, ດັ່ງນັ້ນແຕ່ລະສະພາບແວດລ້ອມຂອງແອັບພລິເຄຊັນຈະມີມູນຄ່າທີ່ແຕກຕ່າງກັນສໍາລັບຕົວແປນີ້.

ຂ້ອນຂ້າງບໍ່ດົນມານີ້, ການສະຫນັບສະຫນູນ K8S ປາກົດຢູ່ໃນ Spring Cloud, ລວມທັງການເຮັດວຽກກັບ configMaps: Spring Cloud Kubernetes. ໃນຂະນະທີ່ໂຄງການພັດທະນາຢ່າງຫ້າວຫັນ ແລະມີການປ່ຽນແປງຢ່າງແຂງແຮງ, ພວກເຮົາບໍ່ສາມາດໃຊ້ມັນເຂົ້າໃນການຜະລິດໄດ້. ແຕ່ພວກເຮົາຕິດຕາມສະພາບຂອງມັນຢ່າງຈິງຈັງ ແລະໃຊ້ມັນຢູ່ໃນການຕັ້ງຄ່າ DEV. ທັນທີທີ່ມັນສະຖຽນລະພາບ, ພວກເຮົາຈະປ່ຽນຈາກການໃຊ້ຕົວແປສະພາບແວດລ້ອມໄປຫາມັນ.

ລວມ

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

ແຜນການໃນອະນາຄົດ: ການເຄື່ອນຍ້າຍຖານຂໍ້ມູນອັດຕະໂນມັດ

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

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

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

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

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