ساوثبريدج في تشيليابينسك وبيتريكس في كوبرنيتيس

تُعقد اجتماعات مسؤول نظام Sysadminka في تشيليابينسك، وفي الاجتماع الأخير قدمت تقريرًا عن الحل الذي نقدمه لتشغيل التطبيقات على 1C-Bitrix في Kubernetes.

Bitrix وKubernetes وCeph - مزيج رائع؟

سأخبرك كيف قمنا بتجميع حل عملي من كل هذا.

دعونا نذهب!

تم اللقاء في 18 أبريل في تشيليابينسك. يمكنك أن تقرأ عن لقاءاتنا في لوحة الوقت وانظر موقع YouTube.

إذا كنت تريد أن تأتي إلينا بتقرير أو كمستمع - مرحبًا بك، فاكتب إلينا [البريد الإلكتروني محمي] وعلى برقية t.me/vadimisakanov.

تقريري

الشرائح

الحل "Bitrix في Kubernetes، الإصدار Southbridge 1.0"

سأتحدث عن الحل الذي توصلنا إليه بتنسيق "للدمى في Kubernetes"، كما حدث في الاجتماع. لكنني أفترض أنك تعرف الكلمات Bitrix وDocker وKubernetes وCeph على الأقل على مستوى المقالات على ويكيبيديا.

ما هو الشيء الجاهز حول Bitrix في Kubernetes؟

هناك القليل جدًا من المعلومات على الإنترنت حول تشغيل تطبيقات Bitrix في Kubernetes.
لم أجد سوى هذه المواد:

تقرير بقلم ألكسندر سيربول، و1C-Bitrix، وأنتون توزلوكوف من Qsoft:

أوصي بالاستماع إليها.

تطوير الحل الخاص بك من المستخدم serkyron على حبري.
وجدت المزيد مثل هذا القرار.

Aaand... في الواقع، هذا كل شيء.

أحذرك أننا لم نتحقق من جودة الحلول في الروابط أعلاه :)
بالمناسبة، عند إعداد حلنا، تحدثت مع ألكسندر سيربول، ثم لم يظهر تقريره بعد، لذلك يوجد في الشرائح الخاصة بي عنصر "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 "افتراضيًا" العمل مع هذا، ويجب أن تكون الحاويات عديمة الحالة.

السبب: تقوم كل حاوية (جراب) في المجموعة بمعالجة جزء فقط من حركة المرور. إذا قمت بتغيير الكود في حاوية واحدة فقط (pod)، فسيكون الكود مختلفًا في البودات المختلفة، وسيعمل الموقع بشكل مختلف، وسيتم عرض إصدارات مختلفة من الموقع لمستخدمين مختلفين. لا يمكنك العيش هكذا.

ثالثًا - تحتاج إلى حل مشكلة النشر

إذا كان لدينا خادم متراص وخادم "كلاسيكي" واحد، فكل شيء بسيط للغاية: نقوم بنشر قاعدة تعليمات برمجية جديدة، وترحيل قاعدة البيانات، وتحويل حركة المرور إلى الإصدار الجديد من التعليمات البرمجية. يحدث التبديل على الفور.
إذا كان لدينا موقع في Kubernetes، مقسم إلى خدمات صغيرة، فهناك الكثير من الحاويات التي تحتوي على رمز - أوه. تحتاج إلى جمع الحاويات بإصدار جديد من التعليمات البرمجية، وطرحها بدلاً من القديمة، وترحيل قاعدة البيانات بشكل صحيح، ومن الأفضل القيام بذلك دون أن يلاحظها أحد من قبل الزوار. لحسن الحظ، يساعدنا Kubernetes في ذلك، حيث يدعم مجموعة كاملة من أنواع عمليات النشر المختلفة.

رابعا - تحتاج إلى حل مشكلة تخزين الإحصائيات

إذا كان حجم موقعك "فقط" 10 غيغابايت وقمت بنشره بالكامل في حاويات، فسوف ينتهي بك الأمر بحاويات سعة 10 غيغابايت والتي تستغرق وقتًا طويلاً للنشر.
تحتاج إلى تخزين الأجزاء "الأثقل" من الموقع خارج الحاويات، ويطرح السؤال حول كيفية القيام بذلك بشكل صحيح

ما الذي ينقصنا من الحل؟

لا يتم تقسيم كود Bitrix بالكامل إلى وظائف صغيرة/خدمات صغيرة (بحيث يكون التسجيل منفصلاً، ووحدة المتجر عبر الإنترنت منفصلة، ​​وما إلى ذلك). نقوم بتخزين قاعدة التعليمات البرمجية بأكملها في كل حاوية.

نحن أيضًا لا نقوم بتخزين قاعدة البيانات في Kubernetes (ما زلت أقوم بتنفيذ حلول مع قاعدة بيانات في Kubernetes لبيئات التطوير، ولكن ليس للإنتاج).

سيظل من الملاحظ لمسؤولي الموقع أن الموقع يعمل على Kubernetes. وظيفة "فحص النظام" لا تعمل بشكل صحيح؛ لتحرير رمز الموقع من لوحة الإدارة، يجب عليك أولاً النقر فوق الزر "أريد تحرير الرمز".

تم تحديد المشكلات، وتم تحديد الحاجة إلى تنفيذ الخدمات الصغيرة، والهدف واضح - الحصول على نظام عمل لتشغيل التطبيقات على Bitrix في Kubernetes، مع الحفاظ على إمكانيات Bitrix ومزايا Kubernetes. لنبدأ بالتنفيذ.

هندسة معمارية

هناك العديد من القرون "العاملة" مع خادم الويب (العمال).
واحدة تحت مهام cron (مطلوب واحدة فقط).
ترقية واحدة لتحرير رمز الموقع من لوحة الإدارة (يلزم أيضًا ترقية واحدة فقط).

نحن نحل الأسئلة:

• أين يتم تخزين الجلسات؟
• أين يتم تخزين ذاكرة التخزين المؤقت؟
• أين يتم تخزين الإحصائيات، وليس وضع غيغابايت من الإحصائيات في مجموعة من الحاويات؟
• كيف ستعمل قاعدة البيانات؟

صورة عامل الميناء

نبدأ ببناء صورة Docker.

الخيار المثالي هو أن يكون لدينا صورة عالمية واحدة، وعلى أساسها نحصل على كبسولات عاملة، وكبسولات مع Crontasks، وكبسولات ترقية.

لقد صنعنا مثل هذه الصورة.

يتضمن nginx، وApache/php-fpm (يمكن تحديده أثناء الإنشاء)، وmsmtp لإرسال البريد، وcron.

عند تجميع الصورة، يتم نسخ قاعدة التعليمات البرمجية الكاملة للموقع إلى الدليل /app (باستثناء تلك الأجزاء التي سننقلها إلى وحدة تخزين مشتركة منفصلة).

الخدمات المصغرة، الخدمات

حاضنات العمال:

• حاوية مع nginx + حاوية apache/php-fpm + msmtp
• لم ينجح نقل msmtp إلى خدمة صغيرة منفصلة، ​​بدأت Bitrix تشعر بالسخط لأنها لا تستطيع إرسال البريد مباشرة
• تحتوي كل حاوية على قاعدة بيانات كاملة.
• حظر تغيير التعليمات البرمجية في الحاويات.

كرون تحت:

• حاوية مع اباتشي، PHP، كرون
• تم تضمين قاعدة التعليمات البرمجية الكاملة
• حظر تغيير التعليمات البرمجية في الحاويات

الترقية تحت:

• حاوية 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/.
يتيح لك هذا استخدام نفس الكود في بيئات التطوير والمرحلة والاختبار والإنتاج (ستكون أسماء المضيفين المخزنة مؤقتًا مختلفة، لذلك نحتاج إلى تمرير اسم مضيف فريد للجلسات إلى كل بيئة).
تخزين ذاكرة التخزين المؤقت 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 في بيئة مطابقة لبيئة المطورين (docker)
• لا تحتاج Crontasks إلى "إعادة كتابتها" لـ Kubernetes، فهي تعمل بنفس الشكل وبنفس قاعدة التعليمات البرمجية كما كانت من قبل
• يمكن إضافة مهام cron بواسطة جميع أعضاء الفريق الذين لديهم حقوق الالتزام إلى فرع الإنتاج، وليس فقط المسؤولين

Southbridge K8SDنشر الوحدة وتحرير التعليمات البرمجية من لوحة الإدارة

كنا نتحدث عن الترقية تحت؟
كيفية توجيه حركة المرور هناك؟
مرحا، لقد كتبنا وحدة لهذا في PHP :) هذه وحدة كلاسيكية صغيرة لـ Bitrix. إنه ليس متاحًا للعامة بعد، ولكننا نخطط لفتحه.
يتم تثبيت الوحدة مثل الوحدة النمطية العادية في Bitrix:

ويبدو مثل هذا:

فهو يسمح لك بتعيين ملف تعريف ارتباط يحدد مسؤول الموقع ويسمح لـ Kubernetes بإرسال حركة المرور إلى حجرة الترقية.

عند اكتمال التغييرات، تحتاج إلى النقر فوق git Push، وسيتم إرسال تغييرات التعليمات البرمجية إلى git، ثم سيقوم النظام بإنشاء صورة بإصدار جديد من التعليمات البرمجية و"طرحها" عبر المجموعة، لتحل محل القرون القديمة .

نعم، إنه أمر صعب بعض الشيء، ولكن في الوقت نفسه نحافظ على بنية الخدمات الصغيرة ولا نحرم مستخدمي Bitrix من فرصتهم المفضلة لتصحيح الكود من لوحة الإدارة. في النهاية هذا خيار، يمكنك حل مشكلة تحرير الكود بطريقة مختلفة.

مخطط الخوذة

لإنشاء تطبيقات على Kubernetes، نستخدم عادةً مدير الحزم Helm.
بالنسبة لحل Bitrix الخاص بنا في Kubernetes، قام سيرجي بونداريف، مسؤول النظام الرائد لدينا، بكتابة مخطط Helm خاص.

فهو يبني العمال، والترقية، والقرون cron، ويقوم بتكوين المداخل، والخدمات، وينقل المتغيرات من أسرار Kubernetes إلى القرون.

نقوم بتخزين الكود في Gitlab، ونقوم أيضًا بتشغيل إصدار Helm من Gitlab.

باختصار، يبدو الأمر هكذا

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

يسمح لك Helm أيضًا بإجراء تراجع "سلس" في حالة حدوث خطأ ما فجأة أثناء النشر. من الجيد عندما لا تكون في حالة من الذعر "إصلاح الكود عبر بروتوكول نقل الملفات لأن المنتج قد سقط"، ولكن Kubernetes يفعل ذلك تلقائيًا، ودون توقف.

نشر

نعم، نحن معجبون بـ Gitlab & Gitlab CI، ونحن نستخدمه :)
عند الالتزام بمستودع المشروع في Gitlab، يطلق Gitlab مسارًا ينشر إصدارًا جديدًا من البيئة.

مراحل:

• بناء (إنشاء صورة Docker جديدة)
• اختبار (اختبار)
• التنظيف (إزالة بيئة الاختبار)
• ادفع (نرسله إلى سجل Docker)
• النشر (ننشر التطبيق على Kubernetes عبر Helm).

يا هلا، إنه جاهز، فلننفذه!
حسنا، أو طرح الأسئلة إذا كان هناك أي.

إذا، مالذي فعلناه

من الناحية الفنية:

• إرساء Bitrix ؛
• "تقطيع" Bitrix إلى حاويات، تؤدي كل منها الحد الأدنى من الوظائف؛
• تحقيق حالة عديمة الجنسية للحاويات؛
• حل مشكلة تحديث Bitrix في Kubernetes؛
• استمرت جميع وظائف Bitrix في العمل (جميعها تقريبًا)؛
• لقد عملنا على النشر في Kubernetes والتراجع بين الإصدارات.

من وجهة نظر تجارية:

• التسامح مع الخطأ؛
• أدوات Kubernetes (سهولة التكامل مع Gitlab CI، والنشر السلس، وما إلى ذلك)؛
• تظل كلمات المرور سرية (مرئية فقط لأولئك الذين تم منحهم حق الوصول المباشر إلى كلمات المرور)؛
• من الملائم إنشاء بيئات إضافية (للتطوير والاختبارات وما إلى ذلك) ضمن بنية تحتية واحدة.

المصدر: www.habr.com