الحل "Bitrix في Kubernetes، الإصدار Southbridge 1.0"
سأتحدث عن الحل الذي توصلنا إليه بتنسيق "للدمى في Kubernetes"، كما حدث في الاجتماع. لكنني أفترض أنك تعرف الكلمات Bitrix وDocker وKubernetes وCeph على الأقل على مستوى المقالات على ويكيبيديا.
ما هو الشيء الجاهز حول Bitrix في Kubernetes؟
هناك القليل جدًا من المعلومات على الإنترنت حول تشغيل تطبيقات Bitrix في Kubernetes.
لم أجد سوى هذه المواد:
تقرير بقلم ألكسندر سيربول، و1C-Bitrix، وأنتون توزلوكوف من Qsoft:
أحذرك أننا لم نتحقق من جودة الحلول في الروابط أعلاه :)
بالمناسبة، عند إعداد حلنا، تحدثت مع ألكسندر سيربول، ثم لم يظهر تقريره بعد، لذلك يوجد في الشرائح الخاصة بي عنصر "Bitrix لا يستخدم Kubernetes".
هل هذا كافٍ لإنشاء حل كامل لـ 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، وكبسولات ترقية.
عند تجميع الصورة، يتم نسخ قاعدة التعليمات البرمجية الكاملة للموقع إلى الدليل /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.
هذا الحل موصى به بواسطة 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 أيضًا بإجراء تراجع "سلس" في حالة حدوث خطأ ما فجأة أثناء النشر. من الجيد عندما لا تكون في حالة من الذعر "إصلاح الكود عبر بروتوكول نقل الملفات لأن المنتج قد سقط"، ولكن Kubernetes يفعل ذلك تلقائيًا، ودون توقف.
نشر
نعم، نحن معجبون بـ Gitlab & Gitlab CI، ونحن نستخدمه :)
عند الالتزام بمستودع المشروع في Gitlab، يطلق Gitlab مسارًا ينشر إصدارًا جديدًا من البيئة.
مراحل:
بناء (إنشاء صورة Docker جديدة)
اختبار (اختبار)
التنظيف (إزالة بيئة الاختبار)
ادفع (نرسله إلى سجل Docker)
النشر (ننشر التطبيق على Kubernetes عبر Helm).
يا هلا، إنه جاهز، فلننفذه!
حسنا، أو طرح الأسئلة إذا كان هناك أي.
إذا، مالذي فعلناه
من الناحية الفنية:
إرساء Bitrix ؛
"تقطيع" Bitrix إلى حاويات، تؤدي كل منها الحد الأدنى من الوظائف؛
تحقيق حالة عديمة الجنسية للحاويات؛
حل مشكلة تحديث Bitrix في Kubernetes؛
استمرت جميع وظائف Bitrix في العمل (جميعها تقريبًا)؛
لقد عملنا على النشر في Kubernetes والتراجع بين الإصدارات.
من وجهة نظر تجارية:
التسامح مع الخطأ؛
أدوات Kubernetes (سهولة التكامل مع Gitlab CI، والنشر السلس، وما إلى ذلك)؛
تظل كلمات المرور سرية (مرئية فقط لأولئك الذين تم منحهم حق الوصول المباشر إلى كلمات المرور)؛
من الملائم إنشاء بيئات إضافية (للتطوير والاختبارات وما إلى ذلك) ضمن بنية تحتية واحدة.