werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes (ພາບລວມແລະບົດລາຍງານວິດີໂອ)

ວັນທີ 27 ພຶດສະພາທີ່ຫ້ອງປະຊຸມໃຫຍ່ຂອງກອງປະຊຸມ DevOpsConf 2019, ໄດ້ຈັດຂຶ້ນເປັນສ່ວນຫນຶ່ງຂອງງານບຸນ. RIT++ 2019, ເປັນສ່ວນຫນຶ່ງຂອງ "ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ", ບົດລາຍງານໄດ້ຖືກມອບໃຫ້ "werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes". ມັນເວົ້າກ່ຽວກັບສິ່ງເຫຼົ່ານັ້ນ ບັນຫາ ແລະສິ່ງທ້າທາຍທີ່ທຸກຄົນປະເຊີນໃນເວລານຳໃຊ້ກັບ Kubernetes, ເຊັ່ນດຽວກັນກັບກ່ຽວກັບ nuances ທີ່ອາດຈະບໍ່ສັງເກດເຫັນທັນທີທັນໃດ. ການວິເຄາະການແກ້ໄຂທີ່ເປັນໄປໄດ້, ພວກເຮົາສະແດງໃຫ້ເຫັນວິທີການນີ້ຖືກປະຕິບັດໃນເຄື່ອງມື Open Source werf.

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

ດັ່ງນັ້ນ, ໃຫ້ພວກເຮົາແນະນໍາ ວິ​ດີ​ໂອ​ຂອງ​ບົດ​ລາຍ​ງານ​ (~ 47 ນາທີ, ຂໍ້ມູນຫຼາຍກວ່າບົດຄວາມ) ແລະສານສະກັດຈາກມັນໃນຮູບແບບຂໍ້ຄວາມ. ໄປ!

ສົ່ງລະຫັດໃຫ້ Kubernetes

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

ການຈັດສົ່ງເບິ່ງຄືແນວໃດໃນ Kubernetes?

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

ມີບັນທຶກທີ່ສໍາຄັນຈໍານວນຫນຶ່ງຢູ່ທີ່ນີ້:

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

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

ຂັ້ນຕອນການກໍ່ສ້າງ

ມັນເບິ່ງຄືວ່າທ່ານສາມາດເວົ້າກ່ຽວກັບການສ້າງຮູບພາບ Docker ໃນປີ 2019, ເມື່ອທຸກຄົນຮູ້ວິທີການຂຽນ Dockerfiles ແລະດໍາເນີນການ. docker build?.. ນີ້ແມ່ນ nuances ທີ່ຂ້ອຍຢາກຈະເອົາໃຈໃສ່:

1. ນ້ໍາຫນັກຮູບພາບ ບັນຫາ, ສະນັ້ນໃຊ້ ຫຼາຍຂັ້ນຕອນເພື່ອອອກຈາກຮູບພາບພຽງແຕ່ຄໍາຮ້ອງສະຫມັກທີ່ຈໍາເປັນແທ້ໆສໍາລັບການປະຕິບັດງານ.
2. ຈໍານວນຊັ້ນ ຕ້ອງໄດ້ຮັບການຫຼຸດຜ່ອນໂດຍການສົມທົບລະບົບຕ່ອງໂສ້ຂອງ RUN- ຄໍາ​ສັ່ງ​ຕາມ​ຄວາມ​ຫມາຍ​.
3. ຢ່າງໃດກໍຕາມ, ນີ້ເພີ່ມບັນຫາ ການດີບັກ, ເນື່ອງຈາກວ່າໃນເວລາທີ່ສະພາແຫ່ງ crash, ທ່ານຕ້ອງຊອກຫາຄໍາສັ່ງທີ່ຖືກຕ້ອງຈາກລະບົບຕ່ອງໂສ້ທີ່ເຮັດໃຫ້ເກີດບັນຫາ.
4. ຄວາມໄວໃນການປະກອບ ສໍາຄັນເພາະວ່າພວກເຮົາຕ້ອງການທີ່ຈະເປີດເຜີຍການປ່ຽນແປງຢ່າງໄວວາແລະເບິ່ງຜົນໄດ້ຮັບ. ຕົວຢ່າງ, ທ່ານບໍ່ຕ້ອງການສ້າງການເພິ່ງພາອາໄສໃນຫ້ອງສະຫມຸດພາສາທຸກໆຄັ້ງທີ່ທ່ານສ້າງແອັບພລິເຄຊັນ.
5. ເລື້ອຍໆຈາກບ່ອນເກັບຂໍ້ມູນ Git ທີ່ທ່ານຕ້ອງການ ຮູບ​ພາບ​ຈໍາ​ນວນ​ຫຼາຍ​, ເຊິ່ງສາມາດແກ້ໄຂໄດ້ໂດຍຊຸດຂອງ Dockerfiles (ຫຼືມີຊື່ຂັ້ນຕອນໃນຫນຶ່ງໄຟລ໌) ແລະ Bash script ທີ່ມີການປະກອບຕາມລໍາດັບຂອງພວກເຂົາ.

ນີ້ແມ່ນພຽງແຕ່ປາຍຂອງກ້ອນຫີນທີ່ທຸກຄົນປະເຊີນ. ແຕ່ມີບັນຫາອື່ນໆ, ໂດຍສະເພາະ:

1. ເລື້ອຍໆຢູ່ໃນຂັ້ນຕອນການປະກອບພວກເຮົາຕ້ອງການບາງສິ່ງບາງຢ່າງ ພູ (ຕົວຢ່າງ, cache ຜົນຂອງຄໍາສັ່ງເຊັ່ນ: apt ໃນ directory ຂອງພາກສ່ວນທີສາມ).
2. ພວກ​ເຮົາ​ຕ້ອງ​ການ ຄວາມເຂົ້າໃຈ ແທນທີ່ຈະຂຽນໃນແກະ.
3. ພວກ​ເຮົາ​ຕ້ອງ​ການ ກໍ່ສ້າງໂດຍບໍ່ມີ Docker (ເປັນຫຍັງພວກເຮົາຈໍາເປັນຕ້ອງມີເຄື່ອງ virtual ເພີ່ມເຕີມທີ່ພວກເຮົາຕ້ອງການກໍານົດທຸກສິ່ງທຸກຢ່າງສໍາລັບການນີ້, ເມື່ອພວກເຮົາມີກຸ່ມ Kubernetes ທີ່ພວກເຮົາສາມາດດໍາເນີນການບັນຈຸ?).
4. ການປະກອບຂະຫນານ, ເຊິ່ງສາມາດເຂົ້າໃຈໄດ້ໃນລັກສະນະຕ່າງໆ: ຄໍາສັ່ງທີ່ແຕກຕ່າງກັນຈາກ Dockerfile (ຖ້າໃຊ້ຫຼາຍຂັ້ນຕອນ), ຫຼາຍຄໍາຫມັ້ນສັນຍາຂອງ repository ດຽວກັນ, ຫຼາຍ Dockerfiles.
5. ການປະກອບການແຈກຢາຍ: ພວກເຮົາຕ້ອງການທີ່ຈະເກັບກໍາສິ່ງທີ່ຢູ່ໃນຝັກທີ່ "ephemeral" ເນື່ອງຈາກວ່າ cache ຂອງເຂົາເຈົ້າຫາຍໄປ, ຊຶ່ງຫມາຍຄວາມວ່າມັນຈໍາເປັນຕ້ອງໄດ້ເກັບຮັກສາໄວ້ບ່ອນໃດຫນຶ່ງແຍກຕ່າງຫາກ.
6. ໃນທີ່ສຸດ, ຂ້າພະເຈົ້າໄດ້ຕັ້ງຊື່ຈຸດສູງສຸດຂອງຄວາມປາຖະຫນາ ອັດຕະໂນມັດ: ມັນເຫມາະສົມທີ່ຈະໄປຫາບ່ອນເກັບມ້ຽນ, ພິມຄໍາສັ່ງບາງຢ່າງແລະເອົາຮູບພາບທີ່ກຽມພ້ອມ, ປະກອບດ້ວຍຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການແລະສິ່ງທີ່ຕ້ອງເຮັດຢ່າງຖືກຕ້ອງ. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າສ່ວນບຸກຄົນບໍ່ແນ່ໃຈວ່າ nuances ທັງຫມົດສາມາດຖືກຄາດຄະເນໄວ້ລ່ວງຫນ້າດ້ວຍວິທີນີ້.

ແລະນີ້ແມ່ນໂຄງການ:

• moby/buildkit — ຜູ້ສ້າງຈາກ Docker Inc (ລວມເຂົ້າກັບ Docker ເວີຊັນປັດຈຸບັນແລ້ວ), ເຊິ່ງພະຍາຍາມແກ້ໄຂບັນຫາທັງໝົດເຫຼົ່ານີ້;
• ຄານິໂກ — builder ຈາກ Google ທີ່ອະນຸຍາດໃຫ້ທ່ານສ້າງໂດຍບໍ່ມີການ Docker;
• Buildpacks.io - ຄວາມພະຍາຍາມຂອງ CNCF ເພື່ອເຮັດໃຫ້ magic ອັດຕະໂນມັດແລະ, ໂດຍສະເພາະ, ເປັນການແກ້ໄຂທີ່ຫນ້າສົນໃຈກັບ rebase ສໍາລັບຊັ້ນ;
• ແລະ​ອຸ​ປະ​ກອນ​ອື່ນໆ​ຈໍາ​ນວນ​ຫນຶ່ງ​, ເຊັ່ນ​:​ ສ້າງ, truetools/img...

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

ສະພາແຫ່ງໃນ werf

ດັ່ງນັ້ນພວກເຮົາໄດ້ຮັບການ werf (ກ່ອນ ໜ້າ ນີ້ ທີ່ມີຊື່ສຽງ ຄື dapp) — ແຫຼ່ງເປີດແຫຼ່ງປະໂຫຍດຈາກບໍລິສັດ Flant, ເຊິ່ງພວກເຮົາໄດ້ເຮັດມາເປັນເວລາຫຼາຍປີແລ້ວ. ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນ 5 ປີກ່ອນຫນ້ານີ້ດ້ວຍ Bash scripts ທີ່ເພີ່ມປະສິດທິພາບການປະກອບ Dockerfiles, ແລະສໍາລັບ 3 ປີທີ່ຜ່ານມາການພັດທະນາຢ່າງເຕັມທີ່ໄດ້ຖືກດໍາເນີນຢູ່ໃນກອບຂອງໂຄງການຫນຶ່ງທີ່ມີບ່ອນເກັບມ້ຽນ Git ຂອງຕົນເອງ. (ທໍາອິດໃນ Ruby, ແລະຫຼັງຈາກນັ້ນ ຂຽນຄືນໃຫມ່ ໄປ, ແລະໃນເວລາດຽວກັນປ່ຽນຊື່). ບັນຫາການປະກອບໃດທີ່ຖືກແກ້ໄຂໃນ werf?

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

ຂັ້ນຕອນການພິມເຜີຍແຜ່ໃນທະບຽນ (ເຜີຍແຜ່)

ພວກເຮົາໂທຫາ docker push... - ສິ່ງ​ທີ່​ອາດ​ຈະ​ເປັນ​ການ​ຍາກ​ກ່ຽວ​ກັບ​ການ​ອັບ​ໂຫລດ​ຮູບ​ພາບ​ໃນ​ການ​ຈົດ​ທະ​ບຽນ​? ແລະຫຼັງຈາກນັ້ນຄໍາຖາມທີ່ເກີດຂື້ນ: "ຂ້ອຍຄວນໃສ່ປ້າຍໃດໃສ່ຮູບ?" ມັນເກີດຂື້ນສໍາລັບເຫດຜົນທີ່ພວກເຮົາມີ Gitflow (ຫຼືກົນລະຍຸດ Git ອື່ນໆ) ແລະ Kubernetes, ແລະອຸດສາຫະກໍາກໍາລັງພະຍາຍາມຮັບປະກັນວ່າສິ່ງທີ່ເກີດຂື້ນໃນ Kubernetes ປະຕິບັດຕາມສິ່ງທີ່ເກີດຂື້ນໃນ Git. ຫຼັງຈາກທີ່ທັງຫມົດ, Git ແມ່ນແຫຼ່ງຄວາມຈິງພຽງແຕ່ຂອງພວກເຮົາ.

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

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

Tagging ຍຸດທະສາດ

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

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

ທາງເລືອກທີສອງແມ່ນ git commit + tag. ສາຂາແມ່ບົດມີປ້າຍຊື່ 1.0; ສໍາລັບມັນຢູ່ໃນທະບຽນ - ຮູບພາບທີ່ຖືກນໍາໃຊ້ກັບການຜະລິດ. ນອກຈາກນັ້ນ, ກຸ່ມ Kubernetes ຍັງມີການສະແດງຕົວຢ່າງ ແລະຮູບຊົງຂັ້ນຕອນ. ຕໍ່ໄປພວກເຮົາປະຕິບັດຕາມ Gitflow: ໃນສາຂາຕົ້ນຕໍສໍາລັບການພັດທະນາ (develop) ພວກເຮົາສ້າງຄຸນສົມບັດໃຫມ່, ສົ່ງຜົນໃຫ້ຄໍາຫມັ້ນສັນຍາກັບຕົວລະບຸ #c1. ພວກ​ເຮົາ​ເກັບ​ກໍາ​ມັນ​ແລະ​ເຜີຍ​ແຜ່​ໃນ​ການ​ຈົດ​ທະ​ບຽນ​ໂດຍ​ນໍາ​ໃຊ້​ຕົວ​ລະ​ບຸ​ນີ້ (#c1). ດ້ວຍຕົວລະບຸດຽວກັນ, ພວກເຮົາເປີດຕົວເພື່ອສະແດງຕົວຢ່າງ. ພວກເຮົາເຮັດເຊັ່ນດຽວກັນກັບຄໍາຫມັ້ນສັນຍາ #c2 и #c3.

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

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

ມີຂໍ້ບົກຜ່ອງທີ່ມີພຽງແຕ່ຫນຶ່ງຮູບພາບທີ່ຖືກອັບໂຫລດໄປ staging (#c25), ແລະໃນການຜະລິດມັນແຕກຕ່າງກັນ (.1.1), ແຕ່ພວກເຮົາຮູ້ວ່າ "ທາງດ້ານຮ່າງກາຍ" ເຫຼົ່ານີ້ແມ່ນຮູບພາບດຽວກັນຈາກທະບຽນ.

ຂໍ້ເສຍທີ່ແທ້ຈິງແມ່ນວ່າບໍ່ມີການສະຫນັບສະຫນຸນສໍາລັບການ merge commits, ທ່ານຕ້ອງເຮັດໄວຕໍ່ຫນ້າ.

ພວກ​ເຮົາ​ສາ​ມາດ​ໄປ​ເພີ່ມ​ເຕີມ​ແລະ​ເຮັດ​ໄດ້ trick ... ໃຫ້​ເບິ່ງ​ຕົວ​ຢ່າງ​ຂອງ Dockerfile ງ່າຍ​ດາຍ​:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

ໃຫ້ສ້າງໄຟລ໌ຈາກມັນຕາມຫຼັກການຕໍ່ໄປນີ້:

• SHA256 ຈາກຕົວລະບຸຂອງຮູບພາບທີ່ໃຊ້ (ruby:2.3 и nginx:alpine), ຊຶ່ງເປັນ checksums ຂອງເນື້ອໃນຂອງເຂົາເຈົ້າ;
• ທີມ​ງານ​ທັງ​ຫມົດ (RUN, CMD ແລະ ອື່ນໆ.);
• SHA256 ຈາກໄຟລ໌ທີ່ຖືກເພີ່ມ.

... ແລະເອົາ checksum (ອີກເທື່ອຫນຶ່ງ SHA256) ຈາກໄຟລ໌ດັ່ງກ່າວ. ນີ້ ລາຍເຊັນ ທຸກສິ່ງທຸກຢ່າງທີ່ກໍານົດເນື້ອໃນຂອງຮູບພາບ Docker.

ໃຫ້ກັບຄືນໄປຫາແຜນວາດແລະ ແທນທີ່ຈະເປັນຄໍາຫມັ້ນສັນຍາ, ພວກເຮົາຈະນໍາໃຊ້ລາຍເຊັນດັ່ງກ່າວ, i.e. tag ຮູບພາບທີ່ມີລາຍເຊັນ.

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

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

Tagging ໃນ werf

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

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

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

ດັ່ງນັ້ນ, ຮູບພາບຂັ້ນຕອນແມ່ນ cache ທີ່ສາມາດເກັບຮັກສາໄວ້ຢ່າງແຜ່ຫຼາຍ, ແລະຮູບພາບທີ່ສ້າງຂຶ້ນແລ້ວຈາກມັນຖືກອັບໂຫລດໄປຍັງ Docker Registry.

ທໍາ​ຄວາມ​ສະ​ອາດ​ການ​ຈົດ​ທະ​ບຽນ​

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

ຍຸດທະສາດການເຮັດຄວາມສະອາດແມ່ນຫຍັງ?

1. ທ່ານພຽງແຕ່ບໍ່ສາມາດເຮັດຫຍັງໄດ້ ບໍ່ສະອາດ. ບາງຄັ້ງມັນກໍ່ງ່າຍກວ່າທີ່ຈະຈ່າຍເງິນເລັກນ້ອຍສໍາລັບພື້ນທີ່ພິເສດກ່ວາການແກ້ບັນຫາແທັກອັນໃຫຍ່ຫຼວງ. ແຕ່ນີ້ພຽງແຕ່ເຮັດວຽກເຖິງຈຸດທີ່ແນ່ນອນ.
2. ຣີເຊັດເຕັມ. ຖ້າທ່ານລຶບຮູບພາບທັງຫມົດແລະສ້າງໃຫມ່ພຽງແຕ່ຮູບປະຈຸບັນໃນລະບົບ CI, ບັນຫາອາດຈະເກີດຂື້ນ. ຖ້າຕູ້ຄອນເທນເນີຖືກເລີ່ມຕົ້ນໃຫມ່ໃນການຜະລິດ, ຮູບພາບໃຫມ່ຈະຖືກໂຫລດສໍາລັບມັນ - ຫນຶ່ງທີ່ຍັງບໍ່ທັນໄດ້ທົດສອບໂດຍໃຜ. ນີ້ຂ້າຄວາມຄິດຂອງໂຄງສ້າງພື້ນຖານທີ່ບໍ່ປ່ຽນແປງໄດ້.
3. ສີຂຽວສີຟ້າ. ການລົງທະບຽນອັນໜຶ່ງເລີ່ມລົ້ນ - ພວກເຮົາອັບໂຫລດຮູບພາບໃສ່ບ່ອນອື່ນ. ບັນຫາດຽວກັນກັບວິທີການທີ່ຜ່ານມາ: ຢູ່ທີ່ຈຸດໃດທີ່ທ່ານສາມາດລ້າງການລົງທະບຽນທີ່ເລີ່ມລົ້ນ?
4. ຕາມເວລາ. ລຶບຮູບທັງໝົດທີ່ເກົ່າກວ່າ 1 ເດືອນອອກບໍ? ແຕ່ແນ່ນອນຈະມີການບໍລິການທີ່ບໍ່ມີການປັບປຸງສໍາລັບເດືອນ ...
5. ດ້ວຍຕົນເອງ ກໍານົດສິ່ງທີ່ສາມາດຖືກລຶບແລ້ວ.

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

ພວກເຮົາມາຫຍັງ werf? ພວກເຮົາເກັບກໍາ:

1. Git head: tags ທັງຫມົດ, ທຸກສາຂາ - ສົມມຸດວ່າພວກເຮົາຕ້ອງການທຸກສິ່ງທຸກຢ່າງທີ່ຖືກ tagged ໃນ Git ໃນຮູບພາບຕ່າງໆ (ແລະຖ້າບໍ່ແມ່ນ, ພວກເຮົາຈໍາເປັນຕ້ອງລຶບມັນຢູ່ໃນ Git ຕົວຂອງມັນເອງ);
2. ຝັກທັງໝົດທີ່ປະຈຸບັນຖືກສູບອອກໄປ Kubernetes;
3. ReplicaSets ເກົ່າ (ສິ່ງທີ່ຖືກປ່ອຍອອກມາເມື່ອບໍ່ດົນມານີ້), ແລະພວກເຮົາຍັງວາງແຜນທີ່ຈະສະແກນ Helm ປ່ອຍແລະເລືອກຮູບພາບຫລ້າສຸດຢູ່ທີ່ນັ້ນ.

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

ປະຕິບັດຂັ້ນຕອນ

ການປະກາດທີ່ເຊື່ອຖືໄດ້

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

1. ຕົວລະບຸ;
2. ຂໍ້ມູນການບໍລິການ;
3. ຄ່າເລີ່ມຕົ້ນຫຼາຍ;
4. ພາກສ່ວນທີ່ມີສະຖານະພາບປະຈຸບັນ;
5. ການປ່ຽນແປງທີ່ເຮັດເປັນສ່ວນຫນຶ່ງຂອງ webhook ເຂົ້າ;
6. ຜົນໄດ້ຮັບຂອງການເຮັດວຽກຂອງຕົວຄວບຄຸມຕ່າງໆ (ແລະຕົວກໍານົດເວລາ).

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

ວິທີການນີ້ເອີ້ນວ່າ ການຮວມ 2 ທາງ. ມັນຖືກນໍາໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນ Helm.

ຍັງມີ ການຮວມ 3 ທາງ, ຊຶ່ງ​ແຕກ​ຕ່າງ​ກັນ​ໃນ​ນັ້ນ​:

• ປຽບທຽບ ນຳໃຊ້ຄັ້ງສຸດທ້າຍ и ໃຫມ່, ພວກເຮົາເບິ່ງສິ່ງທີ່ຖືກລຶບຖິ້ມ;
• ປຽບທຽບ ໃຫມ່ и ດໍາລົງຊີວິດ, ພວກເຮົາເບິ່ງສິ່ງທີ່ໄດ້ຮັບການເພີ່ມຫຼືປ່ຽນແປງ;
• patch summed ຖືກນໍາໃຊ້ກັບ ດໍາລົງຊີວິດ.

ພວກເຮົານຳໃຊ້ 1000+ ແອັບພລິເຄຊັ່ນກັບ Helm, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງມີຊີວິດຢູ່ກັບການລວມຕົວແບບ 2 ທາງ. ຢ່າງໃດກໍຕາມ, ມັນມີຈໍານວນບັນຫາທີ່ພວກເຮົາໄດ້ແກ້ໄຂດ້ວຍ patches ຂອງພວກເຮົາ, ເຊິ່ງຊ່ວຍໃຫ້ Helm ເຮັດວຽກເປັນປົກກະຕິ.

ສະຖານະການເປີດຕົວທີ່ແທ້ຈິງ

ຫຼັງຈາກລະບົບ CI ຂອງພວກເຮົາສ້າງການຕັ້ງຄ່າໃຫມ່ສໍາລັບ Kubernetes ໂດຍອີງໃສ່ເຫດການຕໍ່ໄປ, ມັນຈະສົ່ງມັນສໍາລັບການນໍາໃຊ້ (ສະຫມັກ) to a cluster — ການ​ນໍາ​ໃຊ້ Helm ຫຼື​ kubectl apply. ຕໍ່ໄປ, ການລວມ N-way ທີ່ໄດ້ອະທິບາຍໄວ້ແລ້ວຈະເກີດຂື້ນ, ເຊິ່ງ Kubernetes API ຕອບສະຫນອງການອະນຸມັດກັບລະບົບ CI, ແລະຕໍ່ຜູ້ໃຊ້ຂອງມັນ.

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

ເພື່ອເຮັດທຸກຢ່າງຢ່າງຖືກຕ້ອງ, ໂຄງການນີ້ຮຽກຮ້ອງໃຫ້ມີການເຊື່ອມຕໍ່ເພີ່ມເຕີມ - ບົບຕິດຕາມລຸດພິເສດທີ່ຈະໄດ້ຮັບຂໍ້ມູນສະຖານະພາບຈາກ Kubernetes API ແລະສົ່ງມັນສໍາລັບການວິເຄາະຕື່ມອີກກ່ຽວກັບສະພາບທີ່ແທ້ຈິງຂອງສິ່ງຕ່າງໆ. ພວກເຮົາໄດ້ສ້າງຫ້ອງສະຫມຸດ Open Source ໃນ Go - cubedog (ເບິ່ງການປະກາດຂອງມັນ ທີ່ນີ້), ເຊິ່ງແກ້ໄຂບັນຫານີ້ແລະຖືກສ້າງຂຶ້ນໃນ werf.

ພຶດຕິກໍາຂອງຕົວຕິດຕາມນີ້ຢູ່ໃນລະດັບ werf ໄດ້ຖືກຕັ້ງຄ່າໂດຍໃຊ້ຄໍາບັນຍາຍທີ່ວາງໄວ້ໃນ Deployments ຫຼື StatefulSets. ຄໍາ​ບັນ​ຍາຍ​ຕົ້ນ​ຕໍ - fail-mode - ເຂົ້າ​ໃຈ​ຄວາມ​ຫມາຍ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• IgnoreAndContinueDeployProcess — ພວກ​ເຮົາ​ລະ​ເລີຍ​ບັນ​ຫາ​ຂອງ​ການ​ຍົກ​ອອກ​ອົງ​ປະ​ກອບ​ນີ້​ແລະ​ສືບ​ຕໍ່​ການ​ນໍາ​ໃຊ້​;
• FailWholeDeployProcessImmediately — ຄວາມ​ຜິດ​ພາດ​ໃນ​ອົງ​ປະ​ກອບ​ນີ້​ຢຸດ​ເຊົາ​ຂະ​ບວນ​ການ​ການ​ນໍາ​ໃຊ້​;
• HopeUntilEndOfDeployProcess — ພວກ​ເຮົາ​ຫວັງ​ວ່າ​ອົງ​ປະ​ກອບ​ນີ້​ຈະ​ເຮັດ​ວຽກ​ໃນ​ຕອນ​ທ້າຍ​ຂອງ​ການ​ນໍາ​ໃຊ້​ໄດ້​.

ຕົວຢ່າງ, ການປະສົມປະສານຂອງຊັບພະຍາກອນແລະຄຸນຄ່າຂອງຄໍາບັນຍາຍນີ້ fail-mode:

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

ມີສອງຄໍາອະທິບາຍເພີ່ມເຕີມສໍາລັບ kubedog ໃນ werf:

• failures-allowed-per-replica — ຈໍາ​ນວນ​ຂອງ​ການ​ຫຼຸດ​ລົງ​ອະ​ນຸ​ຍາດ​ໃຫ້​ສໍາ​ລັບ​ການ replica ແຕ່​ລະ​ຄົນ​;
• show-logs-until — ຄວບຄຸມປັດຈຸບັນຈົນກ່ວາ werf ສະແດງໃຫ້ເຫັນ (ໃນ stdout) ບັນທຶກຈາກທັງຫມົດ rolled ອອກຝັກ. ຄ່າເລີ່ມຕົ້ນແມ່ນ PodIsReady (ເພື່ອບໍ່ສົນໃຈຂໍ້ຄວາມທີ່ພວກເຮົາອາດຈະບໍ່ຕ້ອງການເມື່ອການຈະລາຈອນເລີ່ມຕົ້ນມາຮອດ pod), ແຕ່ຄ່າຍັງຖືກຕ້ອງ: ControllerIsReady и EndOfDeploy.

ພວກເຮົາຕ້ອງການຫຍັງອີກແດ່ຈາກການຕິດຕັ້ງ?

ນອກ ເໜືອ ໄປຈາກສອງຈຸດທີ່ໄດ້ອະທິບາຍແລ້ວ, ພວກເຮົາຢາກ:

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

ຜົນໄດ້ຮັບ

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

ແທນທີ່ຈະເປັນການສະຫລຸບ:

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

ວິດີໂອ ແລະສະໄລ້

ວິດີໂອຈາກການສະແດງ (~47 ນາທີ):

ການ​ນໍາ​ສະ​ເຫນີ​ບົດ​ລາຍ​ງານ​:

PS

ບົດລາຍງານອື່ນໆກ່ຽວກັບ Kubernetes ໃນ blog ຂອງພວກເຮົາ:

• «ການປັບຂະໜາດອັດຕະໂນມັດ ແລະການຈັດການຊັບພະຍາກອນໃນ Kubernetes» (Dmitry Stolyarov; ວັນທີ 27 ເມສາ 2019 ກ່ຽວກັບ “Strike”);
• «ຂະຫຍາຍ ແລະເສີມສ້າງ Kubernetes» (Andrey Polovov; ວັນທີ 8 ເມສາ 2019 ໃນ Saint HighLoad++);
• «ຖານຂໍ້ມູນ ແລະ Kubernetes» (Dmitry Stolyarov; ເດືອນພະຈິກ 8, 2018 on HighLoad++);
• «ການຕິດຕາມແລະ Kubernetes» (Dmitry Stolyarov; 28 ພຶດສະພາ 2018 ຢູ່ RootConf);
• «CI/CD ການປະຕິບັດທີ່ດີທີ່ສຸດກັບ Kubernetes ແລະ GitLab» (Dmitry Stolyarov; ເດືອນພະຈິກ 7, 2017 on HighLoad++);
• «ປະສົບການຂອງພວກເຮົາກັບ Kubernetes ໃນໂຄງການຂະຫນາດນ້ອຍ» (Dmitry Stolyarov; 6 ເດືອນມິຖຸນາ 2017 ຢູ່ RootConf).

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