Southbridge ໃນ Chelyabinsk ແລະ Bitrix ໃນ Kubernetes

ກອງປະຊຸມຜູ້ເບິ່ງແຍງລະບົບ Sysadminka ກໍາລັງດໍາເນີນຢູ່ໃນ Chelyabinsk, ແລະໃນທີ່ສຸດຂ້າພະເຈົ້າໄດ້ໃຫ້ບົດລາຍງານກ່ຽວກັບການແກ້ໄຂຂອງພວກເຮົາສໍາລັບການແລ່ນຄໍາຮ້ອງສະຫມັກໃນ 1C-Bitrix ໃນ Kubernetes.

Bitrix, Kubernetes, Ceph - ປະສົມທີ່ຍິ່ງໃຫຍ່?

ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບອກ​ທ່ານ​ກ່ຽວ​ກັບ​ວິ​ທີ​ການ​ທີ່​ພວກ​ເຮົາ​ລວມ​ເອົາ​ວິ​ທີ​ແກ້​ໄຂ​ທີ່​ເຮັດ​ວຽກ​ຈາກ​ທັງ​ຫມົດ​ນີ້​.

ໃຫ້ໄປ!

ການ​ພົບ​ປະ​ດັ່ງກ່າວ​ໄດ້​ຈັດ​ຂຶ້ນ​ໃນ​ວັນ​ທີ 18 ​ເມສາ​ນີ້ ຢູ່ Chelyabinsk. ທ່ານສາມາດອ່ານກ່ຽວກັບກອງປະຊຸມຂອງພວກເຮົາໄດ້ທີ່ ແຜ່ນເວລາ ແລະເບິ່ງ YouTube.

ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຕ້ອງ​ການ​ທີ່​ຈະ​ມາ​ຫາ​ພວກ​ເຮົາ​ໂດຍ​ມີ​ບົດ​ລາຍ​ງານ​ຫຼື​ເປັນ​ຜູ້​ຟັງ - ຍິນ​ດີ​ຕ້ອນ​ຮັບ​, ຂຽນ​ຫາ​ [email protected] ແລະໃນ Telegram t.me/vadimisakanov.

ບົດລາຍງານຂອງຂ້ອຍ

ສະໄລ້

ການແກ້ໄຂ "Bitrix ໃນ Kubernetes, ຮຸ່ນ Southbridge 1.0"

ຂ້ອຍຈະເວົ້າກ່ຽວກັບການແກ້ໄຂຂອງພວກເຮົາໃນຮູບແບບ "ສໍາລັບ dummies ໃນ Kubernetes", ດັ່ງທີ່ໄດ້ເຮັດຢູ່ໃນກອງປະຊຸມ. ແຕ່ຂ້ອຍສົມມຸດວ່າເຈົ້າຮູ້ຈັກຄໍາສັບ Bitrix, Docker, Kubernetes, Ceph ຢ່າງຫນ້ອຍໃນລະດັບຂອງບົດຄວາມໃນ Wikipedia.

ສິ່ງທີ່ພ້ອມທີ່ຈະເຮັດກ່ຽວກັບ Bitrix ໃນ Kubernetes?

ມີຂໍ້ມູນພຽງເລັກນ້ອຍຫຼາຍຢູ່ໃນອິນເຕີເນັດທັງຫມົດກ່ຽວກັບການດໍາເນີນງານຂອງຄໍາຮ້ອງສະຫມັກ Bitrix ໃນ Kubernetes.
ຂ້ອຍພົບອຸປະກອນເຫຼົ່ານີ້ເທົ່ານັ້ນ:

ລາຍງານໂດຍ Alexander Serbul, 1C-Bitrix, ແລະ Anton Tuzlukov ຈາກ Qsoft:

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ຟັງມັນ.

ການພັດທະນາການແກ້ໄຂຂອງທ່ານເອງຈາກຜູ້ໃຊ້ serkyron ສຸດ Habre.
ພົບຫຼາຍ ການຕັດສິນໃຈດັ່ງກ່າວ.

Aaand ... ຕົວຈິງແລ້ວ, ນັ້ນແມ່ນທັງຫມົດ.

ຂ້າພະເຈົ້າເຕືອນທ່ານ, ພວກເຮົາບໍ່ໄດ້ກວດເບິ່ງຄຸນນະພາບຂອງການແກ້ໄຂໃນການເຊື່ອມຕໍ່ຂ້າງເທິງ :)
ໂດຍວິທີທາງການ, ໃນເວລາທີ່ການກະກຽມການແກ້ໄຂຂອງພວກເຮົາ, ຂ້າພະເຈົ້າໄດ້ໂອ້ລົມກັບ Alexander Serbul, ຫຼັງຈາກນັ້ນບົດລາຍງານຂອງລາວຍັງບໍ່ທັນປາກົດ, ດັ່ງນັ້ນໃນສະໄລ້ຂອງຂ້ອຍມີລາຍການ "Bitrix ບໍ່ໃຊ້ Kubernetes."

ແຕ່ມີຮູບພາບ Docker ທີ່ກຽມພ້ອມແລ້ວຫຼາຍສໍາລັບການແລ່ນ Bitrix ໃນ Docker: https://hub.docker.com/search?q=bitrix&type=image

ນີ້ພຽງພໍທີ່ຈະສ້າງການແກ້ໄຂທີ່ສົມບູນແບບສໍາລັບ Bitrix ໃນ Kubernetes ບໍ?
ບໍ່. ມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງບັນຫາທີ່ຕ້ອງໄດ້ຮັບການແກ້ໄຂ.

ບັນຫາຫຍັງກັບ Bitrix ໃນ Kubernetes?

ຫນ້າທໍາອິດ, ຮູບພາບທີ່ກຽມພ້ອມຈາກ Dockerhub ບໍ່ເຫມາະສົມກັບ Kubernetes

ຖ້າພວກເຮົາຕ້ອງການສ້າງສະຖາປັດຕະຍະກໍາ microservices (ແລະຢູ່ໃນ Kubernetes ປົກກະຕິແລ້ວພວກເຮົາເຮັດ), ພວກເຮົາຈໍາເປັນຕ້ອງແຍກຄໍາຮ້ອງສະຫມັກ Kubernetes ຂອງພວກເຮົາອອກເປັນບັນຈຸແລະໃຫ້ແຕ່ລະ container ປະຕິບັດຫນ້າທີ່ຂະຫນາດນ້ອຍຫນຶ່ງ (ແລະເຮັດໄດ້ດີ). ເປັນຫຍັງພຽງແຕ່ຫນຶ່ງ? ໃນສັ້ນ, ງ່າຍດາຍຫຼາຍທີ່ເຊື່ອຖືໄດ້ຫຼາຍ.
ເພື່ອໃຫ້ມີຄວາມສະເພາະຫຼາຍ, ເບິ່ງບົດຄວາມນີ້ແລະວິດີໂອ, ກະລຸນາ: https://habr.com/ru/company/southbridge/blog/426637/

ຮູບພາບ Docker ໃນ Dockerhub ສ່ວນໃຫຍ່ແມ່ນຖືກສ້າງຂຶ້ນໃນຫຼັກການທັງຫມົດໃນຫນຶ່ງ, ດັ່ງນັ້ນພວກເຮົາຍັງຕ້ອງເຮັດລົດຖີບຂອງພວກເຮົາເອງແລະແມ້ກະທັ້ງສ້າງຮູບພາບຈາກຈຸດເລີ່ມຕົ້ນ.

ອັນທີສອງ - ລະຫັດເວັບໄຊທ໌ໄດ້ຖືກດັດແກ້ຈາກກະດານ admin

ພວກເຮົາໄດ້ສ້າງພາກໃຫມ່ຢູ່ໃນເວັບໄຊທ໌ - ລະຫັດໄດ້ຖືກປັບປຸງ (ໄດເລກະທໍລີທີ່ມີຊື່ຂອງພາກໃຫມ່ໄດ້ຖືກເພີ່ມ).

ຖ້າທ່ານປ່ຽນຄຸນສົມບັດຂອງອົງປະກອບຈາກກະດານ admin, ລະຫັດຈະປ່ຽນແປງ.

Kubernetes “ຕາມຄ່າເລີ່ມຕົ້ນ” ບໍ່ສາມາດເຮັດວຽກກັບເຄື່ອງບັນຈຸຕ້ອງບໍ່ມີລັດ.

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

ອັນທີສາມ - ທ່ານຈໍາເປັນຕ້ອງໄດ້ແກ້ໄຂບັນຫາທີ່ມີການນໍາໃຊ້

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

ສີ່ - ທ່ານຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫາຂອງການເກັບຮັກສາ statics ໄດ້

ຖ້າເວັບໄຊຂອງທ່ານແມ່ນ "ພຽງແຕ່" 10 gigabyte ແລະທ່ານນໍາໃຊ້ມັນທັງຫມົດໃນບັນຈຸ, ທ່ານຈະສິ້ນສຸດດ້ວຍ 10 gigabyte containers ທີ່ໃຊ້ເວລາຕະຫຼອດໄປເພື່ອ deploy.
ທ່ານ ຈຳ ເປັນຕ້ອງເກັບສ່ວນທີ່ "ໜັກທີ່ສຸດ" ຂອງເວັບໄຊທ໌ຢູ່ນອກຕູ້ຄອນເທນເນີ, ແລະ ຄຳ ຖາມທີ່ເກີດຂື້ນກ່ຽວກັບວິທີການເຮັດຢ່າງຖືກຕ້ອງ.

ສິ່ງທີ່ຂາດຫາຍໄປຈາກການແກ້ໄຂຂອງພວກເຮົາ?

ລະຫັດ Bitrix ທັງຫມົດບໍ່ໄດ້ຖືກແບ່ງອອກເປັນ microfunctions / microservices (ດັ່ງນັ້ນການລົງທະບຽນແມ່ນແຍກຕ່າງຫາກ, ໂມດູນຮ້ານຄ້າອອນໄລນ໌ແມ່ນແຍກຕ່າງຫາກ, ແລະອື່ນໆ). ພວກເຮົາເກັບຮັກສາພື້ນຖານລະຫັດທັງຫມົດໃນແຕ່ລະຖັງ.

ພວກເຮົາຍັງບໍ່ໄດ້ເກັບຮັກສາຖານຂໍ້ມູນໃນ Kubernetes (ຂ້າພະເຈົ້າຍັງປະຕິບັດການແກ້ໄຂກັບຖານຂໍ້ມູນໃນ Kubernetes ສໍາລັບສະພາບແວດລ້ອມການພັດທະນາ, ແຕ່ບໍ່ແມ່ນສໍາລັບການຜະລິດ).

ມັນຍັງຄົງເປັນທີ່ສັງເກດໄດ້ຕໍ່ກັບຜູ້ເບິ່ງແຍງເວັບໄຊທ໌ທີ່ເວັບໄຊທ໌ເຮັດວຽກຢູ່ໃນ Kubernetes. ຟັງຊັນ "ກວດສອບລະບົບ" ເຮັດວຽກບໍ່ຖືກຕ້ອງ;

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

ຖາປັດຕະຍະ

ມີຫຼາຍຝັກ "ເຮັດວຽກ" ກັບເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ (ພະນັກງານ).
ຫນຶ່ງພາຍໃຕ້ກັບວຽກງານ cron (ພຽງແຕ່ຫນຶ່ງແມ່ນຕ້ອງການ).
ການອັບເກຣດໜຶ່ງອັນສຳລັບການດັດແກ້ລະຫັດເວັບໄຊຈາກກະດານ admin (ຍັງຕ້ອງການອັນດຽວເທົ່ານັ້ນ).

ພວກເຮົາແກ້ໄຂຄໍາຖາມ:

• ບ່ອນເກັບເຊດຊັນ?
• ບ່ອນເກັບ cache?
• ບ່ອນໃດທີ່ຈະເກັບຮັກສາສະຖິດ, ບໍ່ແມ່ນການວາງ gigabytes ຂອງ statics ໃນຊໍ່ຂອງບັນຈຸ?
• ຖານຂໍ້ມູນຈະເຮັດວຽກແນວໃດ?

ຮູບພາບ Docker

ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍການສ້າງຮູບພາບ Docker.

ທາງເລືອກທີ່ເຫມາະສົມແມ່ນວ່າພວກເຮົາມີຮູບພາບທົ່ວໄປຫນຶ່ງ, ບົນພື້ນຖານຂອງມັນພວກເຮົາໄດ້ຮັບ pods ພະນັກງານ, ຝັກທີ່ມີ Crontasks, ແລະປັບປຸງ pods.

ພວກເຮົາສ້າງຮູບພາບດັ່ງກ່າວ.

ມັນປະກອບມີ nginx, apache / php-fpm (ສາມາດເລືອກໄດ້ໃນລະຫວ່າງການສ້າງ), msmtp ສໍາລັບການສົ່ງອີເມວ, ແລະ cron.

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

ບໍລິການຈຸລະພາກ, ບໍລິການ

ຝັກ​ຄົນ​ງານ​:

• ຕູ້ຄອນເທນເນີທີ່ມີ nginx + container apache/php-fpm + msmtp
• ມັນບໍ່ໄດ້ຜົນທີ່ຈະຍ້າຍ msmtp ເຂົ້າໄປໃນ microservice ແຍກຕ່າງຫາກ, Bitrix ກໍາລັງເລີ່ມ indignant ທີ່ມັນບໍ່ສາມາດສົ່ງ mail ໂດຍກົງ.
• ແຕ່ລະບັນຈຸມີ codebase ສົມບູນ.
• ການຫ້າມການປ່ຽນລະຫັດໃນຖັງ.

cron ພາຍໃຕ້:

• container ທີ່ມີ apache, php, cron
• ພື້ນຖານລະຫັດຄົບຖ້ວນລວມ
• ຫ້າມການປ່ຽນລະຫັດໃນກ່ອງບັນຈຸ

ຍົກລະດັບພາຍໃຕ້:

• nginx container + apache/php-fpm container + msmtp
• ບໍ່ມີຂໍ້ຫ້າມໃນການປ່ຽນແປງລະຫັດໃນຕູ້ຄອນເທນເນີ

ການເກັບຮັກສາເຊດຊັນ

ການເກັບຮັກສາ cache Bitrix

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

ການເກັບຮັກສາສໍາລັບສະຖິດ

ທ່ານສາມາດນໍາໃຊ້ສິ່ງໃດກໍ່ຕາມ: ceph, nfs (ແຕ່ພວກເຮົາບໍ່ແນະນໍາ nfs ສໍາລັບການຜະລິດ), ການເກັບຮັກສາເຄືອຂ່າຍຈາກຜູ້ໃຫ້ບໍລິການຟັງ, ແລະອື່ນໆ.

ການເກັບຮັກສາຈະຕ້ອງໄດ້ຮັບການເຊື່ອມຕໍ່ໃນບັນຈຸກັບ /upload/ directory ຂອງເວັບໄຊທ໌ແລະໄດເລກະທໍລີອື່ນໆທີ່ມີເນື້ອໃນຄົງທີ່.

ຖານຂໍ້ມູນ

ເພື່ອຄວາມງ່າຍດາຍ, ພວກເຮົາແນະນຳໃຫ້ຍ້າຍຖານຂໍ້ມູນອອກໄປນອກ Kubernetes. ພື້ນຖານໃນ Kubernetes ແມ່ນວຽກງານທີ່ສັບສົນແຍກຕ່າງຫາກ;

ການເກັບຮັກສາເຊດຊັນ

ພວກເຮົາໃຊ້ memcached :)

ມັນຈັດການການເກັບຮັກສາເຊດຊັນໄດ້ດີ, ເປັນກຸ່ມ, ແລະຖືກສະຫນັບສະຫນູນ "natively" ເປັນ session.save_path ໃນ php. ລະບົບດັ່ງກ່າວໄດ້ຖືກທົດສອບຫຼາຍຄັ້ງໃນສະຖາປັດຕະຍະກໍາ monolithic ຄລາສສິກ, ເມື່ອພວກເຮົາສ້າງກຸ່ມທີ່ມີຈໍານວນເຄື່ອງແມ່ຂ່າຍເວັບ. ສໍາລັບການປະຕິບັດພວກເຮົາໃຊ້ຫມວກກັນກະທົບ.

$ helm install stable/memcached --name session

php.ini - ທີ່ນີ້ຮູບພາບປະກອບດ້ວຍການຕັ້ງຄ່າສໍາລັບການເກັບຮັກສາ sessions ໃນ memcached

ພວກເຮົາໄດ້ໃຊ້ຕົວແປສະພາບແວດລ້ອມເພື່ອຖ່າຍທອດຂໍ້ມູນກ່ຽວກັບໂຮສດ້ວຍ memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
ນີ້ອະນຸຍາດໃຫ້ທ່ານໃຊ້ລະຫັດດຽວກັນໃນສະພາບແວດລ້ອມ dev, ຂັ້ນຕອນ, ການທົດສອບ, prod (ຊື່ເຈົ້າພາບຂອງ memcached ໃນພວກມັນຈະແຕກຕ່າງກັນ, ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງຜ່ານຊື່ໂຮດທີ່ເປັນເອກະລັກສໍາລັບ sessions ແຕ່ລະສະພາບແວດລ້ອມ).
ການເກັບຮັກສາ cache Bitrix

ພວກເຮົາຕ້ອງການບ່ອນເກັບມ້ຽນທີ່ທົນທານຕໍ່ຄວາມຜິດພາດທີ່ຝັກທັງໝົດສາມາດຂຽນຫາ ແລະອ່ານໄດ້.

ພວກເຮົາຍັງໃຊ້ memcached.
ການແກ້ໄຂນີ້ແມ່ນແນະນໍາໂດຍ Bitrix ຕົວຂອງມັນເອງ.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - ທີ່ນີ້ໃນ Bitrix ມັນຖືກລະບຸບ່ອນທີ່ cache ຖືກເກັບໄວ້.

ພວກເຮົາຍັງໃຊ້ຕົວແປສະພາບແວດລ້ອມ.

Krontaski

ມີວິທີການຕ່າງໆໃນການແລ່ນ Crontask ໃນ Kubernetes.

• ການນຳໃຊ້ແຍກຕ່າງຫາກດ້ວຍຝັກສຳລັບແລ່ນ Crontasks
• cronjob ສໍາລັບການປະຕິບັດ crontask (ຖ້ານີ້ແມ່ນ app ເວັບ - ກັບ wget https://$host$cronjobname, ຫຼື kubectl exec ພາຍໃນຫນຶ່ງຂອງຝັກພະນັກງານ, ແລະອື່ນໆ.)
• ແລະອື່ນໆ

ທ່ານສາມາດໂຕ້ແຍ້ງກ່ຽວກັບອັນທີ່ຖືກຕ້ອງທີ່ສຸດ, ແຕ່ໃນກໍລະນີນີ້ພວກເຮົາໄດ້ເລືອກທາງເລືອກ "ການຕິດຕັ້ງແຍກຕ່າງຫາກກັບຝັກສໍາລັບ Crontasks"

ມັນເຮັດແນວໃດ:

• ເພີ່ມໜ້າວຽກ cron ຜ່ານ ConfigMap ຫຼືຜ່ານໄຟລ໌ config/addcron
• ໃນຕົວຢ່າງຫນຶ່ງທີ່ພວກເຮົາເປີດຕົວຕູ້ຄອນເທນເນີທີ່ຄ້າຍຄືກັບ pod ພະນັກງານ + ອະນຸຍາດໃຫ້ປະຕິບັດຫນ້າວຽກຂອງເຮືອນຍອດໃນມັນ.
• ພື້ນຖານລະຫັດດຽວກັນຖືກນໍາໃຊ້, ຂໍຂອບໃຈກັບການລວມຕົວ, ການປະກອບພາຊະນະແມ່ນງ່າຍດາຍ

ສິ່ງທີ່ດີທີ່ພວກເຮົາໄດ້ຮັບ:

• ພວກເຮົາມີການເຮັດວຽກ Crontask ໃນສະພາບແວດລ້ອມທີ່ຄ້າຍຄືກັບສະພາບແວດລ້ອມຂອງຜູ້ພັດທະນາ (docker)
• Crontasks ບໍ່ຈໍາເປັນຕ້ອງຖືກ "ຂຽນໃຫມ່" ສໍາລັບ Kubernetes, ພວກເຂົາເຮັດວຽກໃນຮູບແບບດຽວກັນແລະໃນຖານລະຫັດດຽວກັນກັບກ່ອນ.
• ວຽກງານ cron ສາມາດຖືກເພີ່ມໂດຍສະມາຊິກທີມງານທັງຫມົດທີ່ມີຄໍາຫມັ້ນສັນຍາກັບສາຂາການຜະລິດ, ບໍ່ພຽງແຕ່ admins

ໂມດູນ Southbridge K8SDeploy ແລະການແກ້ໄຂລະຫັດຈາກກະດານ admin

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

ແລະມັນເບິ່ງຄືວ່ານີ້:

ມັນອະນຸຍາດໃຫ້ທ່ານຕັ້ງຄຸກກີທີ່ກໍານົດຜູ້ເບິ່ງແຍງເວັບໄຊທ໌ແລະອະນຸຍາດໃຫ້ Kubernetes ສົ່ງການຈະລາຈອນໄປຫາ pod ຍົກລະດັບ.

ເມື່ອການປ່ຽນແປງສໍາເລັດ, ທ່ານຈໍາເປັນຕ້ອງກົດ git push, ການປ່ຽນແປງລະຫັດຈະຖືກສົ່ງໄປຫາ git, ຫຼັງຈາກນັ້ນລະບົບຈະສ້າງຮູບພາບທີ່ມີລະຫັດຮຸ່ນໃຫມ່ແລະ "ມ້ວນອອກ" ມັນໃນທົ່ວກຸ່ມ, ແທນທີ່ຝັກເກົ່າ. .

ແມ່ນແລ້ວ, ມັນເປັນໄມ້ທ່ອນເລັກນ້ອຍ, ແຕ່ໃນເວລາດຽວກັນພວກເຮົາຮັກສາສະຖາປັດຕະຍະກໍາ microservice ແລະບໍ່ເອົາໂອກາດຈາກຜູ້ໃຊ້ Bitrix ທີ່ພວກເຂົາມັກໃນການແກ້ໄຂລະຫັດຈາກກະດານ admin. ໃນທີ່ສຸດ, ນີ້ແມ່ນທາງເລືອກຫນຶ່ງ;

ຕາຕະລາງຫມວກກັນກະທົບ

ເພື່ອສ້າງແອັບພລິເຄຊັນໃນ Kubernetes, ພວກເຮົາປົກກະຕິໃຊ້ຕົວຈັດການແພັກເກັດ Helm.
ສໍາລັບການແກ້ໄຂ Bitrix ຂອງພວກເຮົາໃນ Kubernetes, Sergey Bondarev, ຜູ້ບໍລິຫານລະບົບຊັ້ນນໍາຂອງພວກເຮົາ, ຂຽນຕາຕະລາງ Helm ພິເສດ.

ມັນສ້າງພະນັກງານ, ຍົກລະດັບ, cron pods, configures ingresses, ບໍລິການ, ແລະການໂອນຕົວແປຈາກຄວາມລັບ Kubernetes ໄປຫາ pods.

ພວກເຮົາເກັບຮັກສາລະຫັດໃນ Gitlab, ແລະພວກເຮົາຍັງດໍາເນີນການ Helm build ຈາກ Gitlab.

ໃນສັ້ນ, ມັນເບິ່ງຄືວ່ານີ້

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm ຍັງອະນຸຍາດໃຫ້ທ່ານເຮັດການມ້ວນຄືນແບບ “ບໍ່ມີຮອຍຕໍ່” ຖ້າມີບາງຢ່າງຜິດພາດເກີດຂຶ້ນຢ່າງກະທັນຫັນໃນລະຫວ່າງການນຳໃຊ້. ມັນດີໃນເວລາທີ່ທ່ານບໍ່ຕົກຢູ່ໃນຄວາມຕື່ນຕົກໃຈ "ແກ້ໄຂລະຫັດຜ່ານ ftp ເພາະວ່າຜະລິດຕະພັນຫຼຸດລົງ," ແຕ່ Kubernetes ເຮັດມັນອັດຕະໂນມັດ, ແລະບໍ່ຢຸດ.

ນຳໃຊ້

ແມ່ນແລ້ວ, ພວກເຮົາເປັນແຟນຂອງ Gitlab & Gitlab CI, ພວກເຮົາໃຊ້ມັນ :)
ເມື່ອສັນຍາໃນ Gitlab ກັບ repository ໂຄງການ, Gitlab ເປີດຕົວທໍ່ທີ່ນໍາໃຊ້ສະພາບແວດລ້ອມໃຫມ່.

ຂັ້ນຕອນ:

• build (ສ້າງຮູບພາບ Docker ໃໝ່)
• ການ​ທົດ​ສອບ
• ທໍາ​ຄວາມ​ສະ​ອາດ (ເອົາ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ທົດ​ສອບ​)
• push (ພວກເຮົາສົ່ງໄປທີ່ Docker registry)
• deploy (ພວກເຮົາ deploy ຄໍາຮ້ອງສະຫມັກກັບ Kubernetes ຜ່ານ Helm).

Hurray, ມັນພ້ອມແລ້ວ, ໃຫ້ປະຕິບັດມັນ!
ດີ, ຫຼືຖາມຄໍາຖາມຖ້າມີ.

ດັ່ງນັ້ນພວກເຮົາໄດ້ເຮັດຫຍັງ

ຈາກທັດສະນະດ້ານວິຊາການ:

• dockerized Bitrix;
• "ຕັດ" Bitrix ເຂົ້າໄປໃນຖັງ, ແຕ່ລະປະຕິບັດຫນ້າຕໍາ່ສຸດທີ່;
• ບັນ​ລຸ​ໄດ້​ລັດ​ບໍ່​ມີ​ລັດ​ຂອງ​ພາ​ຊະ​ນະ​;
• ແກ້ໄຂບັນຫາດ້ວຍການອັບເດດ Bitrix ໃນ Kubernetes;
• ຫນ້າທີ່ Bitrix ທັງຫມົດຍັງສືບຕໍ່ເຮັດວຽກ (ເກືອບທັງຫມົດ);
• ພວກ​ເຮົາ​ໄດ້​ເຮັດ​ວຽກ​ກ່ຽວ​ກັບ​ການ​ນໍາ​ໃຊ້​ກັບ Kubernetes ແລະ rollback ລະ​ຫວ່າງ​ສະ​ບັບ​.

ຈາກທັດສະນະທຸລະກິດ:

• ຄວາມ​ທົນ​ທານ​ຄວາມ​ຜິດ​;
• ເຄື່ອງມື Kubernetes (ການເຊື່ອມໂຍງງ່າຍກັບ Gitlab CI, ການໃຊ້ seamless, ແລະອື່ນໆ);
• ລະ​ຫັດ​ຜ່ານ​ລັບ (ເບິ່ງ​ເຫັນ​ພຽງ​ແຕ່​ຜູ້​ທີ່​ໄດ້​ຮັບ​ການ​ເຂົ້າ​ເຖິງ​ລະ​ຫັດ​ຜ່ານ​ໂດຍ​ກົງ​)​;
• ມັນສະດວກໃນການສ້າງສະພາບແວດລ້ອມເພີ່ມເຕີມ (ສໍາລັບການພັດທະນາ, ການທົດສອບ, ແລະອື່ນໆ) ພາຍໃນໂຄງສ້າງພື້ນຖານດຽວ.

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