ການປ່ອຍ werf 1.1: ການປັບປຸງຜູ້ກໍ່ສ້າງໃນມື້ນີ້ແລະແຜນການສໍາລັບອະນາຄົດ

werf ເປັນແຫຼ່ງເປີດຂອງພວກເຮົາ GitOps CLI utility ສໍາລັບການກໍ່ສ້າງແລະສົ່ງຄໍາຮ້ອງສະຫມັກກັບ Kubernetes. ຕາມສັນຍາ, ການປ່ອຍເວີຊັນ v1.0 ຫມາຍຈຸດເລີ່ມຕົ້ນຂອງການເພີ່ມລັກສະນະໃຫມ່ໃຫ້ກັບ werf ແລະການປັບປຸງວິທີການແບບດັ້ງເດີມ. ໃນປັດຈຸບັນພວກເຮົາມີຄວາມຍິນດີທີ່ຈະນໍາສະເຫນີການປ່ອຍ v1.1, ເຊິ່ງເປັນບາດກ້າວອັນໃຫຍ່ຫຼວງໃນການພັດທະນາແລະພື້ນຖານສໍາລັບອະນາຄົດ ຜູ້ເກັບ werf. ສະບັບປະຈຸບັນແມ່ນມີຢູ່ໃນ ຊ່ອງ 1.1 ea.

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

ການເພີ່ມປະສິດທິພາບຂອງການເຮັດວຽກປະກອບມີການກໍາຈັດການຄິດໄລ່ທີ່ບໍ່ຈໍາເປັນໃນຂັ້ນຕອນຂອງການຄິດໄລ່ລາຍເຊັນຂອງຂັ້ນຕອນແລະການປ່ຽນແປງກົນໄກການຄິດໄລ່ໄຟລ໌ checksums ທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ. ການເພີ່ມປະສິດທິພາບນີ້ຈະຫຼຸດຜ່ອນເວລາສະເລ່ຍຂອງການສ້າງໂຄງການໂດຍໃຊ້ werf. ແລະ idle builds, ໃນເວລາທີ່ຂັ້ນຕອນທັງຫມົດມີຢູ່ໃນ cache ຂັ້ນ​ຕອນ​ການ​ເກັບ​ຮັກ​ສາ​, ໃນປັດຈຸບັນແມ່ນໄວແທ້ໆ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ການເລີ່ມຕົ້ນການກໍ່ສ້າງຄືນໃຫມ່ຈະໃຊ້ເວລາຫນ້ອຍກວ່າ 1 ວິນາທີ! ນີ້ຍັງໃຊ້ກັບຂັ້ນຕອນການກວດສອບຂັ້ນຕອນໃນຂະບວນການເຮັດວຽກຂອງທີມງານ. werf deploy и werf run.

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

ຂໍໃຫ້ພິຈາລະນາເບິ່ງການປະດິດສ້າງທີ່ສໍາຄັນໃນ werf v1.1, ແລະໃນເວລາດຽວກັນບອກທ່ານກ່ຽວກັບແຜນການສໍາລັບອະນາຄົດ.

ມີການປ່ຽນແປງຫຍັງໃນ werf v1.1?

ຮູບແບບການຕັ້ງຊື່ຂັ້ນຕອນ ແລະສູດການຄິດໄລ່ໃໝ່ສຳລັບການເລືອກຂັ້ນຕອນຈາກແຄດ

ກົດລະບຽບການສ້າງຊື່ເວທີໃຫມ່. ໃນປັດຈຸບັນແຕ່ລະຂັ້ນຕອນການສ້າງສ້າງຊື່ເວທີທີ່ເປັນເອກະລັກ, ເຊິ່ງປະກອບດ້ວຍ 2 ສ່ວນ: ລາຍເຊັນ (ຕາມທີ່ມັນຢູ່ໃນ v1.0) ບວກກັບຕົວລະບຸຊົ່ວຄາວທີ່ບໍ່ຊ້ໍາກັນ.

ຕົວຢ່າງ, ຊື່ຮູບພາບເຕັມຮູບແບບອາດເບິ່ງຄືວ່ານີ້:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... ຫຼືໂດຍທົ່ວໄປ:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ທີ່ນີ້:

• SIGNATURE ແມ່ນລາຍເຊັນຂອງເວທີ, ເຊິ່ງເປັນຕົວແທນຂອງຕົວລະບຸຂອງເນື້ອຫາເວທີແລະຂຶ້ນກັບປະຫວັດຂອງການແກ້ໄຂໃນ Git ທີ່ນໍາໄປສູ່ເນື້ອຫານີ້;
• TIMESTAMP_MILLISEC ແມ່ນຕົວລະບຸຮູບພາບທີ່ເປັນເອກະລັກທີ່ຮັບປະກັນທີ່ຖືກສ້າງຂຶ້ນໃນເວລາທີ່ຮູບພາບໃຫມ່ຖືກສ້າງຂຶ້ນ.

ສູດການຄິດໄລ່ສໍາລັບການເລືອກຂັ້ນຕອນຈາກ cache ແມ່ນອີງໃສ່ການກວດສອບຄວາມສໍາພັນຂອງ Git commits:

1. Werf ຄິດໄລ່ລາຍເຊັນຂອງຂັ້ນຕອນທີ່ແນ່ນອນ.
2. В ຂັ້ນ​ຕອນ​ການ​ເກັບ​ຮັກ​ສາ​ ອາດຈະມີຫຼາຍຂັ້ນຕອນສໍາລັບລາຍເຊັນທີ່ໃຫ້. Werf ເລືອກທຸກຂັ້ນຕອນທີ່ກົງກັບລາຍເຊັນ.
3. ຖ້າຂັ້ນຕອນປະຈຸບັນເຊື່ອມໂຍງກັບ Git (git-archive, ຂັ້ນຕອນທີ່ກໍາຫນົດເອງກັບ Git patches: install, beforeSetup, setup; ຫຼື git-latest-patch), ຫຼັງຈາກນັ້ນ werf ເລືອກພຽງແຕ່ຂັ້ນຕອນເຫຼົ່ານັ້ນທີ່ກ່ຽວຂ້ອງກັບຄໍາຫມັ້ນສັນຍາທີ່ເປັນບັນພະບຸລຸດຂອງຄໍາຫມັ້ນສັນຍາໃນປະຈຸບັນ (ສໍາລັບການກໍ່ສ້າງແມ່ນເອີ້ນວ່າ).
4. ຈາກຂັ້ນຕອນທີ່ເຫມາະສົມທີ່ຍັງເຫຼືອ, ຫນຶ່ງແມ່ນເລືອກ - ເກົ່າແກ່ທີ່ສຸດໂດຍວັນທີສ້າງ.

ເວທີສໍາລັບສາຂາ Git ທີ່ແຕກຕ່າງກັນສາມາດມີລາຍເຊັນດຽວກັນ. ແຕ່ werf ຈະປ້ອງກັນບໍ່ໃຫ້ cache ທີ່ກ່ຽວຂ້ອງກັບສາຂາທີ່ແຕກຕ່າງກັນຈາກການນໍາໃຊ້ລະຫວ່າງສາຂາເຫຼົ່ານີ້, ເຖິງແມ່ນວ່າລາຍເຊັນຈະກົງກັນ.

→ ເອກະສານ.

ສູດການຄິດໄລ່ໃຫມ່ສໍາລັບການສ້າງແລະປະຫຍັດຂັ້ນຕອນໃນການເກັບຮັກສາເວທີ

ຖ້າຫາກວ່າ, ໃນເວລາທີ່ເລືອກຂັ້ນຕອນຈາກຖານຄວາມຈໍາ, werf ບໍ່ພົບຂັ້ນຕອນທີ່ເຫມາະສົມ, ຫຼັງຈາກນັ້ນຂະບວນການປະກອບຂັ້ນຕອນໃຫມ່ແມ່ນເລີ່ມຕົ້ນ.

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

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

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

→ ເອກະສານ.

ປັບປຸງປະສິດທິພາບຕົວສ້າງ Dockerfile

ໃນປັດຈຸບັນ, ທໍ່ຂອງຂັ້ນຕອນສໍາລັບຮູບພາບທີ່ສ້າງຂຶ້ນຈາກ Dockerfile ປະກອບດ້ວຍຂັ້ນຕອນຫນຶ່ງ - dockerfile. ເມື່ອຄິດໄລ່ລາຍເຊັນ, checksum ຂອງໄຟລ໌ຖືກຄິດໄລ່ context, ເຊິ່ງຈະຖືກນໍາໃຊ້ໃນລະຫວ່າງການປະກອບ. ກ່ອນທີ່ຈະປັບປຸງນີ້, werf ໄດ້ recursively ຍ່າງຜ່ານໄຟລ໌ທັງຫມົດແລະໄດ້ຮັບ checksum ໂດຍການສະຫຼຸບສະພາບການແລະຮູບແບບຂອງແຕ່ລະໄຟລ໌. ເລີ່ມຕົ້ນດ້ວຍ v1.1, werf ສາມາດໃຊ້ checksums ທີ່ຖືກຄິດໄລ່ທີ່ເກັບໄວ້ໃນ Git repository.

ສູດການຄິດໄລ່ແມ່ນອີງໃສ່ git ls-tree. ສູດການຄິດໄລ່ໃຊ້ເວລາເຂົ້າໄປໃນບັນທຶກບັນຊີໃນ .dockerignore ແລະຂ້າມຕົ້ນໄມ້ໄຟລ໌ recursively ເມື່ອມີຄວາມຈໍາເປັນ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ decoupled ຈາກການອ່ານລະບົບໄຟລ໌, ແລະການເອື່ອຍອີງຂອງ algorithm ກ່ຽວກັບຂະຫນາດ. context ແມ່ນບໍ່ສໍາຄັນ.

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

ປັບປຸງປະສິດທິພາບໃນເວລານໍາເຂົ້າໄຟລ໌

ເວີຊັນຂອງ werf v1.1 ໃຊ້ເຊີບເວີ rsync ເມື່ອ ການ​ນໍາ​ເຂົ້າ​ໄຟລ​໌​ຈາກ​ປອມ​ແລະ​ຮູບ​ພາບ​. ກ່ອນຫນ້ານີ້, ການນໍາເຂົ້າແມ່ນເຮັດໃນສອງຂັ້ນຕອນໂດຍໃຊ້ directory mount ຈາກລະບົບໂຮດ.

ການປະຕິບັດການນໍາເຂົ້າໃນ macOS ບໍ່ໄດ້ຖືກຈໍາກັດໂດຍປະລິມານ Docker ອີກຕໍ່ໄປ, ແລະການນໍາເຂົ້າສໍາເລັດໃນຈໍານວນເວລາດຽວກັນກັບ Linux ແລະ Windows.

ການແທັກຕາມເນື້ອຫາ

Werf v1.1 ສະຫນັບສະຫນູນອັນທີ່ເອີ້ນວ່າ tagging ໂດຍເນື້ອຫາຮູບພາບ - tagging ອີງໃສ່ເນື້ອໃນ. tags ຂອງຮູບພາບ Docker ຜົນໄດ້ຮັບແມ່ນຂຶ້ນກັບເນື້ອໃນຂອງຮູບພາບເຫຼົ່ານີ້.

ເມື່ອແລ່ນຄໍາສັ່ງ werf publish --tags-by-stages-signature ຫຼື werf ci-env --tagging-strategy=stages-signature ຈັດພີມມາຮູບພາບຂອງອັນທີ່ເອີ້ນວ່າ ລາຍເຊັນເວທີ ຮູບ. ແຕ່ລະຮູບຖືກແທັກດ້ວຍລາຍເຊັນຂອງຕົນເອງຂອງຂັ້ນຕອນຂອງຮູບນີ້, ເຊິ່ງຄິດໄລ່ຕາມກົດລະບຽບດຽວກັນກັບລາຍເຊັນປົກກະຕິຂອງແຕ່ລະຂັ້ນຕອນແຍກຕ່າງຫາກ, ແຕ່ເປັນຕົວລະບຸທົ່ວໄປຂອງຮູບພາບ.

ລາຍເຊັນຂອງຂັ້ນຕອນຮູບພາບແມ່ນຂຶ້ນກັບ:

1. ເນື້ອໃນຂອງຮູບພາບນີ້;
2. ປະຫວັດສາດຂອງການປ່ຽນແປງ Git ທີ່ນໍາໄປສູ່ເນື້ອຫານີ້.

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

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

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

ທີ່ສໍາຄັນ: ເລີ່ມ​ແຕ່​ນີ້​ ຂັ້ນ​ຕອນ​ການ​ລາຍ​ເຊັນ​ - ນີ້​ແມ່ນ ຍຸດທະສາດການແທັກທີ່ແນະນໍາເທົ່ານັ້ນ. ມັນຈະຖືກນໍາໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນໃນຄໍາສັ່ງ werf ci-env (ເວັ້ນເສຍແຕ່ວ່າທ່ານລະບຸຢ່າງຈະແຈ້ງກ່ຽວກັບໂຄງການ tagging ທີ່ແຕກຕ່າງກັນ).

→ ເອກະສານ. ການພິມເຜີຍແຜ່ແຍກຕ່າງຫາກຈະຖືກອຸທິດໃຫ້ກັບຄຸນສົມບັດນີ້ເຊັ່ນກັນ. ອັບເດດແລ້ວ (3 ເມສາ): ບົດຄວາມທີ່ມີລາຍລະອຽດ ຈັດພີມມາ.

ລະດັບການບັນທຶກ

ຜູ້ໃຊ້ໃນປັດຈຸບັນມີໂອກາດທີ່ຈະຄວບຄຸມຜົນຜະລິດ, ກໍານົດລະດັບການບັນທຶກແລະເຮັດວຽກກັບຂໍ້ມູນ debugging. ເພີ່ມທາງເລືອກ --log-quiet, --log-verbose, --log-debug.

ໂດຍຄ່າເລີ່ມຕົ້ນ, ຜົນຜະລິດປະກອບມີຂໍ້ມູນຕໍາ່ສຸດທີ່:

ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ຜົນ​ຜະ​ລິດ verbose (--log-verbose) ທ່ານສາມາດເບິ່ງວິທີການ werf ເຮັດວຽກ:

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

ແຜນການໃນອະນາຄົດ

ລະ​ມັດ​ລະ​ວັງ ທາງເລືອກທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້ແມ່ນຫມາຍ v1.1 ຈະມີຢູ່ໃນສະບັບນີ້, ຈໍານວນຫຼາຍຂອງພວກເຂົາໃນອະນາຄົດອັນໃກ້ນີ້. ການອັບເດດຈະມາໂດຍການອັບເດດອັດຕະໂນມັດ ເມື່ອໃຊ້ multiwerf. ຄຸນສົມບັດເຫຼົ່ານີ້ບໍ່ມີຜົນຕໍ່ສ່ວນທີ່ໝັ້ນຄົງຂອງຟັງຊັນ v1.1; ຮູບລັກສະນະຂອງພວກມັນຈະບໍ່ຮຽກຮ້ອງໃຫ້ມີການແຊກແຊງຂອງຜູ້ໃຊ້ດ້ວຍຕົນເອງໃນການຕັ້ງຄ່າທີ່ມີຢູ່.

ສະຫນັບສະຫນູນຢ່າງເຕັມທີ່ສໍາລັບການປະຕິບັດ Docker Registry ຕ່າງໆ (ໃຫມ່)

• ລຸ້ນ: v1.1
• ວັນທີ: ມີນາ
• ບັນຫາ

ເປົ້າຫມາຍແມ່ນເພື່ອໃຫ້ຜູ້ໃຊ້ໃຊ້ການປະຕິບັດແບບກໍາຫນົດເອງໂດຍບໍ່ມີຂໍ້ຈໍາກັດໃນເວລາທີ່ໃຊ້ werf.

ໃນປັດຈຸບັນ, ພວກເຮົາໄດ້ກໍານົດຊຸດການແກ້ໄຂຕໍ່ໄປນີ້ທີ່ພວກເຮົາຈະຮັບປະກັນການສະຫນັບສະຫນູນຢ່າງເຕັມທີ່:

• ຄ່າເລີ່ມຕົ້ນ (ຫ້ອງສະໝຸດ/ການລົງທະບຽນ)*,
• AWS ECR
• Azure *,
• Docker Hub
• GCR*,
• ແພັກເກດ GitHub
• GitLab Registry*,
• ທ່າເຮືອ*,
• ຮ່ອມ.

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

ສອງບັນຫາຕົ້ນຕໍສາມາດຖືກກໍານົດ:

• ວິທີແກ້ໄຂບາງຢ່າງບໍ່ສະຫນັບສະຫນູນການຖອນແທັກໂດຍໃຊ້ Docker Registry API, ປ້ອງກັນບໍ່ໃຫ້ຜູ້ໃຊ້ໃຊ້ການເຮັດຄວາມສະອາດອັດຕະໂນມັດຂອງ werf. ນີ້ແມ່ນຄວາມຈິງສໍາລັບ AWS ECR, Docker Hub, ແລະແພັກເກດ GitHub.
• ບາງວິທີແກ້ໄຂບໍ່ຮອງຮັບອັນທີ່ເອີ້ນວ່າ nested repositories (Docker Hub, GitHub Packages ແລະ Quay) ຫຼືເຮັດ, ແຕ່ຜູ້ໃຊ້ຕ້ອງສ້າງພວກມັນດ້ວຍຕົນເອງໂດຍໃຊ້ UI ຫຼື API (AWS ECR).

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

ການສ້າງຮູບພາບທີ່ແຈກຢາຍ (↑)

• ລຸ້ນ: v1.2 v1.1 (ບູລິມະສິດໃນການປະຕິບັດຄຸນສົມບັດນີ້ເພີ່ມຂຶ້ນ)
• ວັນທີ: ເດືອນມີນາ - ເດືອນເມສາເດືອນມີນາ
• ບັນຫາ

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

ເພື່ອເປີດຄວາມເປັນໄປໄດ້ຂອງການເຮັດວຽກທີ່ແຈກຢາຍຂອງ werf, ເມື່ອການກໍ່ສ້າງແລະການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກໃນ Kubernetes ຖືກເປີດຕົວໃນຫລາຍ host arbitrary ແລະເຈົ້າພາບເຫຼົ່ານີ້ບໍ່ໄດ້ຊ່ວຍປະຢັດລັດຂອງພວກເຂົາລະຫວ່າງ builds (ນັກແລ່ນຊົ່ວຄາວ), werf ແມ່ນຈໍາເປັນເພື່ອປະຕິບັດຄວາມສາມາດໃນການນໍາໃຊ້. Docker Registry ເປັນຮ້ານຄ້າເວທີ.

ກ່ອນຫນ້ານີ້, ໃນເວລາທີ່ໂຄງການ werf ຍັງເອີ້ນວ່າ dapp, ມັນມີໂອກາດດັ່ງກ່າວ. ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາໄດ້ພົບກັບບັນຫາຈໍານວນຫນຶ່ງທີ່ຕ້ອງໄດ້ຮັບການພິຈາລະນາໃນເວລາປະຕິບັດຫນ້າທີ່ນີ້ໃນ werf.

Примечание. ຄຸນສົມບັດນີ້ບໍ່ຮຽກຮ້ອງໃຫ້ຕົວເກັບລວບລວມເຮັດວຽກພາຍໃນຝັກ Kubernetes, ເພາະວ່າ ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ກໍາຈັດການເອື່ອຍອີງຈາກເຄື່ອງແມ່ຂ່າຍຂອງ Docker ທ້ອງຖິ່ນ (ໃນ pod Kubernetes ບໍ່ມີການເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍຂອງ Docker ທ້ອງຖິ່ນ, ເນື່ອງຈາກວ່າຂະບວນການຕົວມັນເອງແມ່ນແລ່ນຢູ່ໃນ container, ແລະ werf ບໍ່ແລະຈະບໍ່ສະຫນັບສະຫນູນ. ເຮັດວຽກກັບເຊີບເວີ Docker ຜ່ານເຄືອຂ່າຍ). ການສະຫນັບສະຫນູນການແລ່ນ Kubernetes ຈະຖືກປະຕິບັດແຍກຕ່າງຫາກ.

ສະຫນັບສະຫນູນຢ່າງເປັນທາງການສໍາລັບ GitHub Actions (ໃຫມ່)

• ລຸ້ນ: v1.1
• ວັນທີ: ມີນາ
• ບັນຫາ

ລວມມີເອກະສານ werf (ພາກສ່ວນ ອ້າງອິງ и ແນະ​ນໍາ), ເຊັ່ນດຽວກັນກັບ GitHub Action ຢ່າງເປັນທາງການສໍາລັບການເຮັດວຽກກັບ werf.

ນອກຈາກນັ້ນ, ມັນຈະຊ່ວຍໃຫ້ werf ເຮັດວຽກກ່ຽວກັບນັກແລ່ນ ephemeral.

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

ການພັດທະນາທ້ອງຖິ່ນແລະການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ມີ werf (↓)

• ລຸ້ນ: v1.1
• ວັນທີ: ມັງກອນຫາເດືອນກຸມພາເດືອນເມສາ
• ບັນຫາ

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

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

ຂັ້ນຕອນການທຳຄວາມສະອາດໃໝ່ (ໃໝ່)

• ລຸ້ນ: v1.1
• ວັນທີ: ເດືອນເມສາ
• ບັນຫາ

ໃນສະບັບປະຈຸບັນຂອງ werf v1.1 ໃນຂັ້ນຕອນການ cleanup ບໍ່ມີການສະຫນອງການທໍາຄວາມສະອາດຮູບພາບສໍາລັບໂຄງການ tagging ໂດຍອີງໃສ່ເນື້ອຫາ - ຮູບພາບເຫຼົ່ານີ້ຈະສະສົມ.

ນອກຈາກນີ້, ສະບັບປະຈຸບັນຂອງ werf (v1.0 ແລະ v1.1) ໃຊ້ນະໂຍບາຍການທໍາຄວາມສະອາດທີ່ແຕກຕ່າງກັນສໍາລັບຮູບພາບທີ່ຈັດພີມມາພາຍໃຕ້ໂຄງການ tagging: ສາຂາ Git, Git tag ຫຼື Git commit.

ສູດການຄິດໄລ່ໃຫມ່ສໍາລັບການທໍາຄວາມສະອາດຮູບພາບໂດຍອີງໃສ່ປະຫວັດສາດຂອງຄໍາຫມັ້ນສັນຍາໃນ Git, unified ສໍາລັບໂຄງການ tagging ທັງຫມົດ, ໄດ້ຖືກ invented:

• ຮັກສາຮູບພາບ N1 ທີ່ບໍ່ມີຫຼາຍກ່ວາທີ່ກ່ຽວຂ້ອງກັບຄໍາຫມັ້ນສັນຍາ N2 ຫຼ້າສຸດສໍາລັບແຕ່ລະ git HEAD (ສາຂາແລະ tags).
• ເກັບຮັກສາຮູບພາບບໍ່ເກີນ N1 ທີ່ກ່ຽວຂ້ອງກັບ N2 ສັນຍາຫຼ້າສຸດສໍາລັບແຕ່ລະ git HEAD (ສາຂາແລະ tags).
• ເກັບຮັກສາຮູບພາບທັງຫມົດທີ່ຖືກນໍາໃຊ້ໃນຊັບພະຍາກອນຂອງກຸ່ມ Kubernetes ໃດໆ (ສະພາບການ kube ທັງຫມົດຂອງໄຟລ໌ການຕັ້ງຄ່າແລະ namespaces ໄດ້ຖືກສະແກນ; ທ່ານສາມາດຈໍາກັດພຶດຕິກໍານີ້ດ້ວຍທາງເລືອກພິເສດ).
• ເກັບຮັກສາຮູບພາບທັງຫມົດທີ່ຖືກນໍາໃຊ້ໃນ manifests ການຕັ້ງຄ່າຊັບພະຍາກອນທີ່ບັນທຶກໄວ້ໃນການປ່ອຍ Helm.
• ຮູບພາບສາມາດຖືກລຶບໄດ້ຖ້າມັນບໍ່ກ່ຽວຂ້ອງກັບ HEAD ໃດໆຈາກ git (ຕົວຢ່າງ, ເພາະວ່າ HEAD ທີ່ສອດຄ້ອງກັນຂອງມັນເອງຖືກລຶບແລ້ວ) ແລະບໍ່ໄດ້ຖືກນໍາໃຊ້ໃນ manifests ໃດໆໃນກຸ່ມ Kubernetes ແລະໃນການປ່ອຍ Helm.

ການສ້າງຮູບຂະໜານ (↓)

• ລຸ້ນ: v1.1
• ວັນທີ: ມັງກອນ-ກຸມພາ ເມສາ*

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

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

ການປ່ຽນໄປສູ່ Helm 3 (↓)

• ລຸ້ນ: v1.2
• ວັນທີ: ກຸມພາ-ມີນາ ພຶດສະພາ*

ຮວມການຍ້າຍໄປຫາຖານລະຫັດໃໝ່ ໝວກ3 ແລະເປັນວິທີທີ່ສະດວກໃນການເຄື່ອນຍ້າຍການຕິດຕັ້ງທີ່ມີຢູ່ແລ້ວ.

* ຫມາຍເຫດ: ການປ່ຽນໄປໃຊ້ Helm 3 ຈະບໍ່ເພີ່ມລັກສະນະທີ່ສໍາຄັນກັບ werf, ເພາະວ່າລັກສະນະທີ່ສໍາຄັນທັງຫມົດຂອງ Helm 3 (3-way-merge ແລະບໍ່ມີ tiller) ຖືກປະຕິບັດແລ້ວໃນ werf. ຍິ່ງໄປກວ່ານັ້ນ, werf ມີ ລັກສະນະເພີ່ມເຕີມ ນອກ​ເຫນືອ​ໄປ​ຈາກ​ທີ່​ໄດ້​ລະ​ບຸ​ໄວ້​. ຢ່າງໃດກໍ່ຕາມ, ການປ່ຽນແປງນີ້ຍັງຄົງຢູ່ໃນແຜນການຂອງພວກເຮົາແລະຈະຖືກປະຕິບັດ.

Jsonnet ສໍາ​ລັບ​ການ​ອະ​ທິ​ບາຍ​ການ​ຕັ້ງ​ຄ່າ Kubernetes (↓​)

• ລຸ້ນ: v1.2
• ວັນທີ: ມັງກອນ-ກຸມພາ ເມສາ-ເດືອນພຶດສະພາ

Werf ຈະສະຫນັບສະຫນູນຄໍາອະທິບາຍການຕັ້ງຄ່າສໍາລັບ Kubernetes ໃນຮູບແບບ Jsonnet. ໃນເວລາດຽວກັນ, werf ຈະຍັງຄົງເຫມາະສົມກັບ Helm ແລະຈະມີທາງເລືອກຂອງຮູບແບບຄໍາອະທິບາຍ.

ເຫດຜົນແມ່ນວ່າ Go templates, ອີງຕາມປະຊາຊົນຈໍານວນຫຼາຍ, ມີອຸປະສັກເຂົ້າສູງ, ແລະຄວາມເຂົ້າໃຈຂອງລະຫັດຂອງແມ່ແບບເຫຼົ່ານີ້ຍັງທົນທຸກ.

ຄວາມເປັນໄປໄດ້ຂອງການນໍາສະເຫນີລະບົບຄໍາອະທິບາຍການຕັ້ງຄ່າ Kubernetes ອື່ນໆ (ຕົວຢ່າງ, Kustomize) ຍັງຖືກພິຈາລະນາ.

ເຮັດວຽກຢູ່ໃນ Kubernetes (↓)

• ລຸ້ນ: v1.2
• ວັນທີ: ເດືອນເມສາຫາເດືອນພຶດສະພາເດືອນພຶດສະພາຫາເດືອນມິຖຸນາ

ເປົ້າໝາຍ: ໃຫ້ແນ່ໃຈວ່າສ້າງຮູບພາບ ແລະແອັບພລິເຄຊັນຖືກສົ່ງໂດຍໃຊ້ຕົວແລ່ນໃນ Kubernetes. ເຫຼົ່ານັ້ນ. ຮູບພາບໃໝ່ສາມາດສ້າງ, ເຜີຍແຜ່, ອະນາໄມ ແລະນຳໃຊ້ໄດ້ໂດຍກົງຈາກຝັກ Kubernetes.

ເພື່ອປະຕິບັດຄວາມສາມາດນີ້, ທໍາອິດທ່ານຈໍາເປັນຕ້ອງສາມາດສ້າງຮູບພາບທີ່ແຈກຢາຍ (ເບິ່ງຈຸດຂ້າງເທິງ).

ມັນຍັງຮຽກຮ້ອງໃຫ້ມີການສະຫນັບສະຫນູນສໍາລັບຮູບແບບການເຮັດວຽກຂອງຜູ້ສ້າງໂດຍບໍ່ມີເຄື່ອງແມ່ຂ່າຍ Docker (i. e. ການກໍ່ສ້າງຄ້າຍຄື Kaniko ຫຼື build in userspace).

Werf ຈະສະຫນັບສະຫນູນການກໍ່ສ້າງໃນ Kubernetes ບໍ່ພຽງແຕ່ກັບ Dockerfile, ແຕ່ຍັງກັບຕົວສ້າງ Stapel ຂອງມັນດ້ວຍການເພີ່ມການກໍ່ສ້າງໃຫມ່ແລະ Ansible.

ກ້າວ​ໄປ​ສູ່​ການ​ພັດ​ທະ​ນາ​ທີ່​ເປີດ​

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

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

• ເອກະສານແລະສະຖານທີ່;
• ການທົດສອບ;
• ບັກ ແລະ UX ບໍ່ດີ;
• 1.1.

ວຽກງານຫຼາຍຢ່າງໄດ້ຖືກປະຕິບັດກັບບັນຫາ:

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

ວິທີການເປີດໃຊ້ເວີຊັນ v1.1

ສະບັບປະຈຸບັນແມ່ນມີຢູ່ໃນ ຊ່ອງ 1.1 ea (ໃນຊ່ອງ ຫມັ້ນຄົງ и ຫີນແຂງ ການປ່ອຍອອກມາຈະປາກົດໃນຂະນະທີ່ສະຖຽນລະພາບເກີດຂຶ້ນ, ຢ່າງໃດກໍຕາມ ea ຕົວຂອງມັນເອງມີຄວາມຫມັ້ນຄົງພຽງພໍສໍາລັບການນໍາໃຊ້, ເພາະວ່າ ໄດ້ຜ່ານຊ່ອງທາງຕ່າງໆ alpha и ທົດລອງ). ເປີດໃຊ້ແລ້ວ ຜ່ານ multiwerf ໃນ​ວິ​ທີ​ການ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

ສະຫລຸບ

ຖາປັດຕະຍະການເກັບຮັກສາຂັ້ນຕອນໃຫມ່ແລະການເພີ່ມປະສິດທິພາບຂອງຕົວສ້າງສໍາລັບຜູ້ສ້າງ Stapel ແລະ Dockerfile ເປີດຄວາມເປັນໄປໄດ້ຂອງການປະຕິບັດການແຈກຢາຍແລະຂະຫນານໃນ werf. ຄຸນສົມບັດເຫຼົ່ານີ້ຈະປາກົດຢູ່ໃນລຸ້ນ v1.1 ດຽວກັນໃນໄວໆນີ້ ແລະຈະສາມາດໃຊ້ໄດ້ໂດຍອັດຕະໂນມັດຜ່ານກົນໄກການອັບເດດອັດຕະໂນມັດ (ສຳລັບຜູ້ໃຊ້ multiwerf).

ໃນການປ່ອຍນີ້, ຍຸດທະສາດການຕິດແທັກໂດຍອີງໃສ່ເນື້ອຫາຮູບພາບໄດ້ຖືກເພີ່ມ - tagging ອີງໃສ່ເນື້ອໃນ, ເຊິ່ງໄດ້ກາຍເປັນຍຸດທະສາດເລີ່ມຕົ້ນ. ບັນ​ທຶກ​ຄໍາ​ສັ່ງ​ຕົ້ນ​ຕໍ​ຍັງ​ໄດ້​ຮັບ​ການ​ເຮັດ​ວຽກ​ໃຫມ່​: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

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

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

PS

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

• «ການແນະນໍາ 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