ການສ້າງແບບເຄື່ອນໄຫວ ແລະການນຳໃຊ້ຮູບພາບ Docker ດ້ວຍ werf ໃນຕົວຢ່າງຂອງເວັບໄຊເອກະສານສະບັບ

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

ເຂົ້າໄປໃນ nuances ຂອງໂຄງສ້າງເວັບໄຊທ໌: ການສ້າງເມນູທົ່ວໄປສໍາລັບທຸກຮຸ່ນ, ຫນ້າທີ່ມີຂໍ້ມູນກ່ຽວກັບການປ່ອຍ, ແລະອື່ນໆ. - ພວກເຮົາຈະບໍ່. ແທນທີ່ຈະ, ໃຫ້ພວກເຮົາສຸມໃສ່ບັນຫາແລະລັກສະນະຂອງການປະກອບແບບເຄື່ອນໄຫວແລະເລັກນ້ອຍກ່ຽວກັບຂະບວນການ CI / CD ທີ່ມາພ້ອມກັບ.

ແນະນໍາ: ເວັບໄຊທ໌ເຮັດວຽກແນວໃດ

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

• ຟັງຊັນໃຫມ່ຂອງ werf ບໍ່ຄວນຈະຖືກປ່ອຍອອກມາໂດຍບໍ່ມີການປັບປຸງເອກະສານແລະ, ໃນທາງກັບກັນ, ການປ່ຽນແປງໃດໆໃນເອກະສານຫມາຍເຖິງການປ່ອຍ werf ຮຸ່ນໃຫມ່;
• ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ມີ​ການ​ພັດ​ທະ​ນາ​ທີ່​ເຂັ້ມ​ແຂງ​ທີ່​ເປັນ​ທໍາ​: ສະ​ບັບ​ໃຫມ່​ສາ​ມາດ​ອອກ​ໄດ້​ຫຼາຍ​ຄັ້ງ​ຕໍ່​ມື້​;
• ການປະຕິບັດຄູ່ມືໃດໆເພື່ອນໍາໄປໃຊ້ເວັບໄຊທີ່ມີເອກະສານສະບັບໃຫມ່ແມ່ນຢ່າງຫນ້ອຍ tedious;
• ໂຄງການດັ່ງກ່າວຮັບຮອງເອົາວິທີການ semantic ສະບັບ, ມີ 5 ຊ່ອງສະຖຽນລະພາບ. ຂະບວນການປ່ອຍປະກອບມີການຖ່າຍທອດຕາມລໍາດັບຂອງຮຸ່ນຜ່ານຊ່ອງທາງຕ່າງໆເພື່ອຄວາມຫມັ້ນຄົງທີ່ເພີ່ມຂຶ້ນ: ຈາກ alpha ກັບ rock-solid;
• ເວັບໄຊດັ່ງກ່າວມີສະບັບພາສາລັດເຊຍ, ເຊິ່ງ "ດໍາລົງຊີວິດແລະພັດທະນາ" (i.e. ເນື້ອໃນຂອງການປັບປຸງ) ໃນຂະຫນານກັບສະບັບພາສາຕົ້ນຕໍ (i.e. ພາສາອັງກິດ).

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

ໃນເມນູການຄັດເລືອກສະບັບຢູ່ໃນເວັບໄຊທ໌, ສະບັບຫລ້າສຸດຂອງ werf ແມ່ນມີຢູ່ໃນແຕ່ລະຊ່ອງທາງ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕາມທີ່ຢູ່ werf.io/documentation ສະບັບຂອງຊ່ອງທາງທີ່ຫມັ້ນຄົງທີ່ສຸດສໍາລັບການປ່ອຍຫລ້າສຸດເປີດ - ມັນຍັງຖືກດັດສະນີໂດຍເຄື່ອງຈັກຊອກຫາ. ເອກະສານສໍາລັບຊ່ອງທາງແມ່ນມີຢູ່ໃນທີ່ຢູ່ແຍກຕ່າງຫາກ (ຕົວຢ່າງ, werf.io/v1.0-beta/documentation ສໍາລັບການປ່ອຍເບຕ້າ 1.0).

ໃນຈໍານວນທັງຫມົດ, ເວັບໄຊທ໌ມີສະບັບດັ່ງຕໍ່ໄປນີ້ສາມາດໃຊ້ໄດ້:

1. ຮາກ (ເປີດໂດຍຄ່າເລີ່ມຕົ້ນ),
2. ສໍາລັບແຕ່ລະຊ່ອງການປັບປຸງທີ່ມີການເຄື່ອນໄຫວຂອງແຕ່ລະການປ່ອຍ (ຕົວຢ່າງ: werf.io/v1.0-beta).

ເພື່ອສ້າງສະບັບສະເພາະຂອງເວັບໄຊທ໌, ໂດຍທົ່ວໄປ, ມັນພຽງພໍທີ່ຈະລວບລວມມັນໂດຍໃຊ້ Jekyllໂດຍແລ່ນຢູ່ໃນໄດເລກະທໍລີ /docs werf repository ຄໍາ​ສັ່ງ​ທີ່​ສອດ​ຄ້ອງ​ກັນ (jekyll build), ຫຼັງຈາກສະຫຼັບກັບແທັກ Git ຂອງສະບັບທີ່ຕ້ອງການ.

ມັນພຽງແຕ່ຈະເພີ່ມວ່າ:

• ປະໂຫຍດຂອງມັນເອງ (werf) ຖືກນໍາໃຊ້ສໍາລັບການປະກອບ;
• ຂະບວນການ CI/CD ແມ່ນສ້າງຂຶ້ນບົນພື້ນຖານຂອງ GitLab CI;
• ແລະທັງຫມົດນີ້, ແນ່ນອນ, ແລ່ນຢູ່ໃນ Kubernetes.

ວຽກງານ

ຕອນນີ້ໃຫ້ເຮົາສ້າງໜ້າວຽກທີ່ຄຳນຶງເຖິງສະເພາະທັງໝົດທີ່ອະທິບາຍໄວ້:

1. ຫຼັງຈາກການປ່ຽນແປງສະບັບ werf ໃນຊ່ອງທາງການປັບປຸງໃດໆ ເອກະສານຢູ່ໃນເວັບໄຊຄວນໄດ້ຮັບການປັບປຸງອັດຕະໂນມັດ.
2. ສໍາລັບການພັດທະນາທ່ານຈໍາເປັນຕ້ອງສາມາດບາງຄັ້ງ ເບິ່ງສະບັບຕົວຢ່າງຂອງເວັບໄຊທ໌.

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

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

ມັນສະແດງໃຫ້ເຫັນວ່າ ການປະກອບແມ່ນຂຶ້ນກັບການປ່ຽນແປງຂໍ້ມູນພາຍນອກ.

Реализация

ການເລືອກວິທີການ

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

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

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

werf vs git clone ແລະປອມ

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

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

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

ພວກເຮົາຂຽນ werf.yaml

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

werf ອະນຸຍາດໃຫ້ທ່ານນໍາໃຊ້ ໄປແບບ ໃນ​ໄຟລ​໌​ການ​ຕັ້ງ​ຄ່າ​ຂອງ​ທ່ານ (werf.yaml), ແລະນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ ສ້າງ config ສຸດບິນ ອີງຕາມຂໍ້ມູນພາຍນອກ (ສິ່ງທີ່ທ່ານຕ້ອງການ!). ຂໍ້ມູນພາຍນອກໃນກໍລະນີຂອງພວກເຮົາແມ່ນຂໍ້ມູນກ່ຽວກັບສະບັບແລະການປ່ອຍ, ບົນພື້ນຖານທີ່ພວກເຮົາເກັບກໍາຈໍານວນທີ່ຕ້ອງການຂອງປອມແລະຜົນທີ່ພວກເຮົາໄດ້ຮັບສອງຮູບພາບ: werf-doc и werf-dev ເພື່ອດໍາເນີນການໃນວົງຈອນທີ່ແຕກຕ່າງກັນ.

ຂໍ້ມູນພາຍນອກແມ່ນຜ່ານຕົວແປສະພາບແວດລ້ອມ. ນີ້ແມ່ນອົງປະກອບຂອງພວກເຂົາ:

• RELEASES — ເສັ້ນ​ທີ່​ມີ​ບັນ​ຊີ​ລາຍ​ການ​ຂອງ​ການ​ປ່ອຍ​ແລະ​ສະ​ບັບ​ປະ​ຈຸ​ບັນ​ທີ່​ສອດ​ຄ້ອງ​ກັນ​ຂອງ werf​, ໃນ​ຮູບ​ແບບ​ຂອງ​ບັນ​ຊີ​ລາຍ​ການ​ທີ່​ແຍກ​ຫ່າງ​ໄກ​ສອກ​ຫຼີກ​ຂອງ​ຄ່າ​ໃນ​ຮູບ​ແບບ <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. ຕົວຢ່າງ: 1.0%v1.0.4-beta.20
• CHANNELS — ເສັ້ນ​ທີ່​ມີ​ບັນ​ຊີ​ລາຍ​ການ​ຂອງ​ຊ່ອງ​ແລະ​ສະ​ບັບ​ປະ​ຈຸ​ບັນ​ທີ່​ສອດ​ຄ້ອງ​ກັນ​ຂອງ werf​, ໃນ​ຮູບ​ແບບ​ຂອງ​ບັນ​ຊີ​ລາຍ​ການ​ການ​ແຍກ​ຊ່ອງ​ຂອງ​ຄຸນ​ຄ່າ​ໃນ​ຮູບ​ແບບ <КАНАЛ>%<НОМЕР_ВЕРСИИ>. ຕົວຢ່າງ: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• ROOT_VERSION — ສະບັບ werf ຈະຖືກສະແດງໂດຍຄ່າເລີ່ມຕົ້ນຢູ່ໃນເວັບໄຊທ໌ (ມັນບໍ່ຈໍາເປັນສະເຫມີທີ່ຈະສະແດງເອກະສານໂດຍຈໍານວນການປ່ອຍສູງສຸດ). ຕົວຢ່າງ: v1.0.4-beta.20
• REVIEW_SHA — hash ຂອງ​ການ​ທົບ​ທວນ​ຄືນ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ທີ່​ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ສ້າງ​ສະ​ບັບ​ສໍາ​ລັບ​ການ loop ການ​ທົດ​ສອບ​.

ຕົວແປເຫຼົ່ານີ້ຈະຖືກຕື່ມໃສ່ໃນທໍ່ GitLab CI, ແລະວິທີການທີ່ແນ່ນອນແມ່ນຂຽນຂ້າງລຸ່ມນີ້.

ກ່ອນອື່ນ ໝົດ, ເພື່ອຄວາມສະດວກ, ພວກເຮົາ ກຳ ນົດໃນ werf.yaml ໄປ​ທີ່​ຕົວ​ແປ​ແມ່​ແບບ​, ການ​ມອບ​ຫມາຍ​ໃຫ້​ເຂົາ​ເຈົ້າ​ຄ່າ​ຈາກ​ຕົວ​ແປ​ສະ​ພາບ​ແວດ​ລ້ອມ​:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

ຄໍາອະທິບາຍຂອງປອມສໍາລັບການລວບລວມສະບັບ static ຂອງເວັບໄຊທ໌ໂດຍທົ່ວໄປແມ່ນຄືກັນສໍາລັບທຸກກໍລະນີທີ່ພວກເຮົາຕ້ອງການ (ລວມທັງການສ້າງສະບັບຮາກ, ເຊັ່ນດຽວກັນກັບສະບັບສໍາລັບວົງຈອນ dev). ດັ່ງນັ້ນ, ພວກເຮົາຈະຍ້າຍມັນເຂົ້າໄປໃນບລັອກແຍກຕ່າງຫາກໂດຍໃຊ້ຟັງຊັນ define - ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ຕໍ່​ມາ​ນໍາ​ໃຊ້​ include. ພວກເຮົາຈະຜ່ານການໂຕ້ຖຽງຕໍ່ໄປນີ້ໄປຫາແມ່ແບບ:

• Version — ສະ​ບັບ​ຜະ​ລິດ (ຊື່​ໂຄດ​ຄໍາ​ສັ່ງ​)​;
• Channel — ຊື່​ຂອງ​ຊ່ອງ​ທາງ​ການ​ປັບ​ປຸງ​ສໍາ​ລັບ​ການ​ຜະ​ລິດ​ປອມ​;
• Commit — ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ hash​, ຖ້າ​ຫາກ​ວ່າ​ປອມ​ໄດ້​ຖືກ​ສ້າງ​ຂຶ້ນ​ສໍາ​ລັບ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ການ​ທົບ​ທວນ​ຄືນ​;
• ສະພາບການ.

ລາຍລະອຽດແມ່ແບບ Artifact

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

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

ເມື່ອອະທິບາຍສິ່ງປະດິດ, ຄຸນສົມບັດ werf ຕໍ່ໄປນີ້ແມ່ນໃຊ້: ການຕິດຕັ້ງ. ການ​ຕິດ​ຕັ້ງ​ຊີ້​ບອກ​ລະ​ບົບ​ການ​ບໍ​ລິ​ການ​ build_dir ຊ່ວຍໃຫ້ທ່ານສາມາດບັນທຶກ Jekyll cache ລະຫວ່າງການແລ່ນທໍ່, ເຊິ່ງ ເລັ່ງການປະກອບຄືນໃໝ່ຢ່າງໃຫຍ່ຫຼວງ.

ທ່ານອາດຈະໄດ້ສັງເກດເຫັນການນໍາໃຊ້ໄຟລ໌ດັ່ງກ່າວ releases.yml ເປັນໄຟລ໌ YAML ທີ່ມີຂໍ້ມູນການປ່ອຍທີ່ຮ້ອງຂໍຈາກ githubcom (ຂອງປອມທີ່ໄດ້ຮັບໃນເວລາປະຕິບັດທໍ່). ມັນເປັນສິ່ງຈໍາເປັນໃນເວລາທີ່ລວບລວມເວັບໄຊທ໌, ແຕ່ໃນແງ່ຂອງບົດຄວາມມັນຫນ້າສົນໃຈກັບພວກເຮົາເພາະວ່າມັນຂຶ້ນກັບລັດຂອງມັນ. reassembly ຂອງພຽງແຕ່ຫນຶ່ງ artifact — ປອມ​ຂອງ​ສະ​ບັບ​ຮາກ​ຂອງ​ເວັບ​ໄຊ​ໄດ້ (ມັນ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ຢູ່​ໃນ​ປອມ​ອື່ນໆ​)​.

ນີ້ແມ່ນປະຕິບັດໂດຍໃຊ້ຄໍາຖະແຫຼງການທີ່ມີເງື່ອນໄຂ if ໄປແບບແລະແບບ {{ $Root.Files.Get "releases.yml" | sha256sum }} ໃນຂັ້ນຕອນຂອງການ ໄລຍະ. ມັນເຮັດວຽກດັ່ງຕໍ່ໄປນີ້: ເມື່ອສ້າງສິ່ງປະດິດສໍາລັບສະບັບຮາກ (ຕົວແປ .Channel ເທົ່າ​ທຽມ​ກັນ​ກັບ root) ໄຟລ໌ hash releases.yml ມີ​ຜົນ​ກະ​ທົບ​ລາຍ​ເຊັນ​ຂອງ​ຂັ້ນ​ຕອນ​ຂອງ​ການ​ທັງ​ຫມົດ​, ເນື່ອງ​ຈາກ​ວ່າ​ມັນ​ເປັນ​ສ່ວນ​ຫນຶ່ງ​ຂອງ​ຊື່​ຂອງ​ວຽກ​ງານ Ansible (ພາ​ກໍາ​ນົດ​ການ​ name). ດັ່ງນັ້ນ, ເມື່ອມີການປ່ຽນແປງ ເນື້ອໃນ ໄຟລ releases.yml ສິ່ງປະດິດທີ່ສອດຄ້ອງກັນຈະຖືກປະກອບຄືນໃໝ່.

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

ເພື່ອໃຊ້ແມ່ແບບຂອງ artifact ເພື່ອສ້າງລາຍລະອຽດຂອງ artifact ຂອງຊ່ອງແລະການປ່ອຍສະບັບທີ່ຖືກໂອນ, ພວກເຮົາຈັດລຽງ loop ໃນຕົວແປ. .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

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

ເຊັ່ນດຽວກັນ, ແຕ່ບໍ່ມີ loop, ພວກເຮົາໂທຫາແມ່ແບບຂອງປອມສໍາລັບ "ກໍລະນີພິເສດ": ສໍາລັບສະບັບຮາກ, ເຊັ່ນດຽວກັນກັບສະບັບຈາກການທົບທວນຄືນຄໍາຫມັ້ນສັນຍາ:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ artifact ສໍາ​ລັບ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ການ​ທົບ​ທວນ​ຄືນ​ຈະ​ໄດ້​ຮັບ​ການ​ສ້າງ​ພຽງ​ແຕ່​ຖ້າ​ຫາກ​ວ່າ​ຕົວ​ປ່ຽນ​ໄດ້​ຖືກ​ຕັ້ງ​ໄວ້​ .WerfReviewCommit.

ວັດຖຸບູຮານແມ່ນກຽມພ້ອມ - ມັນເປັນເວລາທີ່ຈະເລີ່ມຕົ້ນການນໍາເຂົ້າ!

ຮູບພາບສຸດທ້າຍ, ຖືກອອກແບບມາເພື່ອແລ່ນໃນ Kubernetes, ແມ່ນ NGINX ປົກກະຕິທີ່ມີການເພີ່ມໄຟລ໌ການຕັ້ງຄ່າເຊີບເວີ. nginx.conf ແລະ static ຈາກ artifacts. ນອກເຫນືອໄປຈາກສິ່ງປອມຂອງສະບັບຮາກຂອງເວັບໄຊທ໌, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດເລື້ມຄືນ loop ໃນຕົວແປ .WerfVersions ເພື່ອນໍາເຂົ້າສິ່ງປະດິດຂອງຊ່ອງແລະສະບັບອອກ + ປະຕິບັດຕາມກົດລະບຽບການຕັ້ງຊື່ຂອງປອມທີ່ພວກເຮົາໄດ້ຮັບຮອງເອົາກ່ອນຫນ້ານີ້. ເນື່ອງຈາກວັດຖຸບູຮານແຕ່ລະອັນເກັບຮັກສາສະບັບຂອງເວັບໄຊເປັນສອງພາສາ, ພວກເຮົານໍາເຂົ້າໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນສະຖານທີ່ສະຫນອງໃຫ້ໂດຍການຕັ້ງຄ່າ.

ລາຍລະອຽດຂອງຮູບພາບສຸດທ້າຍ werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

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

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

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

ການຊຸມນຸມແມ່ນກຽມພ້ອມ! ໃຫ້ກ້າວໄປສູ່ CI/CD ແລະ nuances ທີ່ສໍາຄັນ.

ທໍ່ໃນ GitLab CI ແລະລັກສະນະຂອງການກໍ່ສ້າງແບບເຄື່ອນໄຫວ

ເມື່ອດໍາເນີນການກໍ່ສ້າງພວກເຮົາຈໍາເປັນຕ້ອງກໍານົດຕົວແປສະພາບແວດລ້ອມທີ່ໃຊ້ໃນ werf.yaml. ອັນນີ້ບໍ່ນຳໃຊ້ກັບຕົວແປ REVIEW_SHA, ເຊິ່ງພວກເຮົາຈະຕັ້ງເມື່ອໂທຫາທໍ່ຈາກ hook GitHub.

ພວກເຮົາຈະສ້າງຂໍ້ມູນພາຍນອກທີ່ຈໍາເປັນໃນ script Bash generate_artifacts, ເຊິ່ງຈະສ້າງສອງສິ່ງປອມຂອງທໍ່ GitLab:

• file releases.yml ດ້ວຍ​ຂໍ້​ມູນ​ການ​ປ່ອຍ​ອອກ​ມາ​,
• file common_envs.sh, ມີຕົວແປສະພາບແວດລ້ອມທີ່ຈະສົ່ງອອກ.

ເນື້ອໃນໄຟລ໌ generate_artifacts ເຈົ້າຈະພົບເຫັນຢູ່ໃນຂອງພວກເຮົາ repositories ມີຕົວຢ່າງ. ການຮັບຂໍ້ມູນຕົວມັນເອງບໍ່ແມ່ນຫົວຂໍ້ຂອງບົດຄວາມ, ແຕ່ໄຟລ໌ common_envs.sh ເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາ, ເພາະວ່າ ການເຮັດວຽກຂອງ werf ແມ່ນຂຶ້ນກັບມັນ. ຕົວຢ່າງຂອງເນື້ອຫາຂອງມັນ:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

ທ່ານສາມາດນໍາໃຊ້ຜົນໄດ້ຮັບຂອງສະຄິບດັ່ງກ່າວ, ສໍາລັບຕົວຢ່າງ, ການນໍາໃຊ້ຟັງຊັນ Bash source.

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

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

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

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

ເນື້ອໃນຂອງເວທີ ສ້າງກ່ອນ ໄຟລ .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

ໂດຍໄດ້ເກັບກໍາຂໍ້ມູນພາຍນອກຢູ່ໃນສິ່ງປອມ, ທ່ານສາມາດສ້າງແລະນໍາໄປໃຊ້ໂດຍໃຊ້ຂັ້ນຕອນທໍ່ GitLab CI ມາດຕະຖານ: ກໍ່ສ້າງແລະນໍາໃຊ້. ພວກເຮົາເປີດຕົວທໍ່ນັ້ນເອງໂດຍໃຊ້ hooks ຈາກ werf GitHub repository (i.e., ເມື່ອມີການປ່ຽນແປງໃນ GitHub repository). ຂໍ້ມູນສໍາລັບພວກມັນສາມາດພົບໄດ້ໃນຄຸນສົມບັດໂຄງການ GitLab ໃນພາກ ການຕັ້ງຄ່າ CI/CD -> ທໍ່ສົ່ງ, ແລະຫຼັງຈາກນັ້ນສ້າງ Webhook ທີ່ສອດຄ້ອງກັນໃນ GitHub (ການຕັ້ງຄ່າ -> Webhooks).

ຂັ້ນ​ຕອນ​ຂອງ​ການ​ກໍ່​ສ້າງ​ຈະ​ເປັນ​ດັ່ງ​ນີ້​:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

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

ໃນຂັ້ນຕອນການໃຊ້ງານ, ພວກເຮົາຈະອະທິບາຍສອງໜ້າວຽກ - ແຍກຕ່າງຫາກເພື່ອນຳໃຊ້ເຂົ້າໃນການຜະລິດ ແລະ ວົງຈອນ dev, ໂດຍໃຊ້ແມ່ແບບ YAML:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

ວຽກງານທີ່ຈໍາເປັນແຕກຕ່າງກັນພຽງແຕ່ຊີ້ໃຫ້ເຫັນເຖິງສະພາບການຂອງກຸ່ມທີ່ werf ຄວນປະຕິບັດການຈັດຕັ້ງປະຕິບັດ (WERF_KUBE_CONTEXT), ແລະກໍານົດຕົວແປສະພາບແວດລ້ອມ loop (environment.name и environment.url), ເຊິ່ງຫຼັງຈາກນັ້ນຖືກນໍາໃຊ້ໃນ Helm chart templates. ພວກເຮົາຈະບໍ່ໃຫ້ເນື້ອໃນຂອງແມ່ແບບ, ເນື່ອງຈາກວ່າ ... ບໍ່ມີຫຍັງທີ່ຫນ້າສົນໃຈຢູ່ທີ່ນັ້ນສໍາລັບຫົວຂໍ້ໃນຄໍາຖາມ, ແຕ່ວ່າທ່ານສາມາດຊອກຫາພວກມັນໄດ້ repositories ສໍາລັບບົດຄວາມ.

ການສໍາພັດສຸດທ້າຍ

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

ເພື່ອປະຕິບັດທ່ານຈະຕ້ອງການ:

• ເພີ່ມຂັ້ນຕອນການເຮັດຄວາມສະອາດໃສ່ .gitlab-ci.yml;
• ເພີ່ມການປະຕິບັດແຕ່ລະໄລຍະຂອງວຽກງານທໍາຄວາມສະອາດ;
• ຕັ້ງຄ່າຕົວແປສະພາບແວດລ້ອມດ້ວຍໂທເຄັນການເຂົ້າເຖິງການຂຽນ.

ເພີ່ມຂັ້ນຕອນການທໍາຄວາມສະອາດໃຫ້ .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

ພວກເຮົາໄດ້ເຫັນເກືອບທັງຫມົດນີ້ສູງກວ່າເລັກນ້ອຍ - ພຽງແຕ່ເພື່ອເຮັດຄວາມສະອາດມັນທ່ານຈໍາເປັນຕ້ອງເຂົ້າສູ່ລະບົບ Docker Registry ທໍາອິດດ້ວຍ token ທີ່ມີສິດທິໃນການລຶບຮູບພາບໃນ Docker Registry (ເຄື່ອງເຮັດຫນ້າທີ່ GitLab CI ອັດຕະໂນມັດອອກບໍ່ໄດ້. ມີ​ສິດ​ດັ່ງ​ກ່າວ). token ຕ້ອງຖືກສ້າງຂຶ້ນໃນ GitLab ລ່ວງຫນ້າແລະຄ່າຂອງມັນຕ້ອງຖືກລະບຸໄວ້ໃນຕົວແປສະພາບແວດລ້ອມ WERF_IMAGES_CLEANUP_PASSWORD ໂຄງການ (ການຕັ້ງຄ່າ CI/CD -> ຕົວແປ).

ການເພີ່ມວຽກງານທໍາຄວາມສະອາດກັບຕາຕະລາງທີ່ກໍານົດໄວ້ແມ່ນສໍາເລັດໃນ CI/CD ->
ຕາຕະລາງ.

ນັ້ນແມ່ນມັນ: ໂຄງການໃນ Docker Registry ຈະບໍ່ເຕີບໂຕຢ່າງຕໍ່ເນື່ອງຈາກຮູບພາບທີ່ບໍ່ໄດ້ໃຊ້.

ໃນຕອນທ້າຍຂອງພາກປະຕິບັດ, ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າບັນຊີລາຍຊື່ເຕັມທີ່ຈາກບົດຄວາມແມ່ນມີຢູ່ໃນ Git:

• .gitlab-ci.yml;
• werf.yaml.

ຜົນ

1. ພວກ​ເຮົາ​ໄດ້​ຮັບ​ໂຄງ​ສ້າງ​ການ​ປະ​ກອບ​ຢ່າງ​ມີ​ເຫດ​ຜົນ​: ຫນຶ່ງ​ຂອງ​ປອມ​ຕໍ່​ສະ​ບັບ​.
2. ສະພາແຫ່ງແມ່ນທົ່ວໄປແລະບໍ່ຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງຄູ່ມືໃນເວລາທີ່ສະບັບໃຫມ່ຂອງ werf ໄດ້ຖືກປ່ອຍອອກມາ: ເອກະສານຢູ່ໃນເວັບໄຊທ໌ໄດ້ຖືກປັບປຸງໂດຍອັດຕະໂນມັດ.
3. ສອງຮູບໄດ້ຖືກປະກອບສໍາລັບ contours ທີ່ແຕກຕ່າງກັນ.
4. ມັນເຮັດວຽກຢ່າງໄວວາ, ເພາະວ່າ Caching ແມ່ນໃຊ້ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ - ເມື່ອສະບັບໃຫມ່ຂອງ werf ຖືກປ່ອຍອອກມາຫຼື hook GitHub ໄດ້ຖືກເອີ້ນສໍາລັບຄໍາຫມັ້ນສັນຍາການທົບທວນຄືນ, ພຽງແຕ່ສິ່ງປະດິດທີ່ສອດຄ້ອງກັນກັບສະບັບທີ່ມີການປ່ຽນແປງແມ່ນສ້າງຂຶ້ນໃຫມ່.
5. ບໍ່ຈໍາເປັນຕ້ອງຄິດກ່ຽວກັບການລຶບຮູບພາບທີ່ບໍ່ໄດ້ໃຊ້: ການເຮັດຄວາມສະອາດຕາມນະໂຍບາຍ werf ຈະເຮັດໃຫ້ Docker Registry ຢູ່ໃນລໍາດັບ.

ການຄົ້ນພົບ

• ການນໍາໃຊ້ werf ຊ່ວຍໃຫ້ການປະກອບເຮັດວຽກໄດ້ໄວເນື່ອງຈາກການເກັບຂໍ້ມູນຂອງທັງການປະກອບຕົວມັນເອງແລະ caching ເມື່ອເຮັດວຽກກັບບ່ອນເກັບຂໍ້ມູນພາຍນອກ.
• ການເຮັດວຽກກັບບ່ອນເກັບມ້ຽນ Git ພາຍນອກຈະລົບລ້າງຄວາມຕ້ອງການທີ່ຈະໂຄນບ່ອນເກັບມ້ຽນທັງຫມົດໃນແຕ່ລະຄັ້ງຫຼືປັບປຸງລໍ້ດ້ວຍເຫດຜົນການເພີ່ມປະສິດທິພາບທີ່ຫຍຸ້ງຍາກ. werf ໃຊ້ cache ແລະເຮັດ cloning ພຽງແຕ່ຄັ້ງດຽວ, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ fetch ແລະພຽງແຕ່ໃນເວລາທີ່ຈໍາເປັນ.
• ຄວາມສາມາດໃນການໃຊ້ແມ່ແບບ Go ໃນໄຟລ໌ການຕັ້ງຄ່າການກໍ່ສ້າງ werf.yaml ອະນຸຍາດໃຫ້ທ່ານອະທິບາຍການປະກອບທີ່ຜົນໄດ້ຮັບແມ່ນຂຶ້ນກັບຂໍ້ມູນພາຍນອກ.
• ການນໍາໃຊ້ mount ໃນ werf ຢ່າງຫຼວງຫຼາຍເລັ່ງການລວບລວມຂອງປອມ - ເນື່ອງຈາກ cache, ເຊິ່ງແມ່ນທົ່ວໄປກັບທໍ່ທັງຫມົດ.
• werf ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການຕັ້ງຄ່າການເຮັດຄວາມສະອາດ, ເຊິ່ງເປັນສິ່ງສໍາຄັນໂດຍສະເພາະໃນເວລາທີ່ການກໍ່ສ້າງແບບເຄື່ອນໄຫວ.

PS

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

• «ແລ່ນຄຳສັ່ງໃນຂະນະທີ່ສົ່ງແອັບພລິເຄຊັນໃໝ່ໃຫ້ກັບ Kubernetes"
• «ການກໍ່ສ້າງແລະນໍາໃຊ້ບໍລິການຈຸລະພາກທີ່ຄ້າຍຄືກັນກັບ werf ແລະ GitLab CI"
• «ການນໍາໃຊ້ werf ເພື່ອເຜີຍແຜ່ຕາຕະລາງ Helm ທີ່ສັບສົນ"
• «ການແນະນໍາ werf 1.0 ຄົງທີ່: GitOps ມີຫຍັງແດ່ກ່ຽວກັບມັນ, ສະຖານະພາບແລະແຜນການ".

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