Southbridge in Chelyabinsk and Bitrix in Kubernetes

V Čeljabinsku potekajo mitingi sistemskih administratorjev Sysadminka, na zadnjem od njih pa sem imel predavanje o naši rešitvi za delovanje aplikacij na 1C-Bitrix v Kubernetesu.

Bitrix, Kubernetes, Ceph — odlična mešanica?

Povedal bom, kako smo iz vsega tega sestavili delujočo rešitev.

Gremo!

Miting je potekal 18. aprila v Čeljabinsku. O naših mitingih lahko preberete v Timepad in si jih ogledate na YouTube-u.

Če želite priti k nam s predavanjem ali kot poslušalec — dobrodošli, pišite na vadim.isakanov@gmail.com in v Telegram t.me/vadimisakanov.

Moje predavanje

Diapozitivi

Rešitev „Bitrix v Kubernetesu, različica Southbridge 1.0“

Povedal bom o naši rešitvi v formatu „za začetnike v Kubernetesu“, kako je bilo to izvedeno na mitingu. Predvidevam pa, da so vam besede Bitrix, Docker, Kubernetes, Ceph znane vsaj na ravni člankov v Wikipediji.

Kaj sploh obstaja o Bitrixu v Kubernetesu?

Na spletu je zelo malo informacij o delovanju aplikacij na Bitrixu v Kubernetesu.
Našel sem le take materiale:

Predavanje Aleksandra Serbula, 1C-Bitrix, in Antona Tuzlukova iz Qsoft:

Priporočam, da ga poslušate.

Razvoj lastne rešitve od uporabnika serkyron na Habre.
Našel sem še takšno rešitev.

In iii… v bistvu, to je to.

Opozarjam, kakovosti delovanja rešitev na zgornjih povezavah nismo preverjali 🙂
Mimogrede, pri pripravi naše rešitve sem komuniciral z Aleksandrom Serbulom, takrat njegovega predavanja še ni bilo, zato v mojih slidih obstaja točka „Bitrix ne uporablja Kubernetes“.

Ampak že obstaja veliko pripravljenih Docker slik za delovanje Bitrixa v Dockerju: https://hub.docker.com/search?q=bitrix&type=image

Ali je tega dovolj za ustvarjanje popolne rešitve za Bitrix v Kubernetesu?
Ne. Obstaja veliko težav, ki jih je treba rešiti.

Kje so težave z Bitrixom v Kubernetesu?

Prva — pripravljene slike iz Dockerhub ne ustrezajo Kubernetesu.

Če želimo zgraditi mikrostoritveno arhitekturo (kar običajno želimo v Kubernetesu), je treba aplikacijo v Kubernetesu razdeliti na kontejnerje in doseči, da vsak kontejner izvaja eno majhno funkcijo (in to dobro). Zakaj samo eno? Če na kratko — čim preprostejše, tem bolj zanesljivo.
Če pa bi želeli malo bolj podrobno — si prosim oglejte ta članek in video: https://habr.com/ru/company/southbridge/blog/426637/

Docker slike na Dockerhubu so predvsem zgrajene na principu „vse v eni“, zato smo morali vseeno narediti svoj 'kolo' in celo slike ustvariti iz nič.

Druga — kodo spletne strani se spreminja iz administrativne plošče.

Создана нова секција на веб-страници — ажуриран код (додана директорија са именом нове секције).

Изменили смо особине компонента из админ-панела — код је промењен.

Kubernetes „по умолчанию“ не уме да ради с тим, контејнери морају бити неизмењиви (Stateless).

Разлог: сваки контејнер (под) у кластеру обрађује само део саобраћаја. Ако промените код само у једном контејнеру (поду), код ће бити различит у различитим подовима, веб-страница ће радити различито, разним корисницима ће се показивати различите верзије веб-странице. Тако не може да функционише.

Треће — потребно је решити питање са деплојем.

Ако имамо монолит и један „класични“ сервер, све је много простіје: распакујемо нову кодну базу, извршавамо миграцију БД, пребацујемо саобраћај на нову верзију кода. Пребацивање се дешава тренутно.
Ако имамо веб-сајт у Kubernetes, подељен на микросервисе, контејнера са кодом је много — ох. Потребно је саставити контејнере са новом верзијом кода, заменити их старима, исправно извршити миграцију БД, а идеално то треба радити неприметно за посетиоце. Срећом, Kubernetes нам помаже у томе, подржавајући читав низ различитих врста деплоја.

Четврто — потребно је решити питање складиштења статике.

Ако ваш веб-сајт има „само“ 10 гигабајта и распакујете га у потпуности у контејнерима, добићете контејнере тешке 10 гигабајта, који ће се деплојовати вечно.
Потребно је чувати нај„тежи“ део веб-сајта ван контејнера, и поставља се питање како то исправно урадити.

Шта недостаје у нашем решењу.

Цео код Битрикса није разрезан на микрофункције/микросервисе (тако да, на пример, регистрација буде одвојено, модул интернет-продавнице одвојено, итд.). Целу кодну базу чувајемо у сваком контејнеру у целости.

Базу у Kubernetes такође не чувамо (иако сам имплементирао решења са базом у Kubernetes за окружења програмера, али не и за продукцију).

Администраторима веб-сајта ће и даље бити приметно да веб-сајт ради у Kubernetes. Функција „провера система“ не ради исправно, за уређивање кода веб-сајта из админ-панела је прво потребно притиснути дугме „желим да уредим код“.

S težavami smo se spopadli, opredelili smo potrebo po izvajanju mikrostoritev, cilj je jasen — pridobiti funkcionalen sistem za delovanje aplikacij na Bitrixu v Kubernetesu, pri čemer ohranjamo priložnosti Bitrixa in prednosti Kubernetes. Začnemo z izvedbo.

Arhitektura

Veliko "delovnih" podov z web strežnikom (delavci).
Eden pod z cron nalogami (zelo pomembno, le eden).
Eden upgrade pod za urejanje kode spletne strani iz administrativne plošče (tudi zelo pomembno, le eden).

Rešujemo vprašanja:

• Kje shraniti seje?
• Kje shraniti predpomnilnik?
• Kje shraniti statične datoteke, ne moremo pa našteti gigabajtov statičnih datotek v kupu kontejnerjev?
• Kako bo delovala baza podatkov?

Docker slika

Začnemo z gradnjo Docker slike.

Idealna izbira — imamo eno univerzalno sliko, na osnovi katere dobimo tako delavske pode kot pode z cron nalogami in upgrade pode.

Ustvarili smo ravno takšno sliko..

Vključuje nginx, apache/php-fpm (možno izbrati pri gradnji), msmtp za pošiljanje pošte in cron.

Pri gradnji slike se v direktorij /app kopiira celotna koda spletne strani (razen tistih delov, ki jih bomo premestili v ločen skupni prostor za shranjevanje).

Mikrostoritve, storitve

delavski podi:

• Kontejner z nginx + kontejner apache/php-fpm + msmtp
• msmtp ni bilo mogoče izločiti v ločeno mikrostoritev, Bitrix se začne pritoževati, da ne more neposredno pošiljati pošte
• V vsakem kontejnerju je celotna koda.
• Prepoved spremembe kode v kontejnerjih.

cron pod:

• kontejner z apache, php, cron
• v kompletu je celotna koda
• prepoved spremembe kode v kontejnerjih

upgrade pod:

• kontejner z nginx + kontejner apache/php-fpm + msmtp
• ni omejitev za spremembo kode v kontejnerjih

shranjevanje sej

shranjevanje predpomnilnika Bitrix

Še pomembno: gesla za povezovanje do vsega, od baze podatkov do pošte, shranjujemo v Kubernetes secrets. Pridobimo bonus, gesla so vidna le tistim, ki jim omogočimo dostop do skrivnosti, ne pa vsem, ki imajo dostop do kode projekta.

Shranjevanje statike

Lahko uporabite karkoli: ceph, nfs (ampak nfs ne priporočamo za produkcijske namene), omrežno shranjevanje od "oblačnih" ponudnikov itd.

Shranjevanje bo treba povezati v kontejnerjih v /upload/ direktorij spletne strani in druge direktorije s statiko.

База данных

Za enostavnost priporočamo, da bazo premaknete izven Kubernetes. Baza v Kubernetesu — ločena zapletena naloga, ki bo shemo močno zapletla.

Shranjevanje sej

Uporabljamo memcached 🙂

Dobre upravlja shranjevanjem sej, se klasterizira in se «nativno» podpira kot session.save_path v php. Takšna sistematika je bila večkrat preizkušena že v klasični monolitni arhitekturi, ko smo gradili klastre z velikim številom spletnih strežnikov. Za namestitev uporabljamo helm.

$ helm install stable/memcached --name session

php.ini — tukaj so nastavitve za shranjevanje sej v memcached

Uporabili smo okoljske spremenljivke za prenos podatkov o gostiteljih z memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
To omogoča uporabo iste kode v okoljih dev, stage, test, prod (imena gostiteljev memcached se bodo razlikovala, zato moramo za vsako okolje posredovati edinstveno ime gostiteljev za seje).
Shranjevanje predpomnilnika Bitrix

Potrebujemo odporne na napake shranjevanje, v katerega bi vsi podi lahko pisali in iz katerega bi lahko brali.

Prav tako uporabljamo memcached.
To rešitev priporoča sam Bitrix.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php — tukaj se v Bitrixu določa, kje shranjujemo predpomnilnik

Prav tako uporabljamo okoljske spremenljivke.

Cron naloge

Obstajajo različni pristopi za izvajanje cron nalog v Kubernetes.

• ločen deployment s podom za izvajanje cron nalog
• cronjob za izvajanje cron nalog (če gre za spletno aplikacijo — s wget https://$host$cronjobname, ali kubectl exec znotraj enega od worker podov itd.)
• itd.

O tem se lahko razpravlja, vendar smo v tem primeru izbrali možnost »ločen deployment s podi za cron naloge«

Kako je to izvedeno:

• cron naloge dodajamo preko ConfigMap ali preko datoteke config/addcron
• v enem primeru zagnamo vsebnik, identičen worker-podu + omogočimo izvajanje cron nalog v njem
• uporablja se ista koda, zahvaljujoč unifikaciji je sestavljanje vsebnika enostavno

Kaj dobimo dobrega:

• imamo delujoče cron naloge v okolju, identičnem okolju razvijalcev (docker)
• cron naloge ni treba »prepisovati« za Kubernetes, delujejo v isti obliki in isti kodi kot prej
• cron naloge lahko dodajo vsi člani ekipe z pravicami commit v produkcijsko vejo, ne le skrbniki

Modul Southbridge K8SDeploy in urejanje kode iz administrativne nadzorne plošče

Saj smo govorili o nadgradnji poda?
Kako usmeriti promet tja?
Ura, napisali smo modul za to v php 🙂 To je majhen klasičen modul za Bitrix. Rom še ni na voljo javnosti, vendar nameravamo odpreti dostop.
Modul se namesti kot običajen modul v Bitrixu:

In izgleda tako:

Om omogoča nastavitev piškotkov, ki identificirajo administratorja spletne strani in omogoča Kubernetesu, da usmerja promet na nadgradnjo pod.

Ko so spremembe končane, je treba pritisniti git push, spremembe kode bodo poslane v git, nato pa bo sistem zgradil sliko z novo različico kode in jo "razporedil" po klastru, zamenjajoč stare pode.

Da, nekoliko nerodno, a hkrati ohranjamo mikrostoritveno arhitekturo in ne odvzemamo uporabnikom Bitrixa priljubljene možnosti popravila kode iz administrativnega vmesnika. Na koncu je to izbira, nalogo za popravilo kode lahko rešimo drugače.

Helm chart

Za pakiranje aplikacij v Kubernetes običajno uporabljamo upravitelja paketov Helm.
Za naše rešitve Bitrix v Kubernetesu je Sergej Bondarev, naš vodilni sistemski administrator, napisal poseben Helm chart.

Izvaja gradnjo worker, upgrade, cron podov, nastavlja ingrese, storitve, prenaša spremenljivke iz Kubernetes secrets v pode.

Kodo hranimo v Gitlabu, in gradnjo Helma prav tako zagnemo iz Gitlaba.

Če povzamem, to izgleda tako

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

Helm prav tako omogoča "brezšivno" vračanje, če se pri uvedbi kaj ne izkaže. Prijetno je, ko ne panike "popravljate kodo preko ftp, ker je produkcija padla", ampak Kubernetes to opravi samodejno, brez izpadov.

Implementacija

Da, obožujemo Gitlab & Gitlab CI, uporabljamo ga 🙂
Ob zavezi v Gitlabu v repozitoriju projekta Gitlab zažene pipeline, ki izvaja uvedbo nove različice okolja.

Etape:

• build (zgradimo novo Docker sliko)
• test (testiramo)
• clean up (izbrišemo testno okolje)
• push (jo pošljemo v Docker registry)
• deploy (uvajamo aplikacijo v Kubernetes preko Helma).

Vau, pripravljeno, uvedemo!
No ali postavljamo vprašanja, če jih imamo.

Torej, kaj smo naredili

Z tehničnega vidika:

• dockerizirali smo Bitrix;
• "razrezali" smo Bitrix na kontejnere, vsak od njih izvaja minimalne funkcije;
• dosegli smo stateless stanje kontejnerjev;
• rešili smo problem z nadgradnjo Bitrixa v Kubernetes;
• vse funkcije Bitrixa so še naprej delovale (skoraj vse);
• obvladali smo uvedbo v Kubernetes in vračanje med različicami.

Z vidika poslovanja:

• odpornost na napake;
• orodja Kubernetes (enostavna integracija z Gitlab CI, brezšivno uvajanje, itd);
• gesla v skrivnostih (vidna le tistim, ki imajo neposreden dostop do gesel);
• Enostavno je ustvariti dodatna okolja (za razvoj, teste itd.) znotraj enotne infrastrukture.

Izvor: habr.com