โปรโฮสต์ > บล็อก > การบริหาร > Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

การพบปะผู้ดูแลระบบ Sysadminka จัดขึ้นที่ Chelyabinsk และล่าสุดฉันได้ให้รายงานเกี่ยวกับโซลูชันของเราสำหรับการรันแอปพลิเคชันบน 1C-Bitrix ใน Kubernetes

Bitrix, Kubernetes, Ceph - เป็นส่วนผสมที่ยอดเยี่ยมใช่ไหม?

ฉันจะบอกคุณว่าเรารวบรวมวิธีแก้ปัญหาที่ใช้งานได้จากทั้งหมดนี้ได้อย่างไร

Here we go!

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

การพบปะดังกล่าวเกิดขึ้นเมื่อวันที่ 18 เมษายนที่เมืองเชเลียบินสค์ คุณสามารถอ่านเกี่ยวกับการพบปะของเราได้ที่ ไทม์แพด และดู ยูทูบ.

หากคุณต้องการมาหาเราพร้อมรายงานหรือในฐานะผู้ฟัง - ยินดีต้อนรับ เขียนถึงเรา [ป้องกันอีเมล] และทาง Telegram t.me/vadimisakanov

รายงานของฉัน

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

สไลด์

โซลูชัน "Bitrix ใน Kubernetes เวอร์ชัน Southbridge 1.0"

ฉันจะพูดถึงโซลูชันของเราในรูปแบบ "สำหรับหุ่นจำลองใน Kubernetes" เช่นเดียวกับที่ทำไปแล้วที่งานมีตติ้ง แต่ฉันคิดว่าคุณคงรู้จักคำว่า Bitrix, Docker, Kubernetes, Ceph อย่างน้อยก็ในระดับบทความใน Wikipedia

Bitrix ใน Kubernetes มีอะไรบ้างที่พร้อมทำ?

มีข้อมูลน้อยมากบนอินเทอร์เน็ตทั้งหมดเกี่ยวกับการทำงานของแอปพลิเคชัน Bitrix ใน Kubernetes
ฉันพบเฉพาะวัสดุเหล่านี้:

รายงานโดย Alexander Serbul, 1C-Bitrix และ Anton Tuzlukov จาก Qsoft:

ฉันแนะนำให้ฟังมัน

การพัฒนาโซลูชันของคุณเองจากผู้ใช้ เซอร์ไครอน บนHabré.
พบมากขึ้น การตัดสินใจดังกล่าว.

อ่า...จริงๆแล้วก็แค่นั้นแหละ

ฉันขอเตือนคุณ เรายังไม่ได้ตรวจสอบคุณภาพของโซลูชันในลิงก์ด้านบน :)
อย่างไรก็ตาม เมื่อเตรียมโซลูชัน ฉันได้พูดคุยกับ Alexander Serbul แล้วรายงานของเขายังไม่ปรากฏ ดังนั้นในสไลด์ของฉันจึงมีรายการ "Bitrix ไม่ได้ใช้ Kubernetes"

แต่มีอิมเมจ Docker สำเร็จรูปจำนวนมากสำหรับการรัน Bitrix ใน Docker: https://hub.docker.com/search?q=bitrix&type=image

นี่เพียงพอที่จะสร้างโซลูชันที่สมบูรณ์สำหรับ Bitrix ใน Kubernetes หรือไม่
เลขที่ มีปัญหาจำนวนมากที่ต้องแก้ไข

Bitrix ใน Kubernetes มีปัญหาอะไรบ้าง

ประการแรก รูปภาพสำเร็จรูปจาก Dockerhub ไม่เหมาะสำหรับ Kubernetes

หากเราต้องการสร้างสถาปัตยกรรมไมโครเซอร์วิส (และใน Kubernetes เรามักจะสร้าง) เราจำเป็นต้องแยกแอปพลิเคชัน Kubernetes ของเราออกเป็นคอนเทนเนอร์ และให้แต่ละคอนเทนเนอร์ทำหน้าที่เล็กๆ หนึ่งฟังก์ชัน (และทำได้ดี) ทำไมมีเพียงหนึ่งเดียว? กล่าวโดยสรุป ยิ่งง่ายก็ยิ่งเชื่อถือได้มากขึ้น
หากต้องการเจาะจงมากขึ้น โปรดดูบทความและวิดีโอนี้ โปรด: https://habr.com/ru/company/southbridge/blog/426637/

อิมเมจ Docker ใน Dockerhub สร้างขึ้นบนหลักการออลอินวันเป็นหลัก ดังนั้นเราจึงยังคงต้องสร้างรถมอเตอร์ไซค์ของเราเองและแม้แต่สร้างรูปภาพตั้งแต่ต้นด้วยซ้ำ

ประการที่สอง - รหัสไซต์ได้รับการแก้ไขจากแผงผู้ดูแลระบบ

เราได้สร้างส่วนใหม่บนเว็บไซต์ - โค้ดได้รับการอัปเดตแล้ว (มีการเพิ่มไดเร็กทอรีที่มีชื่อของส่วนใหม่)

หากคุณเปลี่ยนคุณสมบัติของส่วนประกอบจากแผงผู้ดูแลระบบ รหัสก็เปลี่ยนไป

Kubernetes "โดยค่าเริ่มต้น" ไม่สามารถทำงานได้ คอนเทนเนอร์จะต้องไม่มีสถานะ

เหตุผล: แต่ละคอนเทนเนอร์ (พ็อด) ในคลัสเตอร์จะประมวลผลการรับส่งข้อมูลเพียงบางส่วนเท่านั้น หากคุณเปลี่ยนโค้ดในคอนเทนเนอร์เดียว (พ็อด) โค้ดจะแตกต่างกันในพ็อดที่ต่างกัน ไซต์จะทำงานแตกต่างกัน และเวอร์ชันต่างๆ ของไซต์จะแสดงต่อผู้ใช้ที่แตกต่างกัน คุณไม่สามารถใช้ชีวิตแบบนั้นได้

ประการที่สาม - คุณต้องแก้ไขปัญหาด้วยการปรับใช้

หากเรามีเซิร์ฟเวอร์ขนาดใหญ่และเซิร์ฟเวอร์ "คลาสสิก" หนึ่งเครื่อง ทุกอย่างจะค่อนข้างง่าย: เราปรับใช้ฐานโค้ดใหม่ ย้ายฐานข้อมูล สลับการรับส่งข้อมูลเป็นโค้ดเวอร์ชันใหม่ การสลับเกิดขึ้นทันที
หากเรามีไซต์ใน Kubernetes ตัดเป็นไมโครเซอร์วิสจะมีคอนเทนเนอร์พร้อมโค้ดมากมาย - โอ้ คุณต้องรวบรวมคอนเทนเนอร์ด้วยโค้ดเวอร์ชันใหม่ นำไปใช้แทนเวอร์ชันเก่า ย้ายฐานข้อมูลอย่างถูกต้อง และทำเช่นนี้โดยที่ผู้เยี่ยมชมจะไม่มีใครสังเกตเห็น โชคดีที่ Kubernetes ช่วยเราในเรื่องนี้ โดยสนับสนุนการปรับใช้ประเภทต่างๆ มากมาย

ประการที่สี่ - คุณต้องแก้ไขปัญหาการจัดเก็บสถิตยศาสตร์

หากไซต์ของคุณมีขนาด “เพียง” 10 กิกะไบต์ และคุณปรับใช้ทั้งหมดในคอนเทนเนอร์ คุณจะพบกับคอนเทนเนอร์ขนาด 10 กิกะไบต์ที่ต้องใช้เวลาตลอดไปในการปรับใช้
คุณต้องจัดเก็บส่วนที่ "หนักที่สุด" ของไซต์ไว้นอกคอนเทนเนอร์ และเกิดคำถามว่าจะต้องทำอย่างไรให้ถูกต้อง

มีอะไรหายไปจากโซลูชันของเรา?

รหัส Bitrix ทั้งหมดไม่ได้แบ่งออกเป็นไมโครฟังก์ชัน/ไมโครเซอร์วิส (เพื่อให้การลงทะเบียนแยกจากกัน โมดูลร้านค้าออนไลน์แยกจากกัน ฯลฯ) เราจัดเก็บฐานโค้ดทั้งหมดไว้ในแต่ละคอนเทนเนอร์

นอกจากนี้เรายังไม่จัดเก็บฐานข้อมูลใน Kubernetes (ฉันยังคงใช้งานโซลูชันกับฐานข้อมูลใน Kubernetes สำหรับสภาพแวดล้อมการพัฒนา แต่ไม่ใช่สำหรับการใช้งานจริง)

ผู้ดูแลระบบไซต์จะยังคงสังเกตเห็นได้ว่าไซต์ทำงานบน Kubernetes ฟังก์ชั่น "การตรวจสอบระบบ" ทำงานไม่ถูกต้อง หากต้องการแก้ไขโค้ดไซต์จากแผงผู้ดูแลระบบ คุณต้องคลิกปุ่ม "ฉันต้องการแก้ไขโค้ด" ก่อน

พบปัญหาแล้ว ความจำเป็นในการใช้ไมโครเซอร์วิสได้รับการกำหนด เป้าหมายชัดเจน - เพื่อรับระบบการทำงานสำหรับการรันแอปพลิเคชันบน Bitrix ใน Kubernetes โดยรักษาทั้งความสามารถของ Bitrix และข้อดีของ Kubernetes มาเริ่มดำเนินการกันเลย

สถาปัตยกรรม

มีพ็อด "ใช้งานได้" มากมายพร้อมเว็บเซิร์ฟเวอร์ (พนักงาน)
หนึ่งรายการภายใต้งาน cron (ต้องมีเพียงรายการเดียวเท่านั้น)
อัปเกรดหนึ่งครั้งสำหรับการแก้ไขโค้ดไซต์จากแผงผู้ดูแลระบบ (จำเป็นต้องมีเพียงอันเดียวเท่านั้น)

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

เราแก้ปัญหา:

  • จะจัดเก็บเซสชั่นได้ที่ไหน?
  • จะเก็บแคชไว้ที่ไหน?
  • จะเก็บสถิตยศาสตร์ได้ที่ไหนไม่ต้องวางสถิตยศาสตร์หลายกิกะไบต์ไว้ในคอนเทนเนอร์จำนวนมาก?
  • ฐานข้อมูลจะทำงานอย่างไร?

ภาพนักเทียบท่า

เราเริ่มต้นด้วยการสร้างอิมเมจนักเทียบท่า

ตัวเลือกที่เหมาะสมที่สุดคือเรามีอิมเมจสากลหนึ่งอิมเมจ โดยพื้นฐานแล้วเราจะได้พ็อดคนงาน พ็อดที่มี Crontasks และอัปเกรดพ็อด

เราสร้างภาพดังกล่าวขึ้นมา.

ประกอบด้วย nginx, apache/php-fpm (สามารถเลือกได้ระหว่างบิลด์), msmtp สำหรับส่งอีเมล และ cron

เมื่อประกอบรูปภาพ โค้ดฐานทั้งหมดของไซต์จะถูกคัดลอกไปยังไดเร็กทอรี /app (ยกเว้นส่วนที่เราจะย้ายไปยังที่เก็บข้อมูลที่ใช้ร่วมกันแยกต่างหาก)

ไมโครเซอร์วิส บริการต่างๆ

ฝักคนงาน:

  • คอนเทนเนอร์ที่มี nginx + คอนเทนเนอร์ apache/php-fpm + msmtp
  • การย้าย msmtp ไปยังไมโครเซอร์วิสแยกต่างหากไม่ได้ผล Bitrix เริ่มไม่พอใจที่ไม่สามารถส่งอีเมลได้โดยตรง
  • แต่ละคอนเทนเนอร์มีโค้ดเบสที่สมบูรณ์
  • ข้อห้ามในการเปลี่ยนรหัสในคอนเทนเนอร์

cron ภายใต้:

  • คอนเทนเนอร์ที่มี apache, php, cron
  • รวมฐานรหัสที่สมบูรณ์
  • ห้ามเปลี่ยนรหัสในคอนเทนเนอร์

อัปเกรดภายใต้:

  • คอนเทนเนอร์ nginx + คอนเทนเนอร์ apache/php-fpm + msmtp
  • ไม่มีข้อห้ามในการเปลี่ยนรหัสในคอนเทนเนอร์

ที่เก็บข้อมูลเซสชัน

พื้นที่เก็บข้อมูลแคช Bitrix

สิ่งสำคัญอีกประการหนึ่ง: เราจัดเก็บรหัสผ่านสำหรับเชื่อมต่อกับทุกสิ่ง ตั้งแต่ฐานข้อมูลไปจนถึงเมล ไว้เป็นความลับของ Kubernetes เราได้รับโบนัส: รหัสผ่านจะปรากฏเฉพาะกับผู้ที่เราให้สิทธิ์เข้าถึงความลับเท่านั้น และไม่ใช่สำหรับทุกคนที่สามารถเข้าถึงฐานโค้ดของโครงการ

ที่เก็บข้อมูลสำหรับสถิตยศาสตร์

คุณสามารถใช้อะไรก็ได้: ceph, nfs (แต่เราไม่แนะนำ nfs สำหรับการผลิต), ที่เก็บข้อมูลเครือข่ายจากผู้ให้บริการคลาวด์ ฯลฯ

พื้นที่จัดเก็บข้อมูลจะต้องเชื่อมต่อในคอนเทนเนอร์กับไดเร็กทอรี /upload/ ของไซต์และไดเร็กทอรีอื่น ๆ ที่มีเนื้อหาคงที่

ฐานข้อมูล

เพื่อความง่าย เราขอแนะนำให้ย้ายฐานข้อมูลไปนอก Kubernetes ฐานใน Kubernetes เป็นงานที่ซับซ้อนแยกต่างหาก โดยจะทำให้โครงร่างมีลำดับความสำคัญที่ซับซ้อนมากขึ้น

ที่เก็บข้อมูลเซสชัน

เราใช้ memcached :)

จัดการพื้นที่จัดเก็บข้อมูลเซสชันได้ดี มีการรวมกลุ่ม และได้รับการสนับสนุน "ดั้งเดิม" เป็น session.save_path ใน php ระบบดังกล่าวได้รับการทดสอบหลายครั้งในสถาปัตยกรรมเสาหินคลาสสิก เมื่อเราสร้างคลัสเตอร์ที่มีเว็บเซิร์ฟเวอร์จำนวนมาก สำหรับการปรับใช้เราใช้หางเสือ

$ helm install stable/memcached --name session

php.ini - รูปภาพประกอบด้วยการตั้งค่าสำหรับจัดเก็บเซสชันใน memcached

เราใช้ตัวแปรสภาพแวดล้อมเพื่อส่งข้อมูลเกี่ยวกับโฮสต์ที่มี memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
ซึ่งจะทำให้คุณสามารถใช้โค้ดเดียวกันในสภาพแวดล้อม dev, stage, test, prod (ชื่อโฮสต์ memcached จะแตกต่างกัน ดังนั้นเราจึงจำเป็นต้องส่งชื่อโฮสต์ที่ไม่ซ้ำกันสำหรับเซสชันไปยังแต่ละสภาพแวดล้อม)
พื้นที่เก็บข้อมูลแคช Bitrix

เราต้องการพื้นที่เก็บข้อมูลที่ทนทานต่อข้อผิดพลาดซึ่งพ็อดทั้งหมดสามารถเขียนและอ่านได้

เรายังใช้ memcached
Bitrix แนะนำวิธีแก้ปัญหานี้เอง

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - ใน Bitrix จะมีการระบุตำแหน่งที่เก็บแคช

เรายังใช้ตัวแปรสภาพแวดล้อม

ครอนทาสกี

มีแนวทางที่แตกต่างกันในการรัน Crontasks ใน Kubernetes

  • การปรับใช้แยกต่างหากพร้อมพ็อดสำหรับการรัน Crontasks
  • cronjob สำหรับการดำเนินการ crontasks (หากนี่คือเว็บแอป - ด้วย wget https://$host$cronjobnameหรือ kubectl exec ภายในพ็อดผู้ปฏิบัติงานอันใดอันหนึ่ง ฯลฯ )
  • เป็นต้น

คุณสามารถโต้แย้งเกี่ยวกับสิ่งที่ถูกต้องที่สุดได้ แต่ในกรณีนี้ เราเลือกตัวเลือก “แยกการใช้งานด้วยพ็อดสำหรับ Crontasks”

ทำอย่างไร:

  • เพิ่มงาน cron ผ่าน ConfigMap หรือผ่านไฟล์ config/addcron
  • ในกรณีหนึ่ง เราเปิดตัวคอนเทนเนอร์ที่เหมือนกับพ็อดผู้ปฏิบัติงาน + อนุญาตให้ดำเนินงานคราวน์ในนั้นได้
  • ใช้โค้ดฐานเดียวกัน เนื่องจากการรวมเข้าด้วยกัน การประกอบคอนเทนเนอร์จึงเป็นเรื่องง่าย

เราได้อะไรดี:

  • เรามีการทำงาน Crontasks ในสภาพแวดล้อมที่เหมือนกับสภาพแวดล้อมของนักพัฒนา (นักเทียบท่า)
  • Crontasks ไม่จำเป็นต้อง "เขียนใหม่" สำหรับ Kubernetes แต่ทำงานในรูปแบบเดียวกันและอยู่ในฐานโค้ดเดียวกันกับเมื่อก่อน
  • สมาชิกในทีมทุกคนที่มีสิทธิ์คอมมิตในสาขาการผลิตสามารถเพิ่มงาน cron ได้ ไม่ใช่แค่ผู้ดูแลระบบ

โมดูล Southbridge K8SDeploy และการแก้ไขโค้ดจากแผงผู้ดูแลระบบ

เรากำลังพูดถึงการอัพเกรดภายใต้?
จะนำการจราจรไปที่นั่นได้อย่างไร?
ไชโย เราเขียนโมดูลสำหรับสิ่งนี้ใน PHP :) นี่เป็นโมดูลคลาสสิกขนาดเล็กสำหรับ Bitrix ยังไม่เปิดเผยต่อสาธารณะ แต่เราวางแผนที่จะเปิด
โมดูลได้รับการติดตั้งเหมือนกับโมดูลทั่วไปใน Bitrix:

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

และดูเหมือนว่านี้:

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

ช่วยให้คุณสามารถตั้งค่าคุกกี้ที่ระบุผู้ดูแลไซต์และอนุญาตให้ Kubernetes ส่งการรับส่งข้อมูลไปยังพ็อดอัปเกรด

เมื่อการเปลี่ยนแปลงเสร็จสมบูรณ์ คุณต้องคลิก git push การเปลี่ยนแปลงโค้ดจะถูกส่งไปยัง git จากนั้นระบบจะสร้างอิมเมจด้วยโค้ดเวอร์ชันใหม่และ "เผยแพร่" ทั่วทั้งคลัสเตอร์ โดยแทนที่พ็อดเก่า .

ใช่ มันค่อนข้างยาก แต่ในขณะเดียวกัน เราก็รักษาสถาปัตยกรรมไมโครเซอร์วิส และไม่แย่งชิงโอกาสที่ผู้ใช้ Bitrix ชื่นชอบในการแก้ไขโค้ดจากแผงผู้ดูแลระบบ ท้ายที่สุดแล้ว นี่คือตัวเลือก คุณสามารถแก้ไขปัญหาการแก้ไขโค้ดด้วยวิธีอื่นได้

แผนภูมิหางเสือ

ในการสร้างแอปพลิเคชันบน Kubernetes โดยทั่วไปเราจะใช้ตัวจัดการแพ็คเกจ Helm
สำหรับโซลูชัน Bitrix ของเราใน Kubernetes นั้น Sergey Bondarev ผู้ดูแลระบบชั้นนำของเราได้เขียนแผนภูมิ Helm พิเศษ

สร้างผู้ปฏิบัติงาน อัปเกรด พ็อด cron กำหนดค่าทางเข้า บริการ และโอนตัวแปรจากข้อมูลลับของ Kubernetes ไปยังพ็อด

เราเก็บโค้ดไว้ใน 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 กับที่เก็บโปรเจ็กต์ Gitlab จะเปิดตัวไปป์ไลน์ที่ปรับใช้สภาพแวดล้อมเวอร์ชันใหม่

ขั้นตอน:

  • build (สร้างอิมเมจ Docker ใหม่)
  • ทดสอบ (ทดสอบ)
  • ทำความสะอาด (ลบสภาพแวดล้อมการทดสอบ)
  • พุช (เราส่งไปที่รีจิสทรีนักเทียบท่า)
  • ปรับใช้ (เราปรับใช้แอปพลิเคชันกับ Kubernetes ผ่าน Helm)

Southbridge ใน Chelyabinsk และ Bitrix ใน Kubernetes

ฮูเร่ พร้อมแล้ว ลงมือทำเลย!
หรือถามคำถามถ้ามี

แล้วเราทำอะไร

จากมุมมองทางเทคนิค:

  • Bitrix ที่เชื่อมต่อแล้ว;
  • “ตัด” Bitrix ลงในคอนเทนเนอร์ ซึ่งแต่ละคอนเทนเนอร์ทำหน้าที่ขั้นต่ำสุด
  • บรรลุสภาวะไร้สัญชาติของภาชนะบรรจุ
  • แก้ไขปัญหาด้วยการอัปเดต Bitrix ใน Kubernetes
  • ฟังก์ชั่น Bitrix ทั้งหมดยังคงทำงานต่อไป (เกือบทั้งหมด)
  • เราดำเนินการปรับใช้กับ Kubernetes และการย้อนกลับระหว่างเวอร์ชันต่างๆ

จากมุมมองทางธุรกิจ:

  • ความทนทานต่อความผิดพลาด
  • เครื่องมือ Kubernetes (บูรณาการอย่างง่ายดายกับ Gitlab CI, การใช้งานที่ราบรื่น ฯลฯ );
  • รหัสผ่านลับ (มองเห็นได้เฉพาะผู้ที่ได้รับสิทธิ์เข้าถึงรหัสผ่านโดยตรงเท่านั้น)
  • สะดวกในการสร้างสภาพแวดล้อมเพิ่มเติม (สำหรับการพัฒนา การทดสอบ ฯลฯ) ภายในโครงสร้างพื้นฐานเดียว

ที่มา: will.com

เพิ่มความคิดเห็น