Chelyabinsk میں Southbridge اور Kubernetes میں Bitrix

چیلیابنسک میں سیسڈمینکا سسٹم ایڈمنسٹریٹر میٹنگز ہو رہی ہیں، اور آخر میں میں نے کوبرنیٹس میں 1C-Bitrix پر ایپلی کیشنز چلانے کے اپنے حل کے بارے میں ایک رپورٹ دی۔

Bitrix، Kubernetes، Ceph - ایک عظیم مرکب؟

میں آپ کو بتاؤں گا کہ ہم اس سب سے کام کرنے والے حل کو کیسے اکٹھا کرتے ہیں۔

ہم چلتے ہیں!

یہ ملاقات 18 اپریل کو چیلیابنسک میں ہوئی۔ آپ ہماری ملاقاتوں کے بارے میں پڑھ سکتے ہیں۔ ٹائم پیڈ اور دیکھو یوٹیوب.

اگر آپ ہمارے پاس رپورٹ لے کر آنا چاہتے ہیں یا سننے والے کے طور پر - خوش آمدید، لکھیں۔ [ای میل محفوظ] اور ٹیلیگرام t.me/vadimisakanov پر۔

میری رپورٹ

سلائیڈز

حل "کبرنیٹس میں بٹرکس، ورژن ساؤتھ برج 1.0"

میں اپنے حل کے بارے میں "Kubernetes میں dummies کے لیے" فارمیٹ میں بات کروں گا، جیسا کہ میٹ اپ میں کیا گیا تھا۔ لیکن میں فرض کرتا ہوں کہ آپ Bitrix، Docker، Kubernetes، Ceph الفاظ کو کم از کم ویکیپیڈیا پر مضامین کی سطح پر جانتے ہیں۔

Kubernetes میں Bitrix کے بارے میں کیا تیار ہے؟

Kubernetes میں Bitrix ایپلی کیشنز کے آپریشن کے بارے میں پورے انٹرنیٹ پر بہت کم معلومات ہیں۔
مجھے صرف یہ مواد ملا:

Qsoft سے الیگزینڈر سربل، 1C-Bitrix، اور Anton Tuzlukov کی رپورٹ:

میں اسے سننے کی سفارش کرتا ہوں۔

صارف سے اپنا حل تیار کرنا serkyron Habré پر.
مزید ملا ایسا فیصلہ.

Aaand... اصل میں، بس.

میں آپ کو خبردار کرتا ہوں، ہم نے اوپر کے لنکس میں حل کے معیار کی جانچ نہیں کی ہے :)
ویسے ہمارا حل تیار کرتے وقت میں نے الیگزینڈر سربل سے بات کی، تب اس کی رپورٹ ابھی سامنے نہیں آئی تھی، اس لیے میری سلائیڈز میں ایک آئٹم ہے "Bitrix Kubernetes استعمال نہیں کرتا۔"

لیکن Docker میں Bitrix چلانے کے لیے پہلے سے ہی بہت ساری ریڈی میڈ ڈوکر امیجز موجود ہیں: https://hub.docker.com/search?q=bitrix&type=image

کیا یہ Kubernetes میں Bitrix کے لیے ایک مکمل حل پیدا کرنے کے لیے کافی ہے؟
نہیں. بڑی تعداد میں مسائل ہیں جنہیں حل کرنے کی ضرورت ہے۔

Kubernetes میں Bitrix کے ساتھ کیا مسائل ہیں؟

سب سے پہلے، Dockerhub سے تیار شدہ تصاویر Kubernetes کے لیے موزوں نہیں ہیں۔

اگر ہم مائیکرو سروسز آرکیٹیکچر بنانا چاہتے ہیں (اور Kubernetes میں ہم عام طور پر کرتے ہیں)، تو ہمیں اپنی Kubernetes ایپلیکیشن کو کنٹینرز میں الگ کرنے کی ضرورت ہے اور ہر کنٹینر کو ایک چھوٹا سا فنکشن انجام دینے کی ضرورت ہے (اور اسے اچھی طرح سے انجام دیں)۔ صرف ایک ہی کیوں؟ مختصر میں، آسان، زیادہ قابل اعتماد.
مزید وضاحت کے لیے، یہ مضمون اور ویڈیو دیکھیں، براہ کرم: https://habr.com/ru/company/southbridge/blog/426637/

Dockerhub میں Docker امیجز بنیادی طور پر ایک ہی اصول پر بنائی گئی ہیں، اس لیے ہمیں اب بھی اپنی موٹر سائیکل بنانا پڑی اور یہاں تک کہ شروع سے ہی تصاویر بنانا پڑیں۔

دوسرا - سائٹ کا کوڈ ایڈمن پینل سے ایڈٹ کیا گیا ہے۔

ہم نے سائٹ پر ایک نیا سیکشن بنایا - کوڈ کو اپ ڈیٹ کیا گیا (نئے سیکشن کے نام کے ساتھ ایک ڈائرکٹری شامل کی گئی)۔

اگر آپ نے ایڈمن پینل سے کسی جزو کی خصوصیات کو تبدیل کیا تو کوڈ بدل گیا۔

Kubernetes "بطور ڈیفالٹ" اس کے ساتھ کام نہیں کر سکتا؛ کنٹینرز کو بے وطن ہونا چاہیے۔

وجہ: کلسٹر میں ہر کنٹینر (پوڈ) ٹریفک کے صرف ایک حصے پر عمل کرتا ہے۔ اگر آپ صرف ایک کنٹینر (پوڈ) میں کوڈ تبدیل کرتے ہیں، تو مختلف پوڈز میں کوڈ مختلف ہوگا، سائٹ مختلف طریقے سے کام کرے گی، اور سائٹ کے مختلف ورژن مختلف صارفین کو دکھائے جائیں گے۔ تم ایسے نہیں رہ سکتے۔

تیسرا - آپ کو تعیناتی کے ساتھ مسئلہ کو حل کرنے کی ضرورت ہے۔

اگر ہمارے پاس یک سنگی اور ایک "کلاسک" سرور ہے، تو سب کچھ بہت آسان ہے: ہم ایک نیا کوڈ بیس لگاتے ہیں، ڈیٹا بیس کو منتقل کرتے ہیں، ٹریفک کو کوڈ کے نئے ورژن میں تبدیل کرتے ہیں۔ سوئچنگ فوری طور پر ہوتی ہے۔
اگر ہمارے پاس Kubernetes میں ایک سائٹ ہے، جو مائیکرو سروسز میں کاٹ دی گئی ہے، تو وہاں کوڈ والے بہت سے کنٹینرز ہیں - اوہ۔ آپ کو کوڈ کے نئے ورژن کے ساتھ کنٹینرز کو جمع کرنے، پرانے کی بجائے ان کو رول آؤٹ کرنے، ڈیٹا بیس کو صحیح طریقے سے منتقل کرنے، اور مثالی طور پر ایسا کرنے کی ضرورت ہے جسے دیکھنے والوں کا کوئی دھیان نہیں ہے۔ خوش قسمتی سے، Kubernetes اس میں ہماری مدد کرتا ہے، مختلف قسم کی تعیناتیوں کے پورے گروپ کی حمایت کرتا ہے۔

چوتھا - آپ کو اسٹیٹکس کو ذخیرہ کرنے کے مسئلے کو حل کرنے کی ضرورت ہے۔

اگر آپ کی سائٹ "صرف" 10 گیگا بائٹس ہے اور آپ اسے مکمل طور پر کنٹینرز میں تعینات کرتے ہیں، تو آپ کے پاس 10 گیگا بائٹ کے کنٹینرز ہوں گے جنہیں تعینات کرنے میں ہمیشہ وقت لگتا ہے۔
آپ کو سائٹ کے "سب سے بھاری" حصوں کو کنٹینرز کے باہر ذخیرہ کرنے کی ضرورت ہے، اور سوال یہ پیدا ہوتا ہے کہ اسے صحیح طریقے سے کیسے کیا جائے

ہمارے حل میں کیا کمی ہے؟

پورے Bitrix کوڈ کو مائیکرو فنکشنز/مائیکرو سروسز میں تقسیم نہیں کیا گیا ہے (تاکہ رجسٹریشن الگ ہو، آن لائن اسٹور ماڈیول الگ ہو، وغیرہ)۔ ہم ہر کنٹینر میں پورے کوڈ بیس کو محفوظ کرتے ہیں۔

ہم کبرنیٹس میں ڈیٹا بیس کو بھی ذخیرہ نہیں کرتے ہیں (میں نے اب بھی ترقیاتی ماحول کے لیے Kubernetes میں ڈیٹا بیس کے ساتھ حل نافذ کیے ہیں، لیکن پیداوار کے لیے نہیں)۔

یہ اب بھی سائٹ کے منتظمین کے لیے قابل توجہ رہے گا کہ سائٹ Kubernetes پر چلتی ہے۔ "سسٹم چیک" فنکشن درست طریقے سے کام نہیں کرتا ہے؛ ایڈمن پینل سے سائٹ کوڈ میں ترمیم کرنے کے لیے، آپ کو پہلے "میں کوڈ میں ترمیم کرنا چاہتا ہوں" بٹن پر کلک کرنا چاہیے۔

مسائل کی نشاندہی کی گئی ہے، مائیکرو سروسز کو لاگو کرنے کی ضرورت کا تعین کر لیا گیا ہے، مقصد واضح ہے - Bitrix پر Kubernetes میں ایپلی کیشنز چلانے کے لیے ایک ورکنگ سسٹم حاصل کرنا، Bitrix کی صلاحیتوں اور Kubernetes کے فوائد دونوں کو محفوظ رکھنا۔ آئیے عمل درآمد شروع کریں۔

فن تعمیر

ویب سرور (کارکنان) کے ساتھ بہت سے "کام کرنے والے" پوڈ ہیں۔
ایک انڈر کرون ٹاسک کے ساتھ (صرف ایک کی ضرورت ہے)۔
ایڈمن پینل سے سائٹ کوڈ میں ترمیم کرنے کے لیے ایک اپ گریڈ (صرف ایک کی ضرورت ہے)۔

ہم سوالات حل کرتے ہیں:

• سیشنز کو کہاں ذخیرہ کرنا ہے؟
• کیشے کو کہاں ذخیرہ کرنا ہے؟
• سٹیٹکس کو کہاں ذخیرہ کرنا ہے، کنٹینرز کے ایک گروپ میں گیگا بائٹس کے سٹیٹکس کو نہیں رکھنا ہے؟
• ڈیٹا بیس کیسے کام کرے گا؟

ڈاکر کی تصویر

ہم ڈوکر امیج بنا کر شروع کرتے ہیں۔

مثالی آپشن یہ ہے کہ ہمارے پاس ایک عالمگیر تصویر ہے، اس کی بنیاد پر ہمیں ورکر پوڈز، کرونٹاسک کے ساتھ پوڈز، اور اپ گریڈ پوڈز ملتے ہیں۔

ہم نے صرف ایک ایسی تصویر بنائی ہے۔.

اس میں nginx، apache/php-fpm (تعمیر کے دوران منتخب کیا جا سکتا ہے)، میل بھیجنے کے لیے msmtp، اور cron شامل ہیں۔

تصویر کو جمع کرتے وقت، سائٹ کا پورا کوڈ بیس /app ڈائرکٹری میں کاپی کیا جاتا ہے (ان حصوں کو چھوڑ کر جنہیں ہم علیحدہ مشترکہ اسٹوریج میں منتقل کریں گے)۔

مائیکرو سروسز، سروسز

کارکن کی پھلیاں:

• nginx + کنٹینر apache/php-fpm + msmtp والا کنٹینر
• ایم ایس ایم ٹی پی کو ایک الگ مائیکرو سروس میں منتقل کرنے سے کام نہیں آیا، بِٹرکس ناراض ہونے لگا ہے کہ وہ براہ راست میل نہیں بھیج سکتا۔
• ہر کنٹینر کا ایک مکمل کوڈ بیس ہوتا ہے۔
• کنٹینرز میں کوڈ تبدیل کرنے پر پابندی۔

cron کے تحت:

• اپاچی، پی ایچ پی، کرون کے ساتھ کنٹینر
• مکمل کوڈ بیس شامل ہے۔
• کنٹینرز میں کوڈ تبدیل کرنے پر پابندی

کے تحت اپ گریڈ کریں:

• nginx کنٹینر + apache/php-fpm کنٹینر + msmtp
• کنٹینرز میں کوڈ تبدیل کرنے پر کوئی ممانعت نہیں ہے۔

سیشن اسٹوریج

Bitrix کیش اسٹوریج

ایک اور اہم بات: ہم ڈیٹابیس سے لے کر میل تک، ہر چیز سے منسلک ہونے کے لیے پاس ورڈز kubernetes کے رازوں میں محفوظ کرتے ہیں۔ ہمیں ایک بونس ملتا ہے: پاس ورڈ صرف ان لوگوں کو نظر آتے ہیں جنہیں ہم رازوں تک رسائی دیتے ہیں، اور ہر اس شخص کو نہیں جو پروجیکٹ کے کوڈ بیس تک رسائی رکھتے ہیں۔

اسٹیٹکس کے لیے ذخیرہ

آپ کچھ بھی استعمال کر سکتے ہیں: ceph، nfs (لیکن ہم پیداوار کے لیے nfs کی سفارش نہیں کرتے ہیں)، کلاؤڈ فراہم کرنے والوں سے نیٹ ورک اسٹوریج وغیرہ۔

سٹوریج کو کنٹینرز میں سائٹ کی /upload/ ڈائرکٹری اور جامد مواد کے ساتھ دیگر ڈائریکٹریز سے منسلک کرنے کی ضرورت ہوگی۔

ڈیٹا بیس۔

سادگی کے لیے، ہم ڈیٹا بیس کو Kubernetes سے باہر منتقل کرنے کی تجویز کرتے ہیں۔ Kubernetes میں بنیاد ایک الگ پیچیدہ کام ہے؛ یہ اسکیم کو مزید پیچیدہ بنا دے گا۔

سیشن اسٹوریج

ہم memcached استعمال کرتے ہیں :)

یہ سیشن اسٹوریج کو اچھی طرح سے ہینڈل کرتا ہے، کلسٹرڈ ہے، اور پی ایچ پی میں سیشن. سیو_پاتھ کے بطور "مقامی طور پر" سپورٹ کیا جاتا ہے۔ کلاسیکی یک سنگی فن تعمیر میں اس طرح کے نظام کا کئی بار تجربہ کیا گیا ہے، جب ہم نے ویب سرورز کی ایک بڑی تعداد کے ساتھ کلسٹر بنائے تھے۔ تعیناتی کے لیے ہم ہیلم کا استعمال کرتے ہیں۔

$ helm install stable/memcached --name session

php.ini - یہاں تصویر memcached میں سیشنز کو ذخیرہ کرنے کی ترتیبات پر مشتمل ہے۔

ہم نے memcached کے ساتھ میزبانوں کے بارے میں ڈیٹا منتقل کرنے کے لیے Environment Variables کا استعمال کیا۔ 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 میں یہ بتایا گیا ہے کہ کیش کہاں محفوظ ہے

ہم ماحولیاتی متغیرات بھی استعمال کرتے ہیں۔

کرونٹاسکی

Kubernetes میں کرونٹاسکس چلانے کے مختلف طریقے ہیں۔

• کرونٹاسکس چلانے کے لیے پوڈ کے ساتھ علیحدہ تعیناتی۔
• cronjob crontasks کو انجام دینے کے لیے (اگر یہ ویب ایپ ہے - wget کے ساتھ https://$host$cronjobname، یا kubectl exec ورکر پوڈ وغیرہ میں سے کسی ایک کے اندر۔)
• وغیرہ شامل ہیں.

آپ سب سے درست کے بارے میں بحث کر سکتے ہیں، لیکن اس معاملے میں ہم نے "کرونٹاسک کے لیے پوڈز کے ساتھ علیحدہ تعیناتی" کا آپشن منتخب کیا۔

یہ کیسے کیا جاتا ہے:

• ConfigMap کے ذریعے یا config/addcron فائل کے ذریعے cron کام شامل کریں۔
• ایک مثال میں ہم ورکر پوڈ سے مشابہ کنٹینر لانچ کرتے ہیں + اس میں کراؤن کے کاموں کو انجام دینے کی اجازت دیتے ہیں
• ایک ہی کوڈ بیس استعمال کیا جاتا ہے، اتحاد کی بدولت، کنٹینر اسمبلی آسان ہے۔

ہمیں کیا اچھا ملتا ہے:

• ہمارے پاس ایسے ماحول میں کرونٹاسکس کام کر رہے ہیں جو ڈویلپرز کے ماحول سے ملتے جلتے ہیں (ڈاکر)
• کرونٹاسکس کو کبرنیٹس کے لیے "دوبارہ لکھنے" کی ضرورت نہیں ہے، وہ پہلے کی طرح اسی شکل میں اور اسی کوڈ بیس میں کام کرتے ہیں۔
• cron ٹاسکس کو ٹیم کے تمام ممبران پروڈکشن برانچ کے کمٹ رائٹس کے ساتھ شامل کر سکتے ہیں، نہ صرف ایڈمنز

ساؤتھ برج K8SD ایڈمن پینل سے ماڈیول اور کوڈ میں ترمیم کریں۔

ہم کے تحت اپ گریڈ کے بارے میں بات کر رہے تھے؟
وہاں ٹریفک کو کیسے ڈائریکٹ کیا جائے؟
ارے، ہم نے پی ایچ پی میں اس کے لیے ایک ماڈیول لکھا ہے :) یہ Bitrix کے لیے ایک چھوٹا کلاسک ماڈیول ہے۔ یہ ابھی تک عوامی طور پر دستیاب نہیں ہے، لیکن ہم اسے کھولنے کا ارادہ رکھتے ہیں۔
ماڈیول Bitrix میں ایک باقاعدہ ماڈیول کی طرح انسٹال ہے:

اور یہ اس طرح لگتا ہے:

یہ آپ کو ایک کوکی سیٹ کرنے کی اجازت دیتا ہے جو سائٹ کے منتظم کی شناخت کرتی ہے اور Kubernetes کو ٹریفک کو اپ گریڈ پوڈ پر بھیجنے کی اجازت دیتی ہے۔

تبدیلیاں مکمل ہونے پر، آپ کو گٹ پش پر کلک کرنے کی ضرورت ہے، کوڈ کی تبدیلیاں گٹ پر بھیجی جائیں گی، پھر سسٹم کوڈ کے نئے ورژن کے ساتھ ایک تصویر بنائے گا اور پرانے پوڈز کی جگہ لے کر اسے کلسٹر میں "رول آؤٹ" کرے گا۔ .

ہاں، یہ قدرے مشکل ہے، لیکن اس کے ساتھ ساتھ ہم مائیکرو سروس فن تعمیر کو برقرار رکھتے ہیں اور Bitrix کے صارفین سے ایڈمن پینل سے کوڈ کو درست کرنے کا ان کا پسندیدہ موقع نہیں چھینتے۔ آخر میں، یہ ایک آپشن ہے؛ آپ کوڈ میں ترمیم کے مسئلے کو مختلف طریقے سے حل کر سکتے ہیں۔

ہیلم چارٹ

Kubernetes پر ایپلی کیشنز بنانے کے لیے، ہم عام طور پر ہیلم پیکیج مینیجر کا استعمال کرتے ہیں۔
Kubernetes میں ہمارے Bitrix حل کے لیے، ہمارے سرکردہ سسٹم ایڈمنسٹریٹر Sergey Bondarev نے ایک خصوصی ہیلم چارٹ لکھا۔

یہ ورکر، یوگریڈ، کرون پوڈز بناتا ہے، داخلے، خدمات کو ترتیب دیتا ہے، اور متغیرات کو Kubernetes سیکرٹس سے pods میں منتقل کرتا ہے۔

ہم Gitlab میں کوڈ اسٹور کرتے ہیں، اور ہم Gitlab سے ہیلم بلڈ بھی چلاتے ہیں۔

مختصر میں، یہ اس طرح لگتا ہے

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

اگر تعیناتی کے دوران اچانک کچھ غلط ہو جاتا ہے تو ہیلم آپ کو "سیملیس" رول بیک کرنے کی بھی اجازت دیتا ہے۔ یہ اچھا ہے جب آپ گھبراہٹ میں نہ ہوں "کوڈ کو ایف ٹی پی کے ذریعے ٹھیک کریں کیونکہ پروڈ گر گیا ہے،" لیکن Kubernetes یہ خود بخود کرتا ہے، اور بغیر وقت کے۔

تعینات کریں۔

جی ہاں، ہم Gitlab اور Gitlab CI کے پرستار ہیں، ہم اسے استعمال کرتے ہیں :)
Gitlab میں پروجیکٹ کے ذخیرے کے لیے کمٹمنٹ کرتے وقت، Gitlab ایک پائپ لائن شروع کرتا ہے جو ماحول کا ایک نیا ورژن متعین کرتا ہے۔

مرحلے:

• تعمیر (ایک نئی ڈوکر امیج بنانا)
• ٹیسٹ (ٹیسٹنگ)
• صاف کریں (ٹیسٹ ماحول کو ہٹانا)
• push (ہم اسے ڈاکر رجسٹری میں بھیجتے ہیں)
• deploy (ہم درخواست کو ہیلم کے ذریعے Kubernetes پر تعینات کرتے ہیں)۔

ہیرے، یہ تیار ہے، آئیے اسے لاگو کریں!
ٹھیک ہے، یا سوالات پوچھیں اگر کوئی ہیں.

تو ہم نے کیا کیا

تکنیکی نقطہ نظر سے:

• dockerized Bitrix؛
• Bitrix کو کنٹینرز میں "کٹ" کریں، جن میں سے ہر ایک کم از کم افعال انجام دیتا ہے۔
• کنٹینرز کی بے وطن حالت حاصل کی؛
• Kubernetes میں Bitrix کو اپ ڈیٹ کرنے کے ساتھ مسئلہ حل کیا؛
• Bitrix کے تمام افعال کام کرتے رہے (تقریباً سبھی)؛
• ہم نے Kubernetes میں تعیناتی اور ورژن کے درمیان رول بیک پر کام کیا۔

کاروباری نقطہ نظر سے:

• غلطی کی رواداری؛
• Kubernetes ٹولز (Gitlab CI کے ساتھ آسان انضمام، ہموار تعیناتی، وغیرہ)؛
• خفیہ پاس ورڈز (صرف ان لوگوں کو نظر آتا ہے جنہیں پاس ورڈز تک براہ راست رسائی دی جاتی ہے)؛
• ایک انفراسٹرکچر کے اندر اضافی ماحول (ترقی، ٹیسٹ وغیرہ کے لیے) بنانا آسان ہے۔

ماخذ: www.habr.com