ໃນປັດຈຸບັນທ່ານສາມາດສ້າງຮູບພາບ Docker ໃນ werf ໂດຍໃຊ້ Dockerfile ປົກກະຕິ

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

ພວກເຮົາຈະສົນທະນາກ່ຽວກັບ werf - ຜົນ​ປະ​ໂຫຍດ GitOps ທີ່​ປະ​ສົມ​ປະ​ສານ​ກັບ​ລະ​ບົບ CI / CD ໃດ​ຫນຶ່ງ​ແລະ​ສະ​ຫນອງ​ການ​ຄຸ້ມ​ຄອງ​ຂອງ​ວົງ​ຈອນ​ທັງ​ຫມົດ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​, ອະ​ນຸ​ຍາດ​ໃຫ້​:

• ເກັບ​ກໍາ​ແລະ​ເຜີຍ​ແຜ່​ຮູບ​ພາບ​,
• ນຳໃຊ້ແອັບພລິເຄຊັນໃນ Kubernetes,
• ລຶບຮູບພາບທີ່ບໍ່ໄດ້ໃຊ້ໂດຍໃຊ້ນະໂຍບາຍພິເສດ.

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

ຄວາມ​ເປັນ​ມາ​: ຕົວ​ເກັບ​ກໍາ​ຮູບ​ພາບ​ຂອງ​ທ່ານ​ເອງ​

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

ໃນຂະນະທີ່ສ້າງເຄື່ອງມືສໍາລັບການກໍ່ສ້າງຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນຮູບພາບ Docker, ພວກເຮົາຮູ້ຢ່າງໄວວາວ່າ Dockerfile ບໍ່ເຫມາະສົມສໍາລັບພວກເຮົາສໍາລັບບາງວຽກງານສະເພາະ:

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

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

ໂດຍທົ່ວໄປ, ໂດຍບໍ່ມີການຄິດສອງເທື່ອ, ພວກເຮົາປະກອບອາວຸດຕົວເອງດ້ວຍພາສາການຂຽນໂປຼແກຼມທີ່ພວກເຮົາໃຊ້ (ເບິ່ງຂ້າງລຸ່ມນີ້) ແລະຕີເສັ້ນທາງທີ່ຈະປະຕິບັດ DSL ຂອງຕົນເອງ! ອີງຕາມຈຸດປະສົງ, ມັນມີຈຸດປະສົງເພື່ອອະທິບາຍຂະບວນການປະກອບໃນຂັ້ນຕອນຕ່າງໆແລະກໍານົດຄວາມເພິ່ງພາອາໄສຂອງຂັ້ນຕອນເຫຼົ່ານີ້ຢູ່ໃນໄຟລ໌. ແລະປະກອບມັນ ຜູ້ເກັບຂອງຕົນເອງ, ເຊິ່ງໄດ້ຫັນ DSL ເຂົ້າໄປໃນເປົ້າຫມາຍສຸດທ້າຍ - ຮູບພາບປະກອບ. ໃນຕອນທໍາອິດ DSL ແມ່ນຢູ່ໃນ Ruby, ແຕ່ເປັນ ການ​ຫັນ​ປ່ຽນ​ໄປ Golang​ — ການຕັ້ງຄ່າຕົວເກັບກຳຂອງພວກເຮົາເລີ່ມຖືກອະທິບາຍໄວ້ໃນໄຟລ໌ YAML.

ການຕັ້ງຄ່າເກົ່າສໍາລັບ dapp ໃນ Ruby

ການຕັ້ງຄ່າປະຈຸບັນສໍາລັບ werf ໃນ YAML

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

NB: ໃນປັດຈຸບັນ, ຕົວເກັບລວບລວມຂອງພວກເຮົາ, ເຊິ່ງເຮັດວຽກກັບ config ຂອງຕົນເອງ (ໃນ YAML) ແລະເອີ້ນວ່າ Stapel collector, ໄດ້ພັດທະນາແລ້ວເປັນເຄື່ອງມືທີ່ມີປະສິດທິພາບພໍສົມຄວນ. ລາຍລະອຽດຂອງມັນສົມຄວນໄດ້ຮັບບົດຄວາມແຍກຕ່າງຫາກ, ແລະລາຍລະອຽດພື້ນຖານສາມາດພົບໄດ້ໃນ ເອກະສານ.

ຄວາມຮັບຮູ້ຂອງບັນຫາ

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

ແທນທີ່ຈະຕອບຄໍາຖາມນີ້, ພວກເຮົາສະເຫນີການແກ້ໄຂ. ຈະເປັນແນວໃດຖ້າທ່ານມີ Dockerfile (ຫຼືຊຸດຂອງ Dockerfiles) ແລະຕ້ອງການໃຊ້ werf?

NB: ໂດຍວິທີທາງການ, ເປັນຫຍັງເຈົ້າຈຶ່ງຢາກໃຊ້ werf? ລັກສະນະຕົ້ນຕໍແມ່ນມາຈາກດັ່ງຕໍ່ໄປນີ້:

• ວົງຈອນການຄຸ້ມຄອງຄໍາຮ້ອງສະຫມັກຢ່າງເຕັມທີ່ລວມທັງການທໍາຄວາມສະອາດຮູບພາບ;
• ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ຄຸ້ມ​ຄອງ​ການ​ປະ​ກອບ​ຂອງ​ຮູບ​ພາບ​ຈໍາ​ນວນ​ຫນຶ່ງ​ໃນ​ເວ​ລາ​ດຽວ​ຈາກ config ດຽວ​;
• ປັບປຸງຂະບວນການນຳໃຊ້ສຳລັບຕາຕະລາງທີ່ເຂົ້າກັນໄດ້ກັບ Helm.

ບັນຊີລາຍຊື່ຄົບຖ້ວນຂອງພວກມັນສາມາດພົບໄດ້ທີ່ ຫນ້າໂຄງການ.

ດັ່ງນັ້ນ, ຖ້າກ່ອນຫນ້ານີ້ພວກເຮົາຈະສະເຫນີໃຫ້ຂຽນ Dockerfile ໃນການຕັ້ງຄ່າຂອງພວກເຮົາ, ຕອນນີ້ພວກເຮົາຈະເວົ້າຢ່າງມີຄວາມສຸກ: "ໃຫ້ werf ສ້າງ Dockerfiles ຂອງທ່ານ!"

ວິທີໃຊ້?

ການປະຕິບັດຢ່າງເຕັມທີ່ຂອງຄຸນນະສົມບັດນີ້ປາກົດຢູ່ໃນການປ່ອຍ werf v1.0.3-beta.1. ຫຼັກການທົ່ວໄປແມ່ນງ່າຍດາຍ: ຜູ້ໃຊ້ກໍານົດເສັ້ນທາງໄປຫາ Dockerfile ທີ່ມີຢູ່ແລ້ວໃນ werf config, ແລະຫຼັງຈາກນັ້ນດໍາເນີນການຄໍາສັ່ງ. werf build... ແລະນັ້ນແມ່ນ - werf ຈະລວບລວມຮູບພາບ. ໃຫ້ເບິ່ງຕົວຢ່າງທີ່ບໍ່ມີຕົວຕົນ.

ຂໍໃຫ້ປະກາດອັນຕໍ່ໄປ Dockerfile ໃນ​ຮາກ​ໂຄງ​ການ​:

FROM ubuntu:18.04
RUN echo Building ...

ແລະພວກເຮົາຈະປະກາດ werf.yamlເຊິ່ງໃຊ້ອັນນີ້ Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ທັງໝົດ! ຊ້າຍ ແລ່ນ werf build:

ນອກຈາກນັ້ນ, ທ່ານສາມາດປະກາດດັ່ງຕໍ່ໄປນີ້ werf.yaml ເພື່ອສ້າງຫຼາຍຮູບຈາກ Dockerfiles ທີ່ແຕກຕ່າງກັນໃນເວລາດຽວກັນ:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

ສຸດທ້າຍ, ມັນຍັງສະຫນັບສະຫນູນການຖ່າຍທອດຕົວກໍານົດການກໍ່ສ້າງເພີ່ມເຕີມ, ເຊັ່ນ: --build-arg и --add-host - ຜ່ານ config werf. ຄໍາອະທິບາຍຄົບຖ້ວນສົມບູນຂອງການຕັ້ງຄ່າຮູບພາບ Dockerfile ແມ່ນມີຢູ່ ໜ້າເອກະສານ.

ມັນບໍ່ໄດ້ແນວໃດເຮັດວຽກ?

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

1. ແຕ່ລະຮູບພາບທີ່ສ້າງຂຶ້ນຈາກ Dockerfile ປະກອບດ້ວຍຂັ້ນຕອນຫນຶ່ງທີ່ເອີ້ນວ່າ dockerfile (ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບສິ່ງທີ່ຂັ້ນຕອນຢູ່ໃນ werf ທີ່ນີ້).
2. ສໍາລັບເວທີ dockerfile werf ຄິດໄລ່ລາຍເຊັນທີ່ຂຶ້ນກັບເນື້ອໃນຂອງການຕັ້ງຄ່າ Dockerfile. ເມື່ອການຕັ້ງຄ່າ Dockerfile ປ່ຽນແປງ, ລາຍເຊັນຂອງຂັ້ນຕອນຈະປ່ຽນແປງ dockerfile ແລະ werf ເລີ່ມການສ້າງຂັ້ນຕອນນີ້ຄືນໃໝ່ດ້ວຍການຕັ້ງຄ່າ Dockerfile ໃໝ່. ຖ້າລາຍເຊັນບໍ່ປ່ຽນແປງ, ຫຼັງຈາກນັ້ນ werf ເອົາຮູບພາບຈາກ cache (ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການໃຊ້ລາຍເຊັນໃນ werf ໄດ້ຖືກອະທິບາຍໄວ້ໃນ ບົດລາຍງານນີ້).
3. ຕໍ່ໄປ, ຮູບພາບທີ່ເກັບກໍາສາມາດຖືກເຜີຍແຜ່ດ້ວຍຄໍາສັ່ງ werf publish (ຫຼື werf build-and-publish) ແລະໃຊ້ມັນເພື່ອນຳໃຊ້ກັບ Kubernetes. ຮູບພາບທີ່ເຜີຍແຜ່ໃນ Docker Registry ຈະຖືກອະນາໄມໂດຍໃຊ້ເຄື່ອງມືທໍາຄວາມສະອາດ werf ມາດຕະຖານ, i.e. ຮູບພາບເກົ່າ (ເກົ່າກວ່າ N ມື້), ຮູບພາບທີ່ກ່ຽວຂ້ອງກັບສາຂາ Git ທີ່ບໍ່ມີຢູ່, ແລະນະໂຍບາຍອື່ນໆຈະຖືກເຮັດຄວາມສະອາດໂດຍອັດຕະໂນມັດ.

ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບຈຸດທີ່ອະທິບາຍຢູ່ທີ່ນີ້ສາມາດພົບໄດ້ໃນເອກະສານ:

• ຂະບວນການເຜີຍແຜ່;
• ການເຊື່ອມໂຍງກັບຂະບວນການນຳໃຊ້ Kubernetes;
• ຂະບວນການທໍາຄວາມສະອາດ.

ຫມາຍເຫດແລະຂໍ້ຄວນລະວັງ

1. URL ພາຍນອກບໍ່ຮອງຮັບໃນ ADD

ໃນປັດຈຸບັນມັນບໍ່ໄດ້ຖືກສະຫນັບສະຫນູນທີ່ຈະໃຊ້ URL ພາຍນອກໃນຄໍາສັ່ງ ADD. Werf ຈະບໍ່ລິເລີ່ມການກໍ່ສ້າງຄືນໃຫມ່ເມື່ອຊັບພະຍາກອນທີ່ URL ທີ່ກໍານົດປ່ຽນແປງ. ພວກເຮົາວາງແຜນທີ່ຈະເພີ່ມຄຸນສົມບັດນີ້ໃນໄວໆນີ້.

2. ທ່ານບໍ່ສາມາດເພີ່ມ .git ໃສ່ຮູບພາບໄດ້

ໂດຍທົ່ວໄປແລ້ວ, ການເພີ່ມໄດເລກະທໍລີ .git ໃນຮູບພາບ - ການປະຕິບັດທີ່ບໍ່ດີທີ່ໂຫດຮ້າຍແລະນີ້ແມ່ນເຫດຜົນ:

1. ຖ້າຫາກວ່າ .git ຍັງຄົງຢູ່ໃນຮູບສຸດທ້າຍ, ນີ້ລະເມີດຫຼັກການ 12 ປັດໄຈ app: ເນື່ອງຈາກຮູບພາບສຸດທ້າຍຕ້ອງເຊື່ອມໂຍງກັບຄໍາຫມັ້ນສັນຍາດຽວ, ມັນບໍ່ຄວນເຮັດ git checkout ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ໂດຍ​ຕົນ​ເອງ​.
2. .git ເພີ່ມຂະຫນາດຂອງຮູບພາບ (ບ່ອນເກັບມ້ຽນສາມາດມີຂະຫນາດໃຫຍ່ຍ້ອນຄວາມຈິງທີ່ວ່າໄຟລ໌ຂະຫນາດໃຫຍ່ໄດ້ຖືກເພີ່ມໃສ່ມັນແລະຫຼັງຈາກນັ້ນຖືກລຶບ). ຂະຫນາດຂອງຕົ້ນໄມ້ການເຮັດວຽກທີ່ກ່ຽວຂ້ອງກັບຄໍາຫມັ້ນສັນຍາສະເພາະໃດຫນຶ່ງຈະບໍ່ຂຶ້ນກັບປະຫວັດຂອງການດໍາເນີນງານໃນ Git. ໃນກໍລະນີນີ້, ການເພີ່ມເຕີມແລະການໂຍກຍ້າຍຕໍ່ມາ .git ຈາກຮູບພາບສຸດທ້າຍຈະບໍ່ເຮັດວຽກ: ຮູບພາບຍັງຈະໄດ້ຮັບຊັ້ນພິເສດ - ນີ້ແມ່ນວິທີການເຮັດວຽກຂອງ Docker.
3. Docker ສາມາດລິເລີ່ມການກໍ່ສ້າງຄືນໃຫມ່ທີ່ບໍ່ຈໍາເປັນ, ເຖິງແມ່ນວ່າຈະສ້າງຄໍາຫມັ້ນສັນຍາດຽວກັນ, ແຕ່ມາຈາກຕົ້ນໄມ້ທີ່ແຕກຕ່າງກັນ. ຕົວຢ່າງ, GitLab ສ້າງໄດເລກະທໍລີ cloned ແຍກຕ່າງຫາກໃນ /home/gitlab-runner/builds/HASH/[0-N]/yourproject ເມື່ອການປະກອບຂະຫນານຖືກເປີດໃຊ້. ການປະກອບ reassembly ພິເສດຈະເປັນຍ້ອນຄວາມຈິງທີ່ວ່າໄດເລກະທໍລີ .git ແມ່ນແຕກຕ່າງກັນໃນສະບັບ cloned ທີ່ແຕກຕ່າງກັນຂອງ repository ດຽວກັນ, ເຖິງແມ່ນວ່າຖ້າຫາກວ່າຄໍາຫມັ້ນສັນຍາດຽວກັນຖືກສ້າງຂຶ້ນ.

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

ໂດຍທົ່ວໄປ ເພີ່ມໄຟລ໌ທີ່ຈໍາເປັນສະເພາະ ໂດຍຜ່ານຄໍາແນະນໍາ ADD ໃນກໍລະນີໃດກໍ່ຕາມ, ເພີ່ມປະສິດທິພາບແລະຄວາມຫນ້າເຊື່ອຖືຂອງການຂຽນ Dockerfile, ແລະຍັງປັບປຸງຄວາມຫມັ້ນຄົງຂອງ cache ທີ່ເກັບກໍາສໍາລັບການນີ້ Dockerfile, ກັບການປ່ຽນແປງທີ່ບໍ່ກ່ຽວຂ້ອງໃນ Git.

ຜົນໄດ້ຮັບ

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

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

ດັ່ງນັ້ນ, ຖ້າທ່ານທັນທີທັນໃດມີ Dockerfiles ສອງອັນຢູ່ອ້ອມ ... ພະຍາຍາມ werf!

PS ບັນຊີລາຍຊື່ເອກະສານກ່ຽວກັບຫົວຂໍ້

• ຄູ່ມືສໍາລັບການເລີ່ມຕົ້ນໄວ;
• ການຕັ້ງຄ່າຕົວສ້າງ dockerfile;
• ອຸປະກອນຂັ້ນຕອນໃນ werf;
• ຂະບວນການເຜີຍແຜ່ຮູບພາບ;
• ການເຊື່ອມໂຍງກັບຂະບວນການນຳໃຊ້ Kubernetes;
• ຂະບວນການທໍາຄວາມສະອາດ;
• Stapel builder ເປັນທາງເລືອກສໍາລັບ Dockerfile.

ອ່ານໃນ blog ຂອງພວກເຮົາ: "werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes (ພາບລວມແລະບົດລາຍງານວິດີໂອ)".

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