ການປະຕິບັດການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງກັບ Docker (ການທົບທວນຄືນແລະວິດີໂອ)

ພວກເຮົາຈະເລີ່ມຕົ້ນ blog ຂອງພວກເຮົາດ້ວຍການພິມເຜີຍແຜ່ໂດຍອີງໃສ່ຄໍາເວົ້າຫຼ້າສຸດຂອງຜູ້ອໍານວຍການດ້ານວິຊາການຂອງພວກເຮົາ disstol (Dmitry Stolyarov). ທັງຫມົດຂອງພວກເຂົາໄດ້ຈັດຂຶ້ນໃນປີ 2016 ໃນກິດຈະກໍາມືອາຊີບຕ່າງໆແລະໄດ້ອຸທິດຕົນເພື່ອຫົວຂໍ້ຂອງ DevOps ແລະ Docker. ວິດີໂອຫນຶ່ງຈາກກອງປະຊຸມ Docker Moscow ຢູ່ຫ້ອງການ Badoo, ພວກເຮົາມີແລ້ວ ຈັດພີມມາ ອອນລາຍ. ບົດຄວາມໃຫມ່ຈະມາພ້ອມກັບບົດຄວາມທີ່ຖ່າຍທອດຄວາມສໍາຄັນຂອງບົດລາຍງານ. ດັ່ງນັ້ນ…

ວັນທີ 31 ພຶດສະພາ ທີ່ກອງປະຊຸມ RootConf 2016, ໄດ້ຈັດຂຶ້ນເປັນສ່ວນຫນຶ່ງຂອງງານບຸນ "ເຕັກໂນໂລຢີອິນເຕີເນັດຂອງລັດເຊຍ" (RIT ++ 2016), ພາກສ່ວນ "ການປະຕິບັດແລະການນໍາໃຊ້ຢ່າງຕໍ່ເນື່ອງ" ໄດ້ເປີດດ້ວຍບົດລາຍງານ "ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງກັບ Docker". ມັນໄດ້ສະຫຼຸບແລະຈັດລະບົບການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການສ້າງຂະບວນການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ (CD) ໂດຍໃຊ້ Docker ແລະຜະລິດຕະພັນ Open Source ອື່ນໆ. ພວກເຮົາເຮັດວຽກຮ່ວມກັບການແກ້ໄຂເຫຼົ່ານີ້ໃນການຜະລິດ, ເຊິ່ງອະນຸຍາດໃຫ້ພວກເຮົາອີງໃສ່ປະສົບການປະຕິບັດ.

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

ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງກັບ Docker

ພາຍໃຕ້ ການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ ພວກເຮົາເຂົ້າໃຈລະບົບຕ່ອງໂສ້ຂອງເຫດການທີ່ເປັນຜົນມາຈາກການທີ່ລະຫັດຄໍາຮ້ອງສະຫມັກຈາກບ່ອນເກັບມ້ຽນ Git ທໍາອິດມາຮອດການຜະລິດ, ແລະຫຼັງຈາກນັ້ນສິ້ນສຸດລົງໃນບ່ອນເກັບມ້ຽນ. ມັນເບິ່ງຄືວ່ານີ້: Git → Build → Test → Release → Operate.

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

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

ຮູບແບບການເປີດຕົວຫຼັກ

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

ດັ່ງນັ້ນ, ສໍາລັບບາງຄັ້ງທັງສອງຮຸ່ນຂອງແອັບພລິເຄຊັນ (ເກົ່າແລະໃຫມ່) ຈະເຮັດວຽກພ້ອມໆກັນ. ເຊິ່ງອັດຕະໂນມັດນໍາໄປສູ່ ການຂັດແຍ້ງກ່ຽວກັບຊັບພະຍາກອນທີ່ແບ່ງປັນ: ເຄືອຂ່າຍ, ລະບົບໄຟລ໌, IPC, ແລະອື່ນໆ. ດ້ວຍ Docker, ບັນຫານີ້ຖືກແກ້ໄຂໄດ້ງ່າຍໂດຍການແລ່ນເວີຊັນຕ່າງໆຂອງແອັບພລິເຄຊັນຢູ່ໃນຖັງແຍກຕ່າງຫາກ, ເຊິ່ງການແຍກຊັບພະຍາກອນແມ່ນຮັບປະກັນພາຍໃນໂຮດດຽວກັນ (ເຄື່ອງແມ່ຂ່າຍ / ເຄື່ອງ virtual). ແນ່ນອນ, ທ່ານສາມາດໄດ້ຮັບໂດຍບາງ tricks ໂດຍບໍ່ມີການ insulation ທັງຫມົດ, ແຕ່ຖ້າຫາກວ່າມີເຄື່ອງມືທີ່ພ້ອມທີ່ຈະເຮັດແລະສະດວກ, ຫຼັງຈາກນັ້ນມີເຫດຜົນກົງກັນຂ້າມ - ບໍ່ໃຫ້ລະເລີຍມັນ.

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

ຂໍໃຫ້ສະຫຼຸບ ຮູບແບບການເປີດຕົວຕົ້ນຕໍ ສະ​ບັບ​ໃຫມ່​ໂດຍ​ພິ​ຈາ​ລະ​ນາ​ປັດ​ໄຈ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

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

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

ຄໍາ​ແນະ​ນໍາ​ຄັ້ງ​ທໍາ​ອິດ​ສຸດ​ທ້າຍ​ສຽງ​ຄ້າຍ​ຄື​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ເຖິງ​ແມ່ນ​ວ່າ​ກັບ​ຕັນ​ຍັງ​ບໍ່​ສາ​ມາດ​ຊອກ​ຫາ​ຄວາມ​ຜິດ​ຂອງ​: “.[ເມື່ອຈັດການການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງກັບ Docker] ໃຊ້ Docker [ແລະເຂົ້າໃຈສິ່ງທີ່ມັນໃຫ້]" ຈືຂໍ້ມູນການ, ນີ້ບໍ່ແມ່ນລູກປືນເງິນທີ່ຈະແກ້ໄຂທຸກບັນຫາ, ແຕ່ເປັນເຄື່ອງມືທີ່ສະຫນອງພື້ນຖານທີ່ດີເລີດ.

ການສືບພັນ

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

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

ໂດຍເນື້ອແທ້ແລ້ວຂອງເຂົາເຈົ້າຕົ້ມລົງໄປເຖິງຄວາມຈິງທີ່ວ່າການປະຕິບັດຕາມສະພາບແວດລ້ອມທີ່ນໍາໃຊ້ຢ່າງເຕັມທີ່ (ເຊັ່ນດຽວກັນກັບການຂາດປັດໃຈຂອງມະນຸດ) ແມ່ນມີຄວາມຈໍາເປັນ. ພວກເຮົາສາມາດຮັບປະກັນການສືບພັນໄດ້ແນວໃດ? ສ້າງຮູບພາບ Docker ອີງໃສ່ລະຫັດຈາກ Git, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ພວກມັນສໍາລັບວຽກງານໃດກໍ່ຕາມ: ໃນສະຖານທີ່ທົດສອບ, ໃນການຜະລິດ, ໃນເຄື່ອງຈັກທ້ອງຖິ່ນຂອງໂປລແກລມ ... ໃນເວລາດຽວກັນ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຫຼຸດຜ່ອນການປະຕິບັດທີ່ຖືກປະຕິບັດ. после ປະກອບຮູບພາບ: ມັນງ່າຍກວ່າ, ຄວາມເປັນໄປໄດ້ຫນ້ອຍທີ່ຈະມີຄວາມຜິດພາດ.

ໂຄງສ້າງພື້ນຖານແມ່ນລະຫັດ

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

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

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

ຮູບພາບ Docker, ການສື່ສານກັບ Git

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

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

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

ດີບ

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

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

ອັບເດດ 13 ສິງຫາ 2019: ໃນປັດຈຸບັນເປັນໂຄງການ ດີບ ປ່ຽນຊື່ເປັນ werf, ລະຫັດຂອງມັນໄດ້ຖືກຂຽນຄືນໃຫມ່ຢ່າງສົມບູນໃນ Go, ແລະເອກະສານຂອງມັນຖືກປັບປຸງຢ່າງຫຼວງຫຼາຍ.

Kubernetes

ອີກປະການຫນຶ່ງເຄື່ອງມື Open Source ທີ່ກຽມພ້ອມທີ່ໄດ້ຮັບການຍອມຮັບແລ້ວໃນສະພາບແວດລ້ອມທີ່ເປັນມືອາຊີບແມ່ນ Kubernetes, ກຸ່ມການຈັດການ Docker. ຫົວຂໍ້ຂອງການນໍາໃຊ້ຂອງມັນໃນການດໍາເນີນງານຂອງໂຄງການທີ່ສ້າງຂຶ້ນໃນ Docker ແມ່ນເກີນຂອບເຂດຂອງບົດລາຍງານ, ດັ່ງນັ້ນການນໍາສະເຫນີແມ່ນຖືກຈໍາກັດໃນສະພາບລວມຂອງບາງລັກສະນະທີ່ຫນ້າສົນໃຈ.

ສຳລັບການເປີດຕົວ, Kubernetes ສະເໜີໃຫ້:

• ການ​ສອບ​ສວນ​ຄວາມ​ພ້ອມ — ການ​ກວດ​ສອບ​ຄວາມ​ພ້ອມ​ຂອງ​ການ​ສະ​ບັບ​ໃຫມ່​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ (ເພື່ອ​ສະ​ຫຼັບ​ການ​ຈະ​ລາ​ຈອນ​ກັບ​ມັນ​)​;
• rolling update - sequential image update in a cluster of containers (ການປິດ, ການປັບປຸງ, ການກະກຽມສໍາລັບການເປີດຕົວ, ການສະຫຼັບການຈະລາຈອນ);
• synchronous update - ການປັບປຸງຮູບພາບໃນກຸ່ມທີ່ມີວິທີການທີ່ແຕກຕ່າງກັນ: ທໍາອິດໃສ່ເຄິ່ງຫນຶ່ງຂອງຖັງ, ຫຼັງຈາກນັ້ນສ່ວນທີ່ເຫຼືອ;
• canary releases - ການເປີດຕົວຮູບພາບໃຫມ່ໃນຈໍານວນຈໍາກັດ (ຂະຫນາດນ້ອຍ) ຂອງບັນຈຸເພື່ອຕິດຕາມກວດກາຜິດປົກກະຕິ.

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

ຄໍາແນະນໍາສຸດທ້າຍ

1. ໃຊ້ Docker.
2. ສ້າງຮູບພາບ Docker ຂອງແອັບພລິເຄຊັນສໍາລັບທຸກຄວາມຕ້ອງການຂອງທ່ານ.
3. ປະຕິບັດຕາມຫຼັກການ "ໂຄງສ້າງພື້ນຖານແມ່ນລະຫັດ."
4. ເຊື່ອມຕໍ່ Git ກັບ Docker.
5. ຄວບຄຸມຄໍາສັ່ງຂອງການເປີດຕົວ.
6. ໃຊ້ແພລະຕະຟອມທີ່ກຽມພ້ອມ (Kubernetes ຫຼືອື່ນ).

ວິດີໂອ ແລະສະໄລ້

ວິດີໂອຈາກການສະແດງ (ປະມານຫນຶ່ງຊົ່ວໂມງ) ເຜີຍແຜ່ໃນ YouTube (ບົດ​ລາຍ​ງານ​ຕົວ​ມັນ​ເອງ​ເລີ່ມ​ຈາກ​ນາ​ທີ 5 - ປະ​ຕິ​ບັດ​ຕາມ​ການ​ເຊື່ອມ​ຕໍ່​ການ​ຫຼິ້ນ​ຈາກ​ປັດ​ຈຸ​ບັນ​ນີ້​).

ການ​ນໍາ​ສະ​ເຫນີ​ບົດ​ລາຍ​ງານ​:

PS

ບົດລາຍງານອື່ນໆກ່ຽວກັບຫົວຂໍ້ໃນ blog ຂອງພວກເຮົາ:

• «werf - ເຄື່ອງມືຂອງພວກເຮົາສໍາລັບ CI / CD ໃນ Kubernetes (ພາບລວມແລະບົດລາຍງານວິດີໂອ)» (Dmitry Stolyarov; 27 ພຶດສະພາ 2019 ຢູ່ DevOpsConf);
• «ຖານຂໍ້ມູນ ແລະ Kubernetes» (Dmitry Stolyarov; ເດືອນພະຈິກ 8, 2018 on HighLoad++);
• «CI/CD ການປະຕິບັດທີ່ດີທີ່ສຸດກັບ Kubernetes ແລະ GitLab» (Dmitry Stolyarov; ເດືອນພະຈິກ 7, 2017 on HighLoad++);
• «ປະສົບການຂອງພວກເຮົາກັບ Kubernetes ໃນໂຄງການຂະຫນາດນ້ອຍ» (Dmitry Stolyarov; 6 ເດືອນມິຖຸນາ 2017 ຢູ່ RootConf).

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