ບັນຫາຂອງການທໍາຄວາມສະອາດ "ສະຫມາດ" ຂອງຮູບພາບບັນຈຸແລະການແກ້ໄຂຂອງມັນຢູ່ໃນ werf

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

ການນໍາສະເຫນີ

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

1. ໃຊ້ຈໍານວນແທັກຄົງທີ່ສໍາລັບຮູບພາບ;
2. ເຮັດຄວາມສະອາດຮູບພາບໃນບາງທາງ.

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

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

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

ແຕ່ເຈົ້າກໍານົດວ່າຮູບພາບໃດມີຄວາມກ່ຽວຂ້ອງແນວໃດ?

ເງື່ອນໄຂສໍາລັບຄວາມກ່ຽວຂ້ອງຂອງຮູບພາບ

ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ເງື່ອນໄຂຕົ້ນຕໍແມ່ນ:

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

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

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

4. ສີ່ - ຮູບພາບທີ່ ສອດຄ້ອງກັບສະບັບຂອງຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ, i.e. ແມ່ນຜະລິດຕະພັນສຸດທ້າຍ: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, ແລະອື່ນໆ.

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

ການມີສິດໄດ້ຮັບແລະການແກ້ໄຂທີ່ມີຢູ່ແລ້ວ

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

* ຂຶ້ນກັບການປະຕິບັດການລົງທະບຽນບັນຈຸສະເພາະ. ພວກເຮົາໄດ້ພິຈາລະນາຄວາມເປັນໄປໄດ້ຂອງການແກ້ໄຂຕໍ່ໄປນີ້: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io - ໃນເດືອນກັນຍາ 2020.

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

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

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

ຮູບປະກອບຂອງຂັ້ນຕອນການເຮັດວຽກໃນ Git

ສົມມຸດວ່າເຈົ້າກຳລັງເຮັດວຽກແບບນີ້ຢູ່ໃນ Git:

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

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

ແນ່ນອນ, ສະຖານະການດັ່ງກ່າວຈະບໍ່ເຮັດໃຫ້ໃຜມີຄວາມສຸກ.

ຈະມີການປ່ຽນແປງແນວໃດຖ້ານະໂຍບາຍອະນຸຍາດໃຫ້ຮູບພາບບໍ່ຖືກລຶບ? ອີງຕາມໄລຍະເວລາ / ຈໍານວນຄໍາຫມັ້ນສັນຍາສຸດທ້າຍ?

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

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

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

ເສັ້ນທາງຂອງພວກເຮົາໄປສູ່ການທໍາຄວາມສະອາດຮູບພາບທົ່ວໄປ

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

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

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

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

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

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

ແຜນ​ການ​ຕິດ​ຕັ້ງ​

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

ວິທີການນີ້ໄດ້ສົ່ງຜົນໃຫ້ຊຸດນະໂຍບາຍທີ່ອະນຸຍາດໃຫ້ Git ຖືກນໍາໃຊ້ເປັນແຫຼ່ງດຽວຂອງຄວາມຈິງ:

• ເມື່ອລຶບສາຂາ/ແທັກໃນ Git, ຮູບພາບທີ່ກ່ຽວຂ້ອງໃນທະບຽນຈະຖືກລຶບໂດຍອັດຕະໂນມັດ.
• ຈໍານວນຂອງຮູບພາບທີ່ກ່ຽວຂ້ອງກັບ tags Git ແລະ commits ສາມາດຖືກຄວບຄຸມໂດຍຈໍານວນຂອງ tags ທີ່ໃຊ້ໃນ schema ທີ່ເລືອກແລະເວລາທີ່ຄໍາຫມັ້ນສັນຍາທີ່ກ່ຽວຂ້ອງໄດ້ຖືກສ້າງຂື້ນ.

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

ຂັ້ນຕອນວິທີໃໝ່

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

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

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

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມັນຖືກສະຫນອງໃຫ້ ການເຊື່ອມໂຍງ tags ທີ່ຖືກເຜີຍແຜ່ດ້ວຍຄໍາຫມັ້ນສັນຍາໃນ Git.

ການຕັ້ງຄ່າສຸດທ້າຍ ແລະສູດການຄິດໄລ່ທົ່ວໄປ

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

• ການອ້າງອີງຫຼາຍ, i.e. Git tags ຫຼືສາຂາ Git ທີ່ຖືກນໍາໃຊ້ໃນລະຫວ່າງການສະແກນ;
• ແລະຂອບເຂດຈໍາກັດຂອງຮູບພາບທີ່ຄົ້ນຫາສໍາລັບແຕ່ລະເອກະສານອ້າງອີງຈາກຊຸດ.

ເພື່ອສະແດງໃຫ້ເຫັນ, ນີ້ແມ່ນສິ່ງທີ່ການຕັ້ງຄ່ານະໂຍບາຍເລີ່ມຕົ້ນເບິ່ງຄືວ່າ:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

ການຕັ້ງຄ່ານີ້ມີສາມນະໂຍບາຍທີ່ປະຕິບັດຕາມກົດລະບຽບຕໍ່ໄປນີ້:

1. ບັນທຶກຮູບພາບສໍາລັບ 10 Git tags ສຸດທ້າຍ (ໂດຍວັນທີສ້າງແທັກ).
2. ບັນທຶກຮູບພາບທີ່ບໍ່ເກີນ 2 ຮູບທີ່ຖືກຕີພິມໃນອາທິດທີ່ຜ່ານມາບໍ່ເກີນ 10 ຫົວຂໍ້ທີ່ມີກິດຈະກໍາໃນອາທິດທີ່ຜ່ານມາ.
3. ບັນທຶກ 10 ຮູບພາບສໍາລັບສາຂາ main, staging и production.

ສູດການຄິດໄລ່ສຸດທ້າຍຕົ້ມລົງໄປໃນຂັ້ນຕອນຕໍ່ໄປນີ້:

• ດຶງຂໍ້ມູນ manifests ຈາກທະບຽນ container.
• ບໍ່ລວມຮູບພາບທີ່ໃຊ້ໃນ Kubernetes, ເພາະວ່າ ພວກເຮົາໄດ້ເລືອກພວກມັນໄວ້ກ່ອນແລ້ວໂດຍການສຳຫຼວດ K8s API.
• ການສະແກນປະຫວັດ Git ແລະບໍ່ລວມຮູບພາບໂດຍອີງໃສ່ນະໂຍບາຍທີ່ລະບຸໄວ້.
• ການ​ລົບ​ຮູບ​ພາບ​ທີ່​ຍັງ​ເຫຼືອ​.

ກັບໄປທີ່ຕົວຢ່າງຂອງພວກເຮົາ, ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນກັບ werf:

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

ສະຫລຸບ

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

PS

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

• «ການແທັກທີ່ອີງໃສ່ເນື້ອຫາໃນຕົວເກັບລວບລວມ werf: ເປັນຫຍັງແລະມັນເຮັດວຽກແນວໃດ?"
• «ການລວມເຂົ້າກັນ 3 ທາງກັບ werf: ການປະຕິບັດກັບ Kubernetes ດ້ວຍ Helm "ກ່ຽວກັບ steroids""
• «ສະຫນັບສະຫນູນ monorepo ແລະ multirepo ໃນ werf ແລະ Docker Registry ມີຫຍັງແດ່ກ່ຽວກັບມັນ"
• «ການປ່ອຍ werf 1.1: ການປັບປຸງຜູ້ກໍ່ສ້າງໃນມື້ນີ້ແລະແຜນການສໍາລັບອະນາຄົດ".

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