پل جنوبی در چلیابینسک و بیتریکس در کوبرنتیس

جلسات مدیریت سیستم Sysadminka در چلیابینسک در حال انجام است و در آخرین جلسه من گزارشی از راه حل ما برای اجرای برنامه ها در 1C-Bitrix در Kubernetes ارائه کردم.

Bitrix، Kubernetes، Ceph - یک مخلوط عالی؟

من به شما خواهم گفت که چگونه از همه اینها یک راه حل کار جمع آوری کرده ایم.

بریم!

این دیدار در 18 آوریل در چلیابینسک برگزار شد. شما می توانید در مورد ملاقات های ما در اینجا بخوانید تایم پد و نگاه کنید یوتیوب.

اگر می خواهید با گزارش یا به عنوان شنونده به ما بیایید - خوش آمدید، به ما بنویسید [ایمیل محافظت شده] و در تلگرام t.me/vadimisakanov.

گزارش من

اسلایدها

راه حل "Bitrix در Kubernetes، نسخه Southbridge 1.0"

همانطور که در جلسه انجام شد، من در مورد راه حل خود در قالب "برای آدمک ها در Kubernetes" صحبت خواهم کرد. اما من فرض می کنم که حداقل در سطح مقالات ویکی پدیا کلمات Bitrix، Docker، Kubernetes، Ceph را می شناسید.

چه چیزی در مورد Bitrix در Kubernetes آماده است؟

اطلاعات بسیار کمی در کل اینترنت در مورد عملکرد برنامه های Bitrix در Kubernetes وجود دارد.
من فقط این مواد را پیدا کردم:

گزارش توسط Alexander Serbul، 1C-Bitrix، و Anton Tuzlukov از Qsoft:

توصیه میکنم گوش کنید

در حال توسعه راه حل خود از طرف کاربر سرکیرون در هابره.
بیشتر پیدا کرد چنین تصمیمی.

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 به microfunctions/microservices تقسیم نمی شود (به طوری که ثبت نام جداگانه است، ماژول فروشگاه آنلاین جداگانه است و غیره). کل پایه کد را در هر ظرف ذخیره می کنیم.

ما همچنین پایگاه داده را در Kubernetes ذخیره نمی‌کنیم (من هنوز راه‌حل‌هایی را با پایگاه داده در Kubernetes برای محیط‌های توسعه پیاده‌سازی کردم، اما نه برای تولید).

همچنان برای مدیران سایت قابل توجه است که سایت بر روی Kubernetes اجرا می شود. عملکرد "بررسی سیستم" به درستی کار نمی کند؛ برای ویرایش کد سایت از پنل مدیریت، ابتدا باید روی دکمه "می خواهم کد را ویرایش کنم" کلیک کنید.

مشکلات شناسایی شده اند، نیاز به پیاده سازی میکروسرویس ها مشخص شده است، هدف مشخص است - دریافت یک سیستم کاری برای اجرای برنامه های کاربردی در Bitrix در Kubernetes، با حفظ قابلیت های Bitrix و مزایای Kubernetes. بیایید اجرا را شروع کنیم.

معماری

پادهای "کار" زیادی با یک وب سرور (کارگران) وجود دارد.
یکی زیر با وظایف cron (فقط یکی مورد نیاز است).
یک ارتقا برای ویرایش کد سایت از پنل مدیریت (همچنین فقط یک مورد نیاز است).

ما سوالات را حل می کنیم:

• جلسات را کجا ذخیره کنیم؟
• کش را کجا ذخیره کنیم؟
• استاتیک را کجا ذخیره کنیم، نه اینکه گیگابایت استاتیک را در یک دسته ظروف قرار دهیم؟
• پایگاه داده چگونه کار خواهد کرد؟

تصویر داکر

ما با ساختن یک تصویر داکر شروع می کنیم.

گزینه ایده آل این است که ما یک تصویر جهانی داشته باشیم، بر اساس آن، غلاف های کارگر، غلاف هایی با Crontasks و غلاف های ارتقاء داده می شود.

ما دقیقاً چنین تصویری ساختیم.

این شامل nginx، apache/php-fpm (در حین ساخت قابل انتخاب است)، msmtp برای ارسال نامه و cron است.

هنگام مونتاژ تصویر، کل پایه کد سایت در پوشه /app کپی می شود (به استثنای آن قسمت هایی که به یک ذخیره سازی مشترک جداگانه منتقل می کنیم).

خدمات میکرو، خدمات

غلاف کارگر:

• کانتینری با nginx + کانتینر apache/php-fpm + msmtp
• انتقال msmtp به یک میکروسرویس جداگانه کارساز نبود، Bitrix شروع به خشمگین شدن می کند که نمی تواند مستقیماً نامه ارسال کند.
• هر ظرف دارای یک کد کامل است.
• ممنوعیت تغییر کد در کانتینرها.

cron under:

• ظرف با آپاچی، 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 است

ما از Environment Variables برای انتقال داده ها در مورد میزبان با memcached استفاده کردیم https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
این به شما امکان می دهد از کدهای مشابه در محیط های dev، stage، test، prod استفاده کنید (نام هاست memcach شده در آنها متفاوت خواهد بود، بنابراین باید یک نام میزبان منحصر به فرد برای جلسات به هر محیط ارسال کنیم).
ذخیره سازی کش 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 داخل یکی از Worker pods و غیره)
• و غیره.

شما می توانید در مورد صحیح ترین مورد بحث کنید، اما در این مورد ما گزینه "استقرار جداگانه با pods برای Crontasks" را انتخاب کردیم.

چگونه انجام می شود:

• وظایف cron را از طریق ConfigMap یا از طریق فایل config/addcron اضافه کنید
• در یک نمونه، ما یک کانتینر مشابه با غلاف کارگر راه‌اندازی می‌کنیم + اجازه اجرای وظایف تاج را در آن می‌دهیم.
• از همان پایه کد استفاده می شود، به لطف یکپارچه سازی، مونتاژ کانتینر ساده است

چه خوب به دست می آوریم:

• ما Crontasks را در محیطی مشابه با محیط توسعه دهندگان (docker) داریم.
• Crontasks نیازی به "بازنویسی" برای Kubernetes نیست، آنها به همان شکل و در همان پایه کد قبلی کار می کنند.
• وظایف cron را می توان توسط همه اعضای تیم با حقوق تعهد به شاخه تولید اضافه کرد، نه فقط مدیران

ماژول Southbridge K8SDeploy و ویرایش کد از پنل مدیریت

ما در مورد ارتقاء زیر صحبت می کردیم؟
چگونه ترافیک را به آنجا هدایت کنیم؟
هورا، ما یک ماژول برای این در PHP نوشتیم :) این یک ماژول کلاسیک کوچک برای Bitrix است. هنوز در دسترس عموم نیست، اما ما قصد داریم آن را باز کنیم.
ماژول مانند یک ماژول معمولی در Bitrix نصب شده است:

و به نظر می رسد این است:

این به شما امکان می دهد کوکی تنظیم کنید که مدیر سایت را شناسایی کند و به Kubernetes اجازه می دهد تا ترافیک را به غلاف ارتقاء ارسال کند.

وقتی تغییرات تکمیل شد، باید روی git push کلیک کنید، تغییرات کد به git ارسال می‌شود، سپس سیستم یک تصویر با نسخه جدیدی از کد می‌سازد و آن را در سراسر خوشه پخش می‌کند، و جایگزین پادهای قدیمی می‌شود. .

بله، این کمی مشکل است، اما در عین حال ما معماری میکروسرویس را حفظ می کنیم و فرصت مورد علاقه کاربران Bitrix را برای تصحیح کد از پنل مدیریت از دست نمی دهیم. در نهایت این یک گزینه است؛ شما می توانید مشکل ویرایش کد را به روش دیگری حل کنید.

نمودار هلم

برای ساخت برنامه های کاربردی در Kubernetes، ما معمولا از مدیریت بسته Helm استفاده می کنیم.
برای راه حل Bitrix ما در Kubernetes، سرگئی بوندارف، مدیر پیشرو سیستم ما، یک نمودار Helm ویژه نوشت.

Worker، Ugrade، Cron pods را ایجاد می کند، ورودی ها، سرویس ها را پیکربندی می کند و متغیرها را از Secrets Kubernetes به pods منتقل می کند.

ما کد را در 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 همچنین به شما این امکان را می دهد که اگر در حین استقرار ناگهان مشکلی پیش آمد، یک بازگشت بدون درز انجام دهید. وقتی در هراس نیستید، خوب است «کد را از طریق ftp تعمیر کنید زیرا پرود سقوط کرد»، اما Kubernetes این کار را به صورت خودکار و بدون توقف انجام می‌دهد.

مستقر کنید

بله، ما طرفداران Gitlab & Gitlab CI هستیم، از آن استفاده می کنیم :)
هنگامی که در Gitlab به مخزن پروژه متعهد می شوید، Gitlab خط لوله ای را راه اندازی می کند که نسخه جدیدی از محیط را مستقر می کند.

مراحل:

• ساخت (ساخت یک تصویر داکر جدید)
• تست (تست)
• پاک کردن (حذف محیط تست)
• فشار دهید (ما آن را به رجیستری Docker ارسال می کنیم)
• deploy (ما برنامه را از طریق Helm در Kubernetes مستقر می کنیم).

هورا، آماده است، بیایید آن را اجرا کنیم!
خوب یا اگر سوالی هست بپرسید.

پس چیکار کردیم

از نظر فنی:

• Dockerized Bitrix;
• Bitrix را به ظروف "برش دهید" که هر کدام حداقل عملکرد را انجام می دهند.
• به وضعیت بدون وضعیت کانتینرها دست یافت.
• مشکل به روز رسانی Bitrix در Kubernetes را حل کرد.
• همه توابع Bitrix به کار خود ادامه دادند (تقریباً همه).
• ما روی استقرار به Kubernetes و بازگشت بین نسخه ها کار کردیم.

از دیدگاه تجاری:

• تحمل خطا؛
• ابزارهای Kubernetes (ادغام آسان با Gitlab CI، استقرار بدون درز و غیره)؛
• رمزهای عبور مخفی (فقط برای کسانی که مستقیماً به آنها اجازه دسترسی داده شده است قابل مشاهده است).
• ایجاد محیط های اضافی (برای توسعه، آزمایش و غیره) در یک زیرساخت راحت است.

منبع: www.habr.com