Sysadminka sistem administratorunun görüşləri Çelyabinskdə keçirilir və sonuncuda mən Kubernetes-də 1C-Bitrix-də tətbiqləri işə salmaq üçün həllimiz haqqında hesabat verdim.
Bitrix, Kubernetes, Ceph - əla qarışıqdır?
Bütün bunlardan bir iş həllini necə birləşdirdiyimizi sizə xəbər verəcəyəm.
Gidelim!
Görüş aprelin 18-də Çelyabinskdə baş tutub. Görüşlərimiz haqqında oxuya bilərsiniz və baxın .
Bizə reportajla və ya dinləyici kimi gəlmək istəyirsinizsə - xoş gəlmisiniz, yazın [e-poçt qorunur] və Telegram t.me/vadimisakanov-da.
Mənim hesabatım
Həll "Kubernetes-də Bitrix, Southbridge 1.0 versiyası"
Görüşdə olduğu kimi, “Kubernetes-də dummies” formatında həllimiz haqqında danışacağam. Amma güman edirəm ki, siz Bitrix, Docker, Kubernetes, Ceph sözlərini heç olmasa Vikipediyadakı məqalələr səviyyəsində bilirsiniz.
Kubernetes-də Bitrix haqqında nə hazırdır?
Kubernetes-də Bitrix proqramlarının işləməsi haqqında bütün İnternetdə çox az məlumat var.
Mən yalnız bu materialları tapdım:
Qsoft-dan Alexander Serbul, 1C-Bitrix və Anton Tuzlukovun reportajı:
Dinləməyi məsləhət görürəm.
İstifadəçidən öz həllinizin hazırlanması .
Daha çox tapıldı .
Aaand... əslində, hamısı budur.
Sizi xəbərdar edirəm, yuxarıdakı linklərdəki həllərin keyfiyyətini yoxlamamışıq :)
Yeri gəlmişkən, həllimizi hazırlayarkən mən Alexander Serbul ilə danışdım, sonra onun hesabatı hələ görünməmişdi, buna görə slaydlarımda "Bitrix Kubernetes istifadə etmir" maddəsi var.
Ancaq Bitrix-i Docker-də işə salmaq üçün artıq çoxlu hazır Docker təsvirləri var:
Bu, Kubernetes-də Bitrix üçün tam bir həll yaratmaq üçün kifayətdirmi?
Yox. Həll edilməli olan çoxlu sayda problemlər var.
Kubernetes-də Bitrix ilə bağlı problemlər nələrdir?
Birincisi, Dockerhub-dan hazır şəkillər Kubernetes üçün uyğun deyil
Əgər biz mikroservis arxitekturası qurmaq istəyiriksə (və Kubernetesdə adətən edirik), biz Kubernetes tətbiqimizi konteynerlərə ayırmalı və hər konteynerin bir kiçik funksiya yerinə yetirməsini təmin etməliyik (və bunu yaxşı edin). Niyə yalnız bir? Bir sözlə, nə qədər sadə olsa, bir o qədər etibarlıdır.
Daha konkret olmaq üçün bu məqaləyə və videoya baxın:
Dockerhub-da Docker şəkilləri əsasən hamısı bir-bir prinsip əsasında qurulur, buna görə də biz hələ də öz velosipedimizi yaratmalı və hətta sıfırdan şəkillər yaratmalı olduq.
İkincisi - sayt kodu admin panelindən redaktə edilir
Saytda yeni bölmə yaratdıq - kod yeniləndi (yeni bölmənin adı ilə kataloq əlavə edildi).
Admin panelindən komponentin xassələrini dəyişmisinizsə, kod dəyişdi.
Kubernetes "defolt olaraq" bununla işləyə bilməz; konteynerlər vətəndaşlığı olmayan olmalıdır.
Səbəb: Klasterdəki hər bir konteyner (pod) trafikin yalnız bir hissəsini emal edir. Əgər kodu yalnız bir konteynerdə (podda) dəyişdirsəniz, o zaman kod müxtəlif podlarda fərqli olacaq, sayt fərqli işləyəcək və saytın müxtəlif versiyaları müxtəlif istifadəçilərə göstəriləcək. Sən belə yaşaya bilməzsən.
Üçüncüsü - yerləşdirmə ilə problemi həll etməlisiniz
Monolit və bir "klassik" serverimiz varsa, hər şey olduqca sadədir: yeni kod bazası yerləşdiririk, verilənlər bazasını köçürür, trafiki kodun yeni versiyasına keçiririk. Dəyişmə dərhal baş verir.
Kubernetes-də mikroservislərə kəsilmiş bir saytımız varsa, kodu olan bir çox konteyner var - oh. Kodun yeni versiyası ilə konteynerlər toplamalı, onları köhnələrin əvəzinə yaymalı, verilənlər bazasını düzgün köçürməli və ideal olaraq bunu ziyarətçilər tərəfindən nəzərə alınmadan etməlisiniz. Xoşbəxtlikdən, Kubernetes bu işdə bizə kömək edir, müxtəlif növ yerləşdirmələri dəstəkləyir.
Dördüncüsü - statiklərin saxlanması məsələsini həll etməlisiniz
Saytınız "yalnız" 10 giqabaytdırsa və siz onu tamamilə konteynerlərdə yerləşdirsəniz, yerləşdirməyə əbədi vaxt aparan 10 gigabaytlıq konteynerlər əldə edəcəksiniz.
Saytın "ən ağır" hissələrini konteynerlərdən kənarda saxlamalısınız və bunu necə düzgün etmək barədə sual yaranır.
Bizim həllimizdə nə çatışmır?
Bütün Bitrix kodu mikrofunksiyalara/mikroservislərə bölünmür (belə ki, qeydiyyat ayrıca, onlayn mağaza modulu ayrı və s.). Biz bütün kod bazasını hər bir konteynerdə saxlayırıq.
Biz həmçinin verilənlər bazasını Kubernetes-də saxlamırıq (mən hələ də inkişaf mühitləri üçün Kubernetes-də verilənlər bazası ilə həllər tətbiq etmişəm, lakin istehsal üçün deyil).
Saytın Kubernetes-də işlədiyi sayt administratorları üçün hələ də nəzərə çarpacaq. “Sistem yoxlaması” funksiyası düzgün işləmir, admin panelindən sayt kodunu redaktə etmək üçün əvvəlcə “Mən kodu redaktə etmək istəyirəm” düyməsini sıxmalısınız.
Problemlər müəyyən edilib, mikroservislərin tətbiqi zərurəti müəyyən edilib, məqsəd aydındır - Bitrix-in həm imkanlarını, həm də Kubernetes-in üstünlüklərini qoruyub saxlamaqla, Kubernetes-də Bitrix-də tətbiqləri işə salmaq üçün işləyən sistem əldə etmək. Tətbiq etməyə başlayaq.
memarlıq
Veb server (işçilər) ilə çoxlu "işləyən" podlar var.
Biri cron tapşırıqları ilə (yalnız bir tələb olunur).
Admin panelindən sayt kodunu redaktə etmək üçün bir təkmilləşdirmə (həmçinin yalnız biri tələb olunur).
Sualları həll edirik:
- Seansları harada saxlamaq olar?
- Keşi harada saxlamaq olar?
- Gigabayt statikləri bir dəstə konteynerə yerləşdirməmək üçün statikanı harada saxlamaq lazımdır?
- Verilənlər bazası necə işləyəcək?
Docker şəkli
Docker şəklini yaratmaqla başlayırıq.
İdeal seçim odur ki, bir universal imicimiz var, onun əsasında işçi podlar, Crontasks ilə podlar və təkmil podlar əldə edirik.
.
Buraya nginx, apache/php-fpm (qurma zamanı seçilə bilər), poçt göndərmək üçün msmtp və cron daxildir.
Şəkli yığarkən saytın bütün kod bazası /app qovluğuna kopyalanır (ayrıca paylaşılan yaddaşa keçəcəyimiz hissələr istisna olmaqla).
Mikroservislər, xidmətlər
işçi qabları:
- Nginx + konteyner apache/php-fpm + msmtp ilə konteyner
- Msmtp-ni ayrıca mikroservisə köçürmək alınmadı, Bitrix birbaşa poçt göndərə bilmədiyi üçün qəzəblənməyə başlayır.
- Hər bir konteynerin tam kod bazası var.
- Konteynerlərdə kodun dəyişdirilməsinə qadağa.
cron altında:
- apache, php, cron ilə konteyner
- tam kod bazası daxildir
- konteynerlərdə kodun dəyişdirilməsinə qadağa
altında təkmilləşdirmək:
- nginx konteyneri + apache/php-fpm konteyneri + msmtp
- Konteynerlərdə kodun dəyişdirilməsinə heç bir qadağa yoxdur
sessiya saxlama
Bitrix keş yaddaşı
Başqa bir vacib şey: verilənlər bazasından tutmuş poçta qədər hər şeyə qoşulmaq üçün parolları kubernet sirlərində saxlayırıq. Biz bonus alırıq: parollar yalnız sirrlərə giriş icazəsi verdiyimiz şəxslərə görünür, layihənin kod bazasına girişi olan hər kəsə deyil.
Statik üçün saxlama
Hər şeydən istifadə edə bilərsiniz: ceph, nfs (lakin biz istehsal üçün nfs tövsiyə etmirik), bulud provayderlərindən şəbəkə yaddaşı və s.
Yaddaş saytın /yükləmə/ kataloquna və statik məzmunlu digər qovluqlara konteynerlərdə qoşulmalıdır.
Verilənlər bazası
Sadəlik üçün verilənlər bazasını Kubernetesdən kənara köçürməyi tövsiyə edirik. Kubernetesdəki baza ayrıca mürəkkəb bir vəzifədir; o, sxemi böyüklük sırasını daha mürəkkəb edəcəkdir.
Sessiya yaddaşı
Memcached istifadə edirik :)
O, sessiya yaddaşını yaxşı idarə edir, çoxluq təşkil edir və php-də session.save_path kimi “doğma” olaraq dəstəklənir. Belə bir sistem klassik monolit arxitekturada dəfələrlə sınaqdan keçirilmişdir, biz çoxlu sayda veb serverləri olan klasterlər qurduq. Yerləşdirmə üçün biz dəbilqədən istifadə edirik.
$ helm install stable/memcached --name sessionphp.ini - burada şəkil seansları memcached-də saxlamaq üçün parametrləri ehtiva edir
Memcached ilə hostlar haqqında məlumatları ötürmək üçün Ətraf Dəyişənlərdən istifadə etdik .
Bu, inkişaf, mərhələ, test, məhsul mühitlərində eyni kodu istifadə etməyə imkan verir (onlarda yaddaşda saxlanılan host adları fərqli olacaq, ona görə də hər mühitə sessiyalar üçün unikal host adı ötürməliyik).
Bitrix keş yaddaşı
Bizə bütün podların yazıb oxuya biləcəyi xətaya dözümlü yaddaş lazımdır.
Biz də memcached istifadə edirik.
Bu həll Bitrix özü tərəfindən tövsiyə olunur.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - burada Bitrix-də keşin harada saxlandığı göstərilir
Biz həmçinin Mühit Dəyişənlərindən istifadə edirik.
Krontaski
Kubernetes-də Crontasks-ı işə salmaq üçün müxtəlif yanaşmalar var.
- Crontasks-ı işə salmaq üçün pod ilə ayrıca yerləşdirmə
- crontaskları yerinə yetirmək üçün cronjob (bu bir veb tətbiqidirsə - wget ilə , və ya kubectl exec işçi podlarından birinin daxilində və s.)
- s.
Ən doğrusu haqqında mübahisə edə bilərsiniz, lakin bu halda biz "Crontasks üçün podlarla ayrıca yerləşdirmə" seçimini seçdik.
Bunu necə etmək olar:
- ConfigMap və ya config/addcron faylı vasitəsilə cron tapşırıqlarını əlavə edin
- bir halda biz işçi podu ilə eyni konteyneri işə salırıq + ondakı tac tapşırıqlarının yerinə yetirilməsinə icazə veririk
- eyni kod bazası istifadə olunur, birləşmə sayəsində konteyner montajı sadədir
Nə yaxşı alırıq:
- bizdə tərtibatçıların mühiti (doker) ilə eyni mühitdə işləyən Crontasks var.
- Crontaskların Kubernetes üçün “yenidən yazılmasına” ehtiyac yoxdur, onlar əvvəlki formada və eyni kod bazasında işləyirlər.
- cron tapşırıqlarını yalnız administratorlar deyil, istehsal sahəsinə öhdəlik hüququ olan bütün komanda üzvləri əlavə edə bilər
Southbridge K8SDeploy modulu və admin panelindən kod redaktəsi
Biz altında yeniləmə haqqında danışırdıq?
Oraya trafiki necə yönləndirmək olar?
Hurray, bunun üçün PHP-də modul yazdıq :) Bu Bitrix üçün kiçik klassik moduldur. Hələ ictimaiyyətə açıq deyil, amma biz onu açmağı planlaşdırırıq.
Modul Bitrix-də adi modul kimi quraşdırılmışdır:
Və belə görünür:
Bu, sayt administratorunu müəyyən edən kuki təyin etməyə və Kubernetes-ə təkmilləşdirmə poduna trafik göndərməyə imkan verir.
Dəyişikliklər tamamlandıqda, git push düyməsini sıxmalısınız, kod dəyişiklikləri git-ə göndəriləcək, sonra sistem kodun yeni versiyası ilə bir şəkil quracaq və köhnə podları əvəz edərək onu klasterdə "yayacaq". .
Bəli, bu, bir qədər çətin işdir, lakin eyni zamanda biz mikroservis arxitekturasını qoruyuruq və Bitrix istifadəçilərinin admin panelindən kodu düzəltmək üçün sevimli imkanlarından əl çəkmirik. Sonda bu bir seçimdir, kodun redaktə problemini başqa cür həll edə bilərsiniz.
Sükan diaqramı
Kubernetes-də tətbiqlər yaratmaq üçün biz adətən Helm paket menecerindən istifadə edirik.
Kubernetes-də Bitrix həllimiz üçün aparıcı sistem administratorumuz Sergey Bondarev xüsusi Helm diaqramı yazdı.
O, işçi, ugrade, cron podları qurur, girişləri, xidmətləri konfiqurasiya edir və dəyişənləri Kubernetes sirlərindən podlara köçürür.
Biz kodu Gitlab-da saxlayırıq və Gitlab-dan Helm quruluşunu da icra edirik.
Bir sözlə, belə görünür
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm, həmçinin yerləşdirmə zamanı qəflətən nəsə səhv olarsa, sizə “sorunsuz” geri qayıtmağa imkan verir. Çaxnaşma içində olmadığınız zaman "məhsul düşdüyü üçün kodu ftp vasitəsilə düzəldin" çox gözəldir, lakin Kubernetes bunu avtomatik və fasiləsiz edir.
Yerləşdirmək
Bəli, biz Gitlab & Gitlab CI pərəstişkarlarıyıq, ondan istifadə edirik :)
Gitlab-da layihə deposuna daxil olduqda, Gitlab ətraf mühitin yeni versiyasını yerləşdirən boru kəmərini işə salır.
Mərhələlər:
- qurmaq (yeni Docker şəklinin yaradılması)
- sınaq (sınaq)
- təmizləyin (test mühitinin çıxarılması)
- itələyin (biz onu Docker reyestrinə göndəririk)
- yerləşdirin (biz Helm vasitəsilə tətbiqi Kubernetes-ə yerləşdiririk).
Hurray, hazırdır, həyata keçirək!
Yaxşı və ya sualınız varsa soruşun.
Beləliklə, biz nə etdik
Texniki baxımdan:
- dokerləşdirilmiş Bitrix;
- Bitrix-i hər biri minimum funksiyaları yerinə yetirən konteynerlərə "kəsmək";
- konteynerlərin vətəndaşlığı olmayan vəziyyətinə nail olmaq;
- Kubernetes-də Bitrix-i yeniləmək problemini həll etdi;
- bütün Bitrix funksiyaları işləməyə davam etdi (demək olar ki, hamısı);
- Biz Kubernetes-ə yerləşdirmə və versiyalar arasında geri çəkilmə üzərində işlədik.
Biznes baxımından:
- səhvlərə dözümlülük;
- Kubernetes alətləri (Gitlab CI ilə asan inteqrasiya, qüsursuz yerləşdirmə və s.);
- gizli parollar (yalnız parollara birbaşa giriş icazəsi olanlara görünür);
- Tək bir infrastruktur daxilində əlavə mühitlər (inkişaf, sınaqlar və s. üçün) yaratmaq rahatdır.
Mənbə: www.habr.com