يجتمع مسؤولو النظام في Sysadminka في تشيليابينسك ، وفي آخر الأمر ، قمت بتقديم تقرير عن حلنا لتطبيقات العمل على 1C-Bitrix في Kubernetes.
Bitrix ، Kubernetes ، Ceph - مزيج رائع؟
سوف أخبرك كيف وضعنا حلاً عاملاً من كل هذا.
دعنا نذهب!
تم عقد Mitap في 18 أبريل في تشيليابينسك. يمكنك أن تقرأ عن إجراءاتنا في Timepad ومشاهدتها على YouTube .
إذا كنت تريد أن تأتي إلينا مع تقرير أو كمستمع - إلى Wellcome ، فاكتب إلى vadim.isakanov@gmail.com و Telegram t.me/vadimisakanov.
تقريري
عرض الشرائح
Bitrix في Kubernetes ساوثبريدج 1.0 الحل
سوف أتحدث عن حلنا في شكل "لالدمى في Kubernetes" ، كما تم في الاجتماع. لكنني أفترض أن الكلمات Bitrix و Docker و Kubernetes و Ceph معروفة لك على الأقل في مستوى مقالات ويكيبيديا.
ماذا لديك عن Bitrix في Kubernetes؟
في جميع أنحاء الإنترنت ، هناك القليل جدًا من المعلومات حول تشغيل التطبيقات على Bitrix في Kubernetes.
لقد وجدت فقط هذه المواد:
تقرير ألكساندر سيربول ، 1C- بيتريكس ، وأنتون توزلوكوف من Qsoft:
أوصي الاستماع إليها.
تطوير الحل الخاص من المستخدم serkyron على Habré .
لقد وجدت أيضا مثل هذا الحل .
ثالثا ... في الواقع.
أحذرك ، لم نتحقق من جودة الحلول باستخدام الروابط أعلاه :-)
بالمناسبة ، عند إعداد حلنا ، تحدثت مع ألكسندر سربول ، ثم لم يكن تقريره بعد ، لذلك في الشرائح الخاصة بي هناك البند "Bitrix لا يستخدم Kubernetes".
ولكن يوجد بالفعل الكثير من صور Docker الجاهزة لـ Bitrix للعمل في Docker: https://hub.docker.com/search؟q=bitrix&type=image
هل هذا يكفي لإنشاء حل Bitrix كامل في Kubernetes؟
لا. هناك عدد كبير من المشاكل التي تحتاج إلى معالجة.
ما هي مشاكل Bitrix في Kubernetes؟
أولاً - صور Dockerhub الجاهزة غير مناسبة لـ Kubernetes
إذا كنا نرغب في إنشاء بنية خدمات microservice (وفي Kubernetes التي نريدها عادة) ، فيجب تقسيم التطبيق في Kubernetes إلى حاويات والتأكد من أن كل حاوية تؤدي وظيفة واحدة صغيرة (وتؤدي وظيفتها بشكل جيد). لماذا واحد فقط؟ باختصار - أبسط وأكثر موثوقية.
إذا كان أكثر أصالةً ، فراجع هذه المقالة ومقاطع الفيديو ، يرجى: https://habr.com/en/company/southbridge/blog/426637/
صور Docker الموجودة في Dockerhub مبنية بشكل أساسي على مبدأ "الكل في واحد" ، لذلك لا يزال يتعين علينا صنع دراجتنا الخاصة بل وجعل الصور من نقطة الصفر.
ثانياً - يتم تحرير رمز الموقع من لوحة الإدارة
لقد أنشأنا قسمًا جديدًا على الموقع - تم تحديث الرمز (تم إضافة دليل باسم القسم الجديد).
تم تغيير خصائص المكون من لوحة الادارة - تم تغيير الكود.
Kubernetes "بشكل افتراضي" لا يعرف كيفية التعامل مع هذا ، يجب أن تكون الحاويات بدون جنسية.
السبب: كل حاوية (فرعية) في الكتلة تعالج جزءًا فقط من حركة المرور. إذا قمت بتغيير الرمز في حاوية واحدة فقط (أسفل) ، فسيكون الرمز مختلفًا في حافظات مختلفة ، وسيعمل الموقع بشكل مختلف ، وسيتم عرض إصدارات مختلفة من الموقع لمستخدمين مختلفين. لا يمكنك العيش هكذا.
ثالثا - تحتاج إلى حل مسألة النشر
إذا كان لدينا خادم متراصة وخادم "كلاسيكي" ، فكل شيء بسيط للغاية: ننشر قاعدة كود جديدة ، وننقل قاعدة البيانات ، ونحول الحركة إلى الإصدار الجديد من الكود. التبديل يحدث على الفور.
إذا كان لدينا موقع على شبكة الإنترنت في Kubernetes ، فإنه يتم نشره في خدمات micros ، وهناك العديد من الحاويات التي تحتوي على الكود. من الضروري جمع الحاويات مع الإصدار الجديد من الكود ، وطرحها بدلاً من القديمة ، وتنفيذ عملية ترحيل قاعدة البيانات بشكل صحيح ، والقيام بهذا الأمر دون أن يلاحظه أحد الزوار. لحسن الحظ ، Kubernetes يساعدنا في هذا ، ودعم سحابة كاملة من أنواع مختلفة من النشر.
الرابعة - تحتاج إلى حل مشكلة تخزين ثابت
إذا كان موقعك يزن 10 غيغابايت "فقط" وقمت بنشره بالكامل في حاويات ، فستحصل على حاويات يصل وزنها إلى 10 غيغابايت ، والتي سيتم نشرها إلى الأبد.
تحتاج إلى تخزين أكثر الأجزاء "الثقيلة" في الموقع خارج الحاويات ، والسؤال الذي يطرح نفسه هو كيفية القيام بذلك بشكل صحيح
ما ليس في قرارنا
لا يتم قص رمز Bitrix بالكامل للوظيفة المصغرة / الخدمات المصغرة (بحيث يكون التسجيل منفصلًا ، ووحدة المتجر على الإنترنت منفصلة ، وما إلى ذلك). نقوم بتخزين قاعدة الشفرة بأكملها في كل حاوية ككل.
نحن أيضًا لا نخزن الأساس في Kubernetes (مع ذلك ، قمت بتنفيذ حلول مع القاعدة في Kubernetes لبيئات المطورين ، ولكن ليس للإنتاج).
سيظل مسؤولو الموقع يلاحظون أن الموقع يعمل في Kubernetes. وظيفة "فحص النظام" لا تعمل بشكل صحيح ، لتحرير رمز الموقع من لوحة المسؤول ، يجب أولاً النقر فوق الزر "أريد تحرير الرمز".
قررنا المشكلات ، قررنا الحاجة إلى تنفيذ خدمات microservice ، والهدف واضح - الحصول على نظام عمل للعمل على تطبيقات Bitrix في Kubernetes ، مع الحفاظ على قدرات Bitrix ومزايا Kubernetes. نبدأ التنفيذ.
هندسة معمارية
الكثير من قلوب "العمل" مع خادم الويب (العمال).
واحد تحت مع التيجان تاج (بالضرورة واحد فقط).
ترقية واحدة لتحرير رمز الموقع من لوحة المسؤول (مطلوب واحد فقط أيضًا).
نحن نحل القضايا:
- حيث لتخزين الدورات؟
- حيث لتخزين ذاكرة التخزين المؤقت؟
- حيث لتخزين احصائيات ، وليس لوضع غيغا بايت من احصائيات في كومة من الحاويات؟
- كيف ستعمل قاعدة البيانات؟
صورة عامل الميناء
نبدأ من خلال بناء صورة عامل الميناء.
الخيار المثالي هو أن لدينا صورة عالمية واحدة ، على أساسها ، نحصل على كل من قرون العمال ، وأقراص مدمجة مع أقواس ، ونقوم بتحديث القرون.
لقد صنعنا مثل هذه الصورة .
ويشمل nginx ، apache / php-fpm (يمكن تحديده أثناء التجميع) ، msmtp لإرسال البريد ، و cron.
عند تجميع الصورة ، يتم نسخ قاعدة الشفرة الكاملة للموقع إلى دليل / التطبيق (باستثناء الأجزاء التي سنضعها في وحدة تخزين مشتركة منفصلة).
خدمات Microservice
الموقد العامل:
- حاوية مع حاوية nginx + apache / php-fpm + msmtp
- لم تنجح msmtp في خدمة microservice منفصلة ، يبدأ Bitrix بالاستياء لأنه لا يمكنه إرسال البريد مباشرة
- كل حاوية لديها قاعدة رمز كاملة.
- فرض حظر على تغيير الرمز في الحاويات.
كرون تحت:
- حاوية مع اباتشي ، فب ، كرون
- قاعدة رمز كاملة المدرجة
- فرض حظر على تغيير الرمز في الحاويات
ترقية تحت:
- الحاوية مع 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
استخدمنا متغيرات البيئة لنقل بيانات المضيف باستخدام https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/ .
يسمح لك هذا باستخدام نفس الكود في بيئات تطوير ، مرحلة ، اختبار ، prod (ستكون أسماء مضيف memcached فيها مختلفة ، لذلك نحن بحاجة إلى نقل اسم مضيف فريد للجلسات إلى كل بيئة).
التخزين المؤقت ل Bitrix
نحتاج إلى تخزين آمن من الفشل يمكن أن تكتب فيه جميع الموقد ويمكننا أن نقرأ منه.
ونحن نستخدم أيضا memcached.
ينصح هذا الحل من قبل Bitrix أنفسهم.
$ helm install stable/memcached --name cache
bitrix / .settings_extra.php - هنا في Bitrix يتم تعيينه حيث نقوم بتخزين ذاكرة التخزين المؤقت
نستخدم أيضًا متغيرات البيئة.
Krontaski
هناك طرق مختلفة لعمل كرونتاب في Kubernetes.
- نشر منفصلة مع الموقد
- cronjob لأداء crontask (إذا كان تطبيقًا على الويب - باستخدام https: // $ host $ cronjobname أو kubectl exec داخل أحد مداخل العاملين ، إلخ)
- إلخ
يمكنك الجدال حول الأكثر صحة ، ولكن في هذه الحالة ، اخترنا الخيار "نشر منفصل مع قرون ل crontask"
كيف تفعل ذلك:
- إضافة التيجان من خلال ConfigMap أو عبر config / addcron
- في حالة واحدة ، قم بتشغيل حاوية مماثلة للعامل sub + للسماح بتنفيذ مهام التاج فيه
- يتم استخدام نفس قاعدة الشفرة ، وذلك بفضل توحيد تجميع الحاوية بسيط
ما الجيد الذي حصلنا عليه:
- لدينا crontaski العمل في بيئة مماثلة لبيئة التطوير (عامل ميناء)
- لا يحتاج Krontaski إلى "إعادة كتابته" لـ Kubernetes ، فهم يعملون بنفس الشكل وفي نفس قاعدة الشفرة كما كان من قبل
- يمكن لأعضاء التاج إضافة جميع أعضاء الفريق بحقوق الالتزام إلى فرع الإنتاج ، وليس فقط مدراء
وحدة Southbridge K8SDeploy ورمز التحرير من لوحة المشرف
كنا نتحدث عن ترقية تحت؟
وكيفية توجيه حركة المرور هناك؟
الصيحة ، كتبنا وحدة نمطية لهذا في php :) هذه هي وحدة نمطية صغيرة صغيرة ل Bitrix. لم يكن متاحًا للجمهور حتى الآن ، لكننا نخطط لفتحه.
تم تثبيت الوحدة النمطية كوحدة نمطية عادية في Bitrix:
ويبدو مثل هذا:
يسمح لك بتعيين ملف تعريف ارتباط يحدد مسؤول الموقع ويسمح لـ Kubernetes بإرسال حركة المرور للترقية أسفل.
عند اكتمال التغييرات ، ستحتاج إلى الضغط على git push ، وسيتم إرسال تغييرات الكود إلى git ، ثم سيقوم النظام بجمع الصورة بالإصدار الجديد من الكود "ولفها" عبر المجموعة ، لتحل محل القرون القديمة.
نعم ، إنه عكاز قليل ، لكن في نفس الوقت نحافظ على بنية الخدمات المصغرة ولا نأخذ من مستخدمي Bitrix فرصة مفضلة لتصحيح الشفرة من لوحة المشرف. في النهاية ، هذا خيار ، يمكنك حل مشكلة تحرير الكود بطريقة مختلفة.
مخطط هيلم
لبناء تطبيقات في Kubernetes ، نستخدم عادة مدير حزمة Helm.
من أجل حل Bitrix في Kubernetes ، كتب سيرجي بونداريف ، مسؤول نظامنا الرئيسي ، مخطط هيلم الخاص.
يبني العامل ، ugrade ، الموقد كرون ، تكوين تكوينات ، والخدمات ، ونقل المتغيرات من أسرار 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)
- نشر (نقوم بنشر التطبيق في Kubernetes عبر هيلم).
يا هلا ، نحن مستعدون لتقديمها!
حسنا ، أو طرح الأسئلة ، إن وجدت.
إذن ما الذي فعلناه؟
من الناحية الفنية:
- Bitrix مرسو.
- "قطع" Bitrix في حاويات ، كل منها يؤدي الحد الأدنى من الوظائف ؛
- تحقيق حالة عديمي الجنسية من الحاويات.
- حل مشكلة تحديث Bitrix في Kubernetes ؛
- واصلت جميع وظائف Bitrix العمل (كلها تقريبا) ؛
- عملت النشر في Kubernetes والتراجع بين الإصدارات.
من منظور العمل:
- خطأ التسامح.
- أدوات Kubernetes (التكامل السهل مع Gitlab CI ، النشر السلس ، إلخ) ؛
- كلمات المرور في الأسرار (مرئية فقط لأولئك الذين يتم منحهم حق الوصول المباشر إلى كلمات المرور) ؛
- من المناسب إنشاء بيئات إضافية (للتطوير والاختبارات وما إلى ذلك) داخل بنية أساسية واحدة.