ສະຫນັບສະຫນູນ monorepo ແລະ multirepo ໃນ werf ແລະ Docker Registry ມີຫຍັງແດ່ກ່ຽວກັບມັນ

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

ການສະຫນັບສະຫນູນ mono-repo ທີ່ຜ່ານມາຂອງ werf ເປັນຕົວຢ່າງທີ່ດີຂອງເລື່ອງນີ້. ແຕ່ທໍາອິດ, ໃຫ້ຄິດອອກວິທີການສະຫນັບສະຫນູນນີ້ໂດຍທົ່ວໄປກ່ຽວຂ້ອງກັບການນໍາໃຊ້ werf ແລະສິ່ງທີ່ Docker Registry ກ່ຽວຂ້ອງກັບມັນ ...

ບັນຫາ

ຂໍໃຫ້ຈິນຕະນາການສະຖານະການດັ່ງກ່າວ. ບໍລິສັດມີທີມງານພັດທະນາຈໍານວນຫຼາຍທີ່ເຮັດວຽກກ່ຽວກັບໂຄງການເອກະລາດ. ແອັບພລິເຄຊັນສ່ວນໃຫຍ່ເຮັດວຽກຢູ່ໃນ Kubernetes ແລະດັ່ງນັ້ນຈຶ່ງຖືກບັນຈຸ. ເພື່ອເກັບຮັກສາຕູ້ຄອນເທນເນີ, ຮູບພາບ, ທ່ານຈໍາເປັນຕ້ອງມີທະບຽນ (ທະບຽນ). ໃນຖານະເປັນການລົງທະບຽນດັ່ງກ່າວ, ບໍລິສັດໃຊ້ Docker Hub ດ້ວຍບັນຊີດຽວ COMPANY. ຄ້າຍຄືກັນກັບລະບົບການເກັບຮັກສາລະຫັດແຫຼ່ງສ່ວນໃຫຍ່, Docker Hub ບໍ່ອະນຸຍາດໃຫ້ຈັດລໍາດັບຊັ້ນຂອງບ່ອນເກັບມ້ຽນທີ່ຊ້ອນກັນ, ເຊັ່ນ​ວ່າ COMPANY/PROJECT/IMAGE. ໃນກໍລະນີດັ່ງກ່າວ… ທ່ານສາມາດເກັບຮັກສາຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ແມ່ນ monolithic ຢູ່ໃນທະບຽນທີ່ມີຂໍ້ຈໍາກັດນີ້ໂດຍບໍ່ມີການສ້າງບັນຊີແຍກຕ່າງຫາກສໍາລັບແຕ່ລະໂຄງການ?

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

ວິທີແກ້ໄຂ

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

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

1. ເກັບຮັກສາຮູບພາບໃນ repositories ແຍກແຍກຕ່າງຫາກ:

   

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

   

NB: ຕົວຈິງແລ້ວ, ມີທາງເລືອກອື່ນທີ່ມີການບັນທຶກໃນ repositories ທີ່ແຕກຕ່າງກັນ, PROJECT-frontend и PROJECT-backend, ແຕ່ພວກເຮົາຈະບໍ່ພິຈາລະນາມັນເນື່ອງຈາກຄວາມສັບສົນຂອງການສະຫນັບສະຫນູນ, ການຈັດຕັ້ງແລະການແຈກຢາຍສິດທິລະຫວ່າງຜູ້ໃຊ້.

werf ສະຫນັບສະຫນູນ

ໃນເບື້ອງຕົ້ນ, werf ຈໍາກັດຕົວເອງກັບ repositories nested - ໂຊກດີ, ການລົງທະບຽນສ່ວນໃຫຍ່ສະຫນັບສະຫນູນຄຸນນະສົມບັດນີ້. ເລີ່ມຕົ້ນຈາກສະບັບ v1.0.4-alpha.3, ເພີ່ມການເຮັດວຽກກັບທະບຽນທີ່ ບໍ່ຮອງຮັບການສ້າງຮັງ, ແລະ Docker Hub ແມ່ນຫນຶ່ງໃນນັ້ນ. ຈາກຈຸດນີ້, ຜູ້ໃຊ້ມີທາງເລືອກຂອງວິທີການເກັບຮັກສາຮູບພາບຂອງແອັບພລິເຄຊັນ.

ການປະຕິບັດສາມາດໃຊ້ໄດ້ພາຍໃຕ້ທາງເລືອກ --images-repo-mode=multirepo|monorepo (ຄ່າເລີ່ມຕົ້ນ multirepo, i.e. ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ໃນ repositories ຮັງ​)​. ມັນກໍານົດຮູບແບບທີ່ຮູບພາບຖືກເກັບໄວ້ໃນທະບຽນ. ມັນພຽງພໍທີ່ຈະເລືອກຮູບແບບທີ່ຕ້ອງການໃນເວລາທີ່ໃຊ້ຄໍາສັ່ງພື້ນຖານ, ແລະທຸກສິ່ງທຸກຢ່າງອື່ນຈະບໍ່ປ່ຽນແປງ.

ເນື່ອງຈາກວ່າທາງເລືອກ werf ສ່ວນໃຫຍ່ສາມາດຕັ້ງຄ່າໄດ້ ຕົວແປສະພາບແວດລ້ອມ, ໃນລະບົບ CI / CD, ຮູບແບບການເກັບຮັກສາປົກກະຕິແລ້ວແມ່ນງ່າຍທີ່ຈະຕັ້ງຄ່າທົ່ວໂລກສໍາລັບໂຄງການທັງຫມົດ. ຍົກ​ຕົວ​ຢ່າງ, ໃນກໍລະນີຂອງ GitLab ພຽງແຕ່ເພີ່ມຕົວແປສະພາບແວດລ້ອມໃນການຕັ້ງຄ່າໂຄງການ: ການຕັ້ງຄ່າ -> CI / CD -> ຕົວແປ: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

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

ມານແມ່ນຢູ່ໃນລາຍລະອຽດ

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

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

1. 3 ຍຸດທະສາດທີ່ເຊື່ອມຕໍ່ໂດຍ Git primitives ເຊັ່ນ tag, ສາຂາ, ແລະຄໍາຫມັ້ນສັນຍາ;
2. 1 ຍຸດທະສາດສຳລັບແທັກທີ່ກຳນົດເອງຕາມໃຈມັກ.

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

ເມື່ອ​ບັນ​ທຶກ​ໄວ້​ໃນ​ຫນຶ່ງ repository (monorepo), ໃນແທັກຮູບພາບ, ນອກເຫນືອຈາກແທັກ meta, ຊື່ຂອງຮູບພາບຍັງສາມາດຖືກເກັບໄວ້: PROJECT:frontend-META-TAG. ເພື່ອແຍກພວກມັນ, ພວກເຮົາບໍ່ໄດ້ແນະນໍາຕົວແຍກສະເພາະ, ແຕ່ພຽງແຕ່ເພີ່ມມູນຄ່າທີ່ຈໍາເປັນໃຫ້ກັບປ້າຍຊື່ຂອງຮູບພາບສຸດທ້າຍໃນເວລາເຜີຍແຜ່.

NB: ຖ້າທ່ານສົນໃຈເບິ່ງທຸກສິ່ງທຸກຢ່າງທີ່ອະທິບາຍໄວ້ໃນລະຫັດແຫຼ່ງ werf, ຫຼັງຈາກນັ້ນຈຸດເລີ່ມຕົ້ນສາມາດເປັນ PR 1684.

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

ເພື່ອສະຫຼຸບ

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

ຢູ່ກັບພວກເຮົາແລະໃນໄວໆນີ້ພວກເຮົາຈະບອກທ່ານກ່ຽວກັບການປະດິດສ້າງອື່ນໆໃນ werf!

PS

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

• «ໃນປັດຈຸບັນທ່ານສາມາດສ້າງຮູບພາບ Docker ໃນ werf ໂດຍໃຊ້ Dockerfile ປົກກະຕິ"
• «werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes (ພາບລວມແລະບົດລາຍງານວິດີໂອ)".

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