Southbridge Čeljabinskis ja Bitrix Kuberneteses

Chelyabinskis toimuvad Sysadminka süsteemiadministraatorite kohtumised ning viimasel neist esitlesin meie lahendust 1C-Bitrix'i rakenduste käitamiseks Kuberneteses.

Bitrix, Kubernetes, Ceph — suurepärane segu?

Räägin, kuidas me sellest kokku panime töötava lahenduse.

Lähme!

Kohtumine toimus 18. aprillil Chelyabinskis. Meie kohtumiste kohta saab lugeda Timepad ja vaadata YouTube'is.

Kui soovite meiega esitlusele tulla või kuulajana osaleda — olete teretulnud, kirjutage aadressile vadim.isakanov@gmail.com ja Telegramis t.me/vadimisakanov.

Minu ettekande pealkiri

Esitlused

Lahendus „Bitrix Kuberneteses, versioon Southbridge 1.0“

Räägin meie lahendusest formaadis „Kubernetesi for dummies“, kuidas see kohtumisel teoks sai. Kuid ma eeldan, et sõnad Bitrix, Docker, Kubernetes, Ceph on teile tuttavad vähemalt Wikipedias artiklite tasemel.

Mis valmis lahendust Bitrix Kuberneteses on?

Internetis on väga vähe teavet Bitrix'i rakenduste töö kohta Kuberneteses.
Leidsin vaid sellised materjalid:

Ettekanne Aleksandr Serbuli ja Anton Tuzlukovi poolt Qsoft'ist:

Soovitan seda kuulata.

Kasutajalt enda lahenduse arendamine serkyron Habrás.
Leidsin veel sellise lahenduse.

Ja... tõepoolest, see on kõik.

Maadan, mehaanika lahenduste töö kvaliteeti, mis on antud ülalpool, me pole kontrollinud 🙂
Muide, meie lahenduse ettevalmistamise käigus suhtlesin Aleksandr Serbuliiga. Tema ettekannet ei olnud veel, seega mu slaididel on punkt „Bitrix ei kasuta Kuberneteset“.

Aga Bitrixi jaoks on juba palju valmis Docker-imaid: https://hub.docker.com/search?q=bitrix&type=image

Kas see on piisav, et luua täielik lahendus Bitrixi jaoks Kuberneteses?
Ei. On palju probleeme, mida tuleb lahendada.

Millised on probleemid Bitrixiga Kuberneteses?

Esimene probleem on see, et Dockerhubist leitud valmis pildid ei sobi Kubernetesesse.

Kui me tahame ehitada mikroteenuste arhitektuuri (ja Kuberneteses me tavaliselt tahame), tuleb rakendus Kuberneteses jagada konteineriteks ja püüdma tagada, et iga konteiner täidab üksikut väikest funktsiooni (ja teeb seda hästi). Miks ainult üks? Lihtsalt öeldes — mida lihtsam, seda kindlam.
Pikemalt vaadake palun seda artiklit ja videot: https://habr.com/ru/company/southbridge/blog/426637/

Dockerhubi Docker-imaid ehitatakse peamiselt põhimõttel „kõik ühes“, seega pidime ikkagi oma rattaga asja käivitama ja isegi pilte nullist tegema.

Teine probleem on see, et saidi koodi muudetakse admin-paneeli kaudu.

Loodud on uus jaotis veebisaidil — kood on uuendatud (ilmunud on uue jaotise nimeline kaust).

Muudeti komponendi omadusi admin-paneelist — kood on muutunud.

Kubernetes ei oska sellise konfiguratsiooniga töötada, konteinerid peaksid olema muutumatud (Stateless).

Põhjus: iga konteiner (pod) klastri sees töötleb ainult osa liiklusest. Kui muuta koodi ainult ühes konteineris (podis), siis erinevates podides on kood erinev, veebisait töötab erinevalt ja erinevatele kasutajatele kuvatakse veebisaidi erinevaid versioone. Nii ei saa eksisteerida.

Kolmas — tuleb lahendada juurutamise küsimus.

Kui meil on monoliitne rakendus ja üks «klassikaline» server, on kõik väga lihtne: käivitame uue koodibaasi, teeme andmebaasi migratsiooni, suuname liikluse uue koodiversiooni suunas. Suunamine toimub kohe.
Kui meil on veebisait Kuberneteses, jagatud mikroteenusteks, on konteineritega, kus on uus kood, palju — oioi. Tuleb koguda konteinerid uue koodiversiooniga, asendada need vanadega, õigesti teostada andmebaasi migratsioon ja ideaaljuhul teha seda külalistele märkamatult. On seejuures hea, et Kubernetes aitab, toetades erinevaid juurutusviise.

Neljas – peate lahendama staatilise salvestamise küsimuse

Kui teie veebileht kaalub „vaid” 10 gigabaiti ja te käivitate selle täielikult konteinerites, siis saadud konteinerite kaal on 10 gigabaiti, mis paigaldatakse igavesti.
Veebilehe kõige „raskeid” osi tuleb hoida väljaspool konteineri, ja tekib küsimus, kuidas seda õigesti teha

Mida meie lahenduses ei ole

Kogu Bitrixi kood ei ole jagatud mikrofunktsioonide/mikroteenuste vahel (nii, et registreerimine eraldi, e-poe moodul eraldi jne). Kogu koodibaas on iga konteineri sees täies mahus.

Andmebaasi me Kuberneteses samuti ei hoia (olen siiski rakendanud lahendusi andmebaasi jaoks Kuberneteses arenduskeskkondades, kuid mitte tootmises).

Veebisaidi administraatorid märkavad ikkagi, et veebileht töötab Kuberneteses. Funktsioon „süsteemi kontroll” ei tööta õigesti, veebilehe koodi toimetamiseks administreerimisliidesest tuleb esmalt vajutada nuppu „tahan koodi toimetada”.

Oleme probleemid lahendanud ning mikrotasandite rakendamise vajadused määratletud, eesmärk on selge — luua töötav süsteem rakenduste käitamiseks Bitrixis Kuberneteses, säilitades nii Bitrixi funktsionaalsuse kui ka Kubernetes eelised. Alustame rakendamist.

Arhitektuur

Palju 'töötavaid' pod'e veebiserveriga (töötajad).
Üks pod krontööride jaoks (ainult üks on kohustuslik).
Üks upgrade pod saidi koodi redigeerimiseks admin-paneelist (samuti on kohustuslik ainult üks).

Lahendame küsimused:

• Kus säilitada sessioone?
• Kus hoida vahemälu?
• Kus hoida staatilist sisu, ei saa ju gigabaite statiilist sisu hunnikus konteinerites hoida?
• Kuidas töötab andmebaas?

Docker pilt

Alustame Docker pildi kogumisega.

Ideaalne variant — meil on üks universaalne pilt, mille alusel saame nii töötaja pod'id kui ka krontööride pod'id ja upgrade pod'id.

Oleme teinud nagu just selle pildi..

See sisaldab nginx'i, apache/php-fpm (valitav kogumise ajal), msmtp meilide saatmiseks ja krontöör.

Pildi kogumise käigus kopeeritakse kaustasse /app kogu saidi koodibaas (v.a need osad, mille viime üle eraldi jagatud salvestusse).

Mikroteenused, teenused

töötaja pod'id:

• Konteiner nginx'iga + konteiner apache/php-fpm + msmtp
• msmtp ei saanud eraldi mikroteenuseks välja viidud, Bitrix hakkab protestima, et ei saa otse e-kirju saata
• Igas konteineris on täielik koodibaas.
• Keeld koodi muutmiseks konteinerites.

cron all:

• konteiner koos apache'i, php ja croniga
• komplektis on täielik koodibaas
• keeld koodi muutmiseks konteinerites

upgrade all:

• konteiner nginxiga + konteiner apache/php-fpm + msmtp
• koodi muutmiseks konteinerites ei ole keeldu

sessioonide salvestamine

Bitrixi vahemälu salvestamine

Veel oluline: ühendamise paroolid, alates andmebaasist kuni e-kirjadeni, säilitame kubernetes secrets. Saame boonuse, et paroolid on nähtavad ainult neile, kellele anname juurdepääsu saladustele, mitte kõigile, kellel on juurdepääs projekti koodibaasile.

staatika salvestamine

Võib kasutada mida iganes: ceph, nfs (aga nfs ei ole tootmises soovitatav), pilveteenuse pakkujate võrgu salvestus jne.

Salvestus tuleb ühendama konteinerites /upload/ veebilehe katalooge ja teisi staatika katalooge.

Andmebaas

Lihtsuse huvides soovitame andmebaasi viia väljapoole Kuberneteset. Andmebaas Kuberneteses on eraldi keeruline ülesanne, mis muudab skeemi oluliselt keerukamaks.

sessioonide salvestamine

Kasutame memcached 🙂

See säilitab sessioone tõhusalt, klastreerub ja toetab "natiivselt" session.save_path'i php-s. Selline süsteem on korduvalt tööle pandud klassikalises monoliitarkitektuuris, kui ehitasime suure arvu veebi serveritega klastreid. Deployment'i jaoks kasutame helm'i.

$ helm install stable/memcached --name session

php.ini — siin on pildis määratud seaded sessioonide hoidmiseks memcached'is

Me kasutasime keskkonnamuutujaid hostide andmete edastamiseks memcached'iga https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
See võimaldab kasutada sama koodi dev, stage, test, prod keskkondades (memcached'i hostide nimed neil erinevad, seetõttu peame igasse keskkonda edastama unikaalsed hostide nimed sessioonide jaoks).
Bitrix'i vahemälu salvestamine

Me vajame kõrge usaldusväärsusega salvestust, kuhu kõik podid saaksid kirjutada ja kust nad saaksid lugeda.

Kasutame ka memcached'i.
Seda lahendust soovitab Bitrix ise.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php — siin Bitrix'is määritakse, kus meie vahemälu asub

Kasutame ka keskkonnamuutujaid.

Kronitasud

Kuberneteses on erinevad lähenemisviisid cron-tasude täitmiseks.

• eraldi deployment pod cron-tasude täitmiseks
• cronjob krontaskide täitmiseks (kui see on veebirakendus — koos wget https://$host$cronjobname, või kubectl exec ühe töötaja podi sisse jne)
• jne.

Saame vaielda, mis on kõige õigem, kuid antud juhul valisime variandi „eraldi deployment podide jaoks krontaskide jaoks“

Kuidas seda teha:

• krontaskid lisame läbi ConfigMapi või config/addcron faili
• käivitame konteineri, mis on identne töötaja podiga + lubame krontaskide täitmise selles
• kasutame sama koodibaasi, tänu ühtsusele on konteineri koostamine lihtne

Mida head me saame:

• meil on töötavad krontaskid keskkonnas, mis on identne arendajate keskkonnaga (docker)
• krontaskid ei vaja Kubernetes'i jaoks 'üle kirjutamist', need töötavad samas vormis ja samas koodibaasis nagu varem
• krontaskid saavad lisada kõik meeskonna liikmed, kellel on commit õigused tootmisvihikus, mitte ainult administraatorid

Moodul Southbridge K8SDeploy ja koodi redigeerimine administraatoripaneelis

Rääkisime me ju podi uuendamisest?
Aga kuidas suunata sinna liiklust?
Hurraa, me kirjutasime selle jaoks mooduli PHP-s 🙂 See on väike klassikaline moodul Bittrexile. Seda ei ole veel avalikult saadaval, kuid plaanime selle avada.
Moodul installitakse Bitrixis nagu tavaline moodul:

Ja see näeb välja selline:

See võimaldab seadistada küpsise, mis identifitseerib saidi administraatori ja võimaldab Kubernetesel suunata liiklust upgrade podile.

Kui muudatused on lõpetatud, tuleb vajutada git push, koodimuudatused saadetakse git'i, seejärel kogub süsteem uue versiooni koodiga pildi ja „jaotab” selle klastrisse, asendades vanad podid.

Jah, see on veidi tobe, kuid samas säilitame mikroteenuste arhitektuuri ja ei võta Bitrixi kasutajatelt armastatud võimalust koodi adminpaneelilt parandada. Lõppkokkuvõttes on see valik, koodi muutmise ülesanne võib olla lahendatud ka teisiti.

Helm chart

Kuberneteses rakenduste kogumiseks kasutame tavaliselt pakihaldurit Helm.
Meie Bitrixi lahenduse jaoks Kuberneteses kirjutas meie juhtiv süsteemiadministraator Sergei Bondarev spetsiaalse Helm charti.

See kogub worker, upgrade, cron podes, seadistab ingressid, teenused ja edastab muutujad Kubernetesi salajastes podidesse.

Koodi hoiame Gitlabis, samuti käivitame Helm kogumise Gitlabist.

Lühidalt öeldes, see näeb välja selline

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

Helm võimaldab ka "sõltumatut" tagasipöördumist, kui juhtub, et juurutamisel läheb midagi valesti. On tore, et te ei pea ärevuses "koodi FTP kaudu parandama, sest tootmine kukkus", vaid Kubernetes teeb seda automaatselt, ilma seisakuta.

Juhtimistöö

Jah, me oleme Gitlabi ja GitLab CI fännid, kasutame seda 🙂
Gitlabi projektireposiitiumisse commitimisel käivitab GitLab torustiku, mis viib ellu keskkonna uue versiooni.

Etapid:

• build (uus Docker pilt kokku monteerimine)
• test (testimine)
• clean up (testkeskkonna eemaldamine)
• push (kujundi saatmine Docker registrisse)
• deploy (rakenduse juurutamine Kuberneteses Helmi kaudu).

Hurraa, valmis, juurutame!
Või küsime küsimusi, kui neid on.

Niisiis, mida me tegime

Tehnilisest vaatenurgast:

• dockeriseerisime Bitrixi;
• "lõikasime" Bitrixi konteineriteks, millest igaüks täidab minimaalset funktsiooni;
• saavutasime konteinerite state-less oleku;
• lahendasime Bitrixi uuendamise probleem Kuberneteses;
• kõik Bitrixi funktsioonid töötasid edasi (peaaegu kõik);
• kasutasime Kuberneteses juurutamist ja versioonide vahelist tagasipöördumist.

Ärivaatepunktist:

• rikketolerantsus;
• Kubernetesi tööriistad (lihtne integratsioon Gitlab CI-ga, sujuv deploy, jne);
• salasonad salvestustes (nähtavad ainult neile, kellele on otseselt antud juurdepääs salasonadele);
• täiendavate keskkondade loomine (arenduseks, testimiseks jne) ühes infrastruktuuris on mugav.

Allikas: habr.com