ການແທັກທີ່ອີງໃສ່ເນື້ອຫາໃນຕົວເກັບລວບລວມ werf: ເປັນຫຍັງແລະມັນເຮັດວຽກແນວໃດ?

werf ເປັນແຫຼ່ງເປີດຂອງພວກເຮົາ GitOps CLI utility ສໍາລັບການກໍ່ສ້າງແລະສົ່ງຄໍາຮ້ອງສະຫມັກກັບ Kubernetes. IN ປ່ອຍ v1.1 ຄຸນ​ນະ​ສົມ​ບັດ​ໃຫມ່​ໄດ້​ຖືກ​ນໍາ​ສະ​ເຫນີ​ໃນ​ຕົວ​ເກັບ​ກໍາ​ຮູບ​ພາບ​: tagging ຮູບ​ພາບ​ໂດຍ​ເນື້ອ​ຫາ​ຫຼື​ tagging ອີງໃສ່ເນື້ອໃນ. ຈົນກ່ວາໃນປັດຈຸບັນ, ໂຄງການ tagging ປົກກະຕິໃນ werf ກ່ຽວຂ້ອງກັບການ tag ຮູບພາບ Docker ໂດຍ Git tag, ສາຂາ Git ຫຼື Git commit. ແຕ່ໂຄງການເຫຼົ່ານີ້ທັງຫມົດມີຂໍ້ເສຍທີ່ຖືກແກ້ໄຂຢ່າງສົມບູນໂດຍຍຸດທະສາດການຕິດແທໍກໃຫມ່. ລາຍລະອຽດກ່ຽວກັບມັນແລະເປັນຫຍັງມັນດີຫຼາຍແມ່ນຢູ່ພາຍໃຕ້ການຕັດ.

ເປີດຕົວຊຸດຂອງບໍລິການຈຸລະພາກຈາກບ່ອນເກັບມ້ຽນ Git ດຽວ

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

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

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

Tagging ໂດຍສາຂາ Git ແລະ Git tag

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

ເມື່ອແທັກ Git ໃໝ່ຖືກສ້າງຂື້ນ, ຕົວຢ່າງ, ເມື່ອສະບັບໃຫມ່ຖືກປ່ອຍອອກມາ, ແທັກ Docker ໃໝ່ ຈະຖືກສ້າງຂື້ນສໍາລັບຮູບພາບໂຄງການທັງຫມົດໃນ Docker Registry:

• myregistry.org/myproject/frontend:v1.1.10
• myregistry.org/myproject/myservice1:v1.1.10
• myregistry.org/myproject/myservice2:v1.1.10
• myregistry.org/myproject/myservice3:v1.1.10
• myregistry.org/myproject/myservice4:v1.1.10
• myregistry.org/myproject/myservice5:v1.1.10
• myregistry.org/myproject/database:v1.1.10

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

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

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

Tagging ໂດຍ Git commit

werf ຍັງມີກົນລະຍຸດ tagging ທີ່ກ່ຽວຂ້ອງກັບ Git commits.

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

ຢ່າງໃດກໍ່ຕາມ, ການຕິດແທໍກໂດຍ Git commit ມີຂໍ້ເສຍຄືກັນກັບການແທັກໂດຍສາຂາ Git ຫຼື Git tags:

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

ການແທັກຊື່ສາຂາ Git ບໍ່ສະທ້ອນເຖິງເວີຊັນຂອງຮູບພາບ

ມີບັນຫາອື່ນທີ່ກ່ຽວຂ້ອງກັບຍຸດທະສາດການຕິດແທໍກສໍາລັບສາຂາ Git.

ການແທັກດ້ວຍຊື່ສາຂາເຮັດວຽກໄດ້ຕາບໃດທີ່ຄຳໝັ້ນສັນຍາໃນສາຂານັ້ນຖືກເກັບກຳຕາມລຳດັບຕາມລຳດັບ.

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

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

ການແທັກທີ່ອີງໃສ່ເນື້ອຫາແມ່ນຫຍັງ?

ດັ່ງນັ້ນ, tagging ອີງໃສ່ເນື້ອຫາແມ່ນຫຍັງ - tagging ຮູບພາບໂດຍເນື້ອຫາ.

ເພື່ອສ້າງແທໍກ Docker, ມັນບໍ່ແມ່ນ Git primitives (Git branch, Git tag ...) ທີ່ໃຊ້, ແຕ່ checksum ທີ່ກ່ຽວຂ້ອງກັບ:

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

ແທັກຕົວລະບຸດັ່ງກ່າວເປັນອັນທີ່ເອີ້ນວ່າ ລາຍເຊັນຂອງເວທີຮູບພາບ.

ແຕ່ລະຮູບປະກອບດ້ວຍຊຸດຂອງຂັ້ນຕອນ: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch ແລະອື່ນໆ ແຕ່ລະຂັ້ນຕອນມີຕົວລະບຸທີ່ສະທ້ອນເຖິງເນື້ອໃນຂອງມັນ − ລາຍເຊັນເວທີ (ລາຍເຊັນເວທີ).

ຮູບພາບສຸດທ້າຍ, ປະກອບດ້ວຍຂັ້ນຕອນເຫຼົ່ານີ້, ແມ່ນ tagged ກັບອັນທີ່ເອີ້ນວ່າລາຍເຊັນຂອງຊຸດຂອງຂັ້ນຕອນເຫຼົ່ານີ້ - ລາຍເຊັນຂັ້ນຕອນ, - ເຊິ່ງໂດຍທົ່ວໄປແມ່ນສໍາລັບທຸກຂັ້ນຕອນຂອງຮູບພາບ.

ສໍາລັບແຕ່ລະຮູບພາບຈາກການຕັ້ງຄ່າ werf.yaml ໃນກໍລະນີທົ່ວໄປ, ຈະມີລາຍເຊັນຂອງຕົນເອງແລະ, ຕາມນັ້ນ, ແທັກ Docker.

ລາຍເຊັນຂອງເວທີແກ້ໄຂບັນຫາເຫຼົ່ານີ້ທັງຫມົດ:

• ທົນທານຕໍ່ກັບ Git commits ຫວ່າງເປົ່າ.
• ທົນທານຕໍ່ Git ຫມັ້ນສັນຍາທີ່ຈະປ່ຽນໄຟລ໌ທີ່ບໍ່ກ່ຽວຂ້ອງກັບຮູບພາບ.
• ບໍ່ໄດ້ນໍາໄປສູ່ບັນຫາຂອງການ overhaling ສະບັບປະຈຸບັນຂອງຮູບພາບໃນເວລາທີ່ restarting ການກໍ່ສ້າງສໍາລັບ Git ເກົ່າ commits ຂອງສາຂາ.

ດຽວນີ້ນີ້ແມ່ນຍຸດທະສາດການແທັກທີ່ແນະນຳ ແລະເປັນຄ່າເລີ່ມຕົ້ນໃນ werf ສຳລັບລະບົບ CI ທັງໝົດ.

ວິທີການເປີດໃຊ້ແລະນໍາໃຊ້ໃນ werf

ຄໍາສັ່ງໃນປັດຈຸບັນມີທາງເລືອກທີ່ສອດຄ້ອງກັນ werf publish: --tag-by-stages-signature=true|false

ໃນລະບົບ CI, ຍຸດທະສາດການຕິດແທໍກແມ່ນຖືກກໍານົດໂດຍຄໍາສັ່ງ werf ci-env. ກ່ອນຫນ້ານີ້, ພາລາມິເຕີໄດ້ຖືກກໍານົດສໍາລັບມັນ werf ci-env --tagging-strategy=tag-or-branch. ໃນປັດຈຸບັນ, ຖ້າທ່ານລະບຸ werf ci-env --tagging-strategy=stages-signature ຫຼືບໍ່ລະບຸຕົວເລືອກນີ້, werf ຈະໃຊ້ກົນລະຍຸດການຕິດແທັກໂດຍຄ່າເລີ່ມຕົ້ນ stages-signature. ທີມງານ werf ci-env ອັດຕະໂນມັດຈະກໍານົດທຸງທີ່ຈໍາເປັນສໍາລັບຄໍາສັ່ງ werf build-and-publish (ຫຼື werf publish), ດັ່ງນັ້ນບໍ່ມີທາງເລືອກເພີ່ມເຕີມຈໍາເປັນຕ້ອງຖືກກໍານົດສໍາລັບຄໍາສັ່ງເຫຼົ່ານີ້.

ສໍາລັບຕົວຢ່າງ, ຄໍາສັ່ງ:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...ສາມາດສ້າງຮູບພາບຕໍ່ໄປນີ້:

• registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
• registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

ມັນເປັນ 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ເປັນລາຍເຊັນຂອງຂັ້ນຕອນຂອງຮູບພາບ backendແລະ f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - ລາຍເຊັນຂອງຂັ້ນຕອນຮູບພາບ frontend.

ເມື່ອນໍາໃຊ້ຫນ້າທີ່ພິເສດ werf_container_image и werf_container_env ບໍ່ຈໍາເປັນຕ້ອງມີການປ່ຽນແປງອັນໃດໃນແມ່ແບບ Helm: ຟັງຊັນເຫຼົ່ານີ້ຈະສ້າງຊື່ຮູບພາບທີ່ຖືກຕ້ອງໂດຍອັດຕະໂນມັດ.

ຕົວຢ່າງການຕັ້ງຄ່າໃນລະບົບ CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການຕັ້ງຄ່າແມ່ນມີຢູ່ໃນເອກະສານ:

• ໄດເລກະທໍລີ → ການພິມເຜີຍແຜ່ (ເຜີຍແຜ່);
• ເຮັດວຽກກັບ CI/CD → ຂໍ້ມູນທົ່ວໄປ → ຂັ້ນຕອນ-ລາຍເຊັນ;
• ການປະສົມປະສານກັບ GitLab CI/CD → .gitlab-ci.yml.

ລວມ

• ທາງເລືອກໃຫມ່ werf publish --tag-by-stages-signature=true|false.
• ຄ່າທາງເລືອກໃຫມ່ werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ຖ້າບໍ່ລະບຸ, ຄ່າເລີ່ມຕົ້ນຈະເປັນ stages-signature).
• ຖ້າກ່ອນໜ້ານີ້ເຈົ້າເຄີຍໃຊ້ຕົວເລືອກ tagging ສໍາລັບ Git commits (WERF_TAG_GIT_COMMIT ຫຼືທາງເລືອກ werf publish --tag-git-commit COMMIT), ຫຼັງຈາກນັ້ນໃຫ້ແນ່ໃຈວ່າຈະປ່ຽນໄປສູ່ກົນລະຍຸດ tagging ຂັ້ນ​ຕອນ​ການ​ລາຍ​ເຊັນ​.
• ມັນດີກວ່າທີ່ຈະປ່ຽນໂຄງການໃຫມ່ໃນທັນທີກັບໂຄງການ tagging ໃຫມ່.
• ເມື່ອໂອນໄປຫາ werf 1.1, ແນະນໍາໃຫ້ປ່ຽນໂຄງການເກົ່າໄປຫາໂຄງການ tagging ໃຫມ່, ແຕ່ເກົ່າ. tag-or-ສາຂາ ຍັງໄດ້ຮັບການສະຫນັບສະຫນູນ.

ການຕິດແທໍກໂດຍອີງໃສ່ເນື້ອຫາແກ້ໄຂບັນຫາທັງຫມົດທີ່ກວມເອົາໃນບົດຄວາມ:

• Docker tag name resistance to empty Git commits.
• ການຕໍ່ຕ້ານຊື່ແທັກ Docker ກັບ Git commits ທີ່ປ່ຽນໄຟລ໌ທີ່ບໍ່ກ່ຽວຂ້ອງກັບຮູບພາບ.
• ບໍ່ໄດ້ນໍາໄປສູ່ບັນຫາຂອງການ overhaling ສະບັບປະຈຸບັນຂອງຮູບພາບໃນເວລາທີ່ restarting ການກໍ່ສ້າງສໍາລັບ Git commits ເກົ່າສໍາລັບສາຂາ Git.

ໃຊ້​ມັນ! ແລະຢ່າລືມໄປຢ້ຽມຢາມພວກເຮົາທີ່ GitHubເພື່ອສ້າງບັນຫາຫຼືຊອກຫາທີ່ມີຢູ່ແລ້ວ, ເພີ່ມບວກ, ສ້າງ PR ຫຼືພຽງແຕ່ເບິ່ງການພັດທະນາໂຄງການ.

PS

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

• «ການປ່ອຍ werf 1.1: ການປັບປຸງຜູ້ກໍ່ສ້າງໃນມື້ນີ້ແລະແຜນການສໍາລັບອະນາຄົດ»
• «ການແນະນໍາ werf 1.0 ຄົງທີ່: GitOps ມີຫຍັງແດ່ກ່ຽວກັບມັນ, ສະຖານະພາບແລະແຜນການ»
• «werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes (ພາບລວມແລະບົດລາຍງານວິດີໂອ)"
• ຊຸດບັນທຶກກ່ຽວກັບການປະດິດສ້າງໃນ werf:
  • «ການລວມເຂົ້າກັນ 3 ທາງກັບ werf: ການປະຕິບັດກັບ Kubernetes ດ້ວຍ Helm "ກ່ຽວກັບ steroids""
  • «ການນໍາໃຊ້ werf ເພື່ອເຜີຍແຜ່ຕາຕະລາງ Helm ທີ່ສັບສົນ"
  • «ສະຫນັບສະຫນູນ monorepo ແລະ multirepo ໃນ werf ແລະ Docker Registry ມີຫຍັງແດ່ກ່ຽວກັບມັນ"
  • «ໃນປັດຈຸບັນທ່ານສາມາດສ້າງຮູບພາບ Docker ໃນ werf ໂດຍໃຊ້ Dockerfile ປົກກະຕິ".

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